Facebook Woos Mobile Developers, but Is It Too Late?

Not so long ago, the key to building a successful app business required piggybacking on an existing big network like Facebook.

But relying on Facebook for your paycheck also meant being subject to the whims of Facebook CEO Mark Zuckerberg. The “things” in Facebook’s mantra, “Move fast and break things,” frequently meant your app, your business.

So it is no surprise that as Zuckerberg took the stage at the f8 conference this week to woo developers back to the platform, his intended audience wondered if they really needed Facebook. After all, just a few weeks before the gathering, Facebook paid $19 billion for WhatsApp, a messaging company built without any help from the world’s largest social network.

In fact, an entire generation of messaging apps have established strong followings without relying on Facebook’s social graph or its powerful database of users. Aside from WhatsApp, there is Snapchat, Line, WeChat, KakaoTalk, Viber, Kik, Telegram — all with audiences in the tens of millions without assistance from a larger network.

Developing for mobile devices, where the new action is taking place, has empowered developers with one key tool — your smartphone’s phone book. These new apps are bypassing gatekeepers like Facebook and building new networks right from your own smartphone by going directly to your contacts list.

While phone books have been around for ages, one prominent app developer reminded me that it was the advent of the smartphone app, kicked off by the iPhone, that started making the phone book such a vital tool to creating new social graphs for developers to tap into.

“The address book was always there, but more people have smartphones now than they did five years ago,” this person said. “Now more of those address books can connect to apps.”

Another person intimately familiar with Facebook’s platform noted that this method of tapping into cellphone contacts works particularly well for communication-based apps, though not for all types of apps.

Those who choose to work with Facebook say it comes with strings attached. Some call it the Facebook tax. As a developer, you’re handing Facebook valuable data on the performance of your apps, the audiences that use it and how well your app is doing. And if developers choose to implement the new anonymous login tool the company introduced this week, they could be helping Facebook more than Facebook is helping them.

“Anonymous login scares the shit out of me as a developer,” the person intimately familiar with Facebook’s platform strategy told me. “So Facebook knows who my user is, but I don’t. They know more about my app and user base than me.”

Trust is at an all time low after years of neglect to their concerns, developers say. In the past, Facebook would frequently make snap changes to its platform, often breaking other developers’ integrated apps in the process with little or no immediate explanation.

Or say your app’s popularity is seen as a threat to Facebook. It has been known to suddenly shut off access.

“There has been a flurry of mobile apps that have been trying to use Facebook as an anchor to build their own ‘network’ in a sense, and Facebook then deems them competitive and blocks them or shuts them off,” said another prominent developer who has had a troubled relationship with Facebook. “That’s something everyone has been fearful of,” this person said.

To soothe developers, Facebook announced a series of improvements, including offering up to $30,000 worth of development services to promising a “stability guarantee” that it would continue to support apps for two years even if it made changes to its platform. So significant was the latter that it inspired Facebook to modify its motto to a less catchy “Move fast with stable infra” (short for infrastructure).

Facebook will also make better use of Parse, a startup it acquired last year that is beloved by developers. Parse sells tools and back-end support to smaller mobile apps developers.

The most powerful tool in Facebook’s arsenal could turn out to be the creation of a new open-source code standard called App Links. With App Links, clicking a link in one app will send you directly to another a page or section on another app and bypass the clunky mobile browser altogether.

Though it is open source, this process, called mobile deep linking, could give Facebook more control over how the future of smartphone usage will play out.

Think of it in terms of how one Facebook ad competitor put it to us: “That whole deep-linking product that Facebook just announced? If that works? God, that’s Google search,” this person said. Facebook could become the thread that connects all mobile apps together.

To be fair to Facebook, some industry insiders think the social network can still make a strong case for many other kinds of apps to work with it.

“Most kinds of apps, especially content-based apps, tend to leverage FB to grow,” the person familiar with Facebook’s platform strategy said. “Instagram and Pinterest certainly did. And I think a lot more will.”

But convincing developers to hand over more control will be a challenge for Facebook as it mends its relationship with the community.

“I’d say we should all be taking this news with a grain of salt, but it’s more like buckets of salt,” one prominent Facebook development partner, who did not want to be named, told Re/code.

It will take more than dropping the L-word.

“My goal over the next 10 years is to build a culture of loving the people we serve,”  Zuckerberg told a packed room full of developers at the f8 event on Wednesday, far gushier than the 29-year-old CEO has ever come off in public.

Re/code

SVN E195016: Cannot merge into a working copy with a switched subtree

As a developer, I’m pretty accustomed to getting error messages.  I think the number of errors I’ve seen is probably greater than the number of lines of code I’ve written.  I definitely have seen the same error 20 times in a row as I try to debug a single line of code.  So is the life of a developer.  Anyways, this fun error message was seen when I was trying to merge a branch into trunk after a release with the following command:

svn merge --reintegrate

I guess I should also mention that the weekend before this happened, I had just updated my Macbook Pro from Lion to Mavericks.  A little research revealed that this was due to the upgrade and my version of SVN being updated to version 1.7.  So the proposed solutions were mainly around updating my branch and removing the mergeinfo property files in each folder.  This wasn’t a great idea and seemed really manual.  So after more research, I found that it would be easier to just do a manual merge:

// from the destination where you want to merge changes into
svn merge -r N:M SOURCE

N and M are the start (N) and end (M) revision numbers you want to merge into your destination project.  And SOURCE is the url to the project you want to merge changes from.  So, in my original example of merging changes from a release branch into trunk, I would run the following command from my trunk directory:

svn merge -r 1:100 http://svn/project/trunk

Hope this helps someone.

How to build a specific SVN revision in Hudson/Jenkins

This was surprisingly easy to do, but difficult to find, so I figured I would do a quick write-up to help others who might find themselves in the same boat.  All you need to do is specify the revision number you want to build using the @ symbol at the end of the SVN URL, for example:

http://svn-repo/project/trunk@12345

12345 would be the revision number you want to build.  There are also a number of SVN plugins you could install to do this as well, but if all you want to do is test a specific revision, this is an extremely easy way to do it.  In my case, I was hunting down an issue that I could reproduce locally so I was going through the trac history revision by revision to find the culprit behind the issue.  It luckily took less than 10 tries and the builds were relatively quick, so I didn’t waste too much of my night finding the issue.  And luckily, when I found the bad commit, it was a one-line change, so it was easy to figure out what went wrong and make a fix.  Here’s a screenshot to help you if you’re more a visual learner:

Jenkins SVN Revision