Fully native Facebook iOS app released, and yes it is faster

August 23, 2012

Finally, Facebook has released an update of their iOS app. Whereas older versions used HTML technology in combination with UIWebViews, the new version as it looks now is (almost) fully developed in native iOS technology, Objective-C. As I have written in the past, it is hard to get a well performing app using the hybrid approach of native and web. The UIWebView is not as fast as when it runs inside of mobile Safari because the Javascript engine Nitro is not available for 3rd party apps, and it doesn’t seem to be so in the new upcoming iOS 6.

My testing by network sniffing confirms that no more HTML is returned from the Facebook servers but JSON, the preferred format when using REST technology. JSON just gives you the data, formatting needs to be done by the code inside of the app. Most iOS apps that retrieve server data use JSON technology, so that was a no-brainer. According to their development blog post, many more different optimisations were implemented, including offloading actions to background threads (iOS 101), caching of computations how long text should be displayed, caching of heights of rows in the UITableView. Most of the app is native now. Still some lesser used parts are leveraging HTML technology, to allow for flexibility.

So is it faster? Yes it is. It is pretty fast, and seems to be fast enough. Open up the app, within a second the timeline shows, a couple more you have your updates. Mobile users need to be served even faster than web users, so this is good. Another complaint often heard was inconsistency of information, like getting a red icon indicating new messages but when you open the tab no new messages show up. That also seemed to be fixed, although a lot of different JSON calls are done to the FB backend, so hopefully these systems stay in sync.

User interface wise, the app seems to have become more basic. The new design direction of the Facebook Camera app is not followed. This rewrite seems to be done mostly by the engineering department to speed up the app. Hopefully the design department is now allowed to come up with new nicer designs like the Instagram or Path app.

Facebook chose HTML technology to allow for cross-platform development and faster updates. In the process it developed a suboptimal iOS app for users that are spoiled by awesome and speedy apps. An app that takes 60 seconds to load versus the 5 seconds that users want, sacrifices user experience badly. Facebook has now seen the light, turned around and gone back to fully native. HTML technology has its place, some companies like LinkedIn manage to build great iOS apps but most HTML/hybrid apps are slower than native, and developers should be fully aware of that. Facebook took a lot of heat for their HTML choice, their going back should be applauded and a lesson for us all. Let’s see what the users think.

Another note about Apple, the review process really hurts companies that want to iterate faster than 1 week. That Facebook was willing to go HTML to circumvent their process is a big indicator of that. Now for new apps and new companies, I would not change the way things work. But for trusted companies like Facebook, in particular a company that like Twitter is integrated on OS level, there must be a faster way of getting updates out there? I’d think so.

Current app had an average rating of 2 stars. I think it deserves 3.5 stars. What do you think?

Get the update from iTunes.

Dirk de Kok

Posts