When Facebook first released its app for the iOS platform, it was fairly well received as a solution that allowed people to easily access their friends and news feed while on the go. The initial app was written with HTML5, and this allowed Facebook to use the same code across a whopping 7000 devices for its 500 million users (1). The solution seemed to work fine, and Facebook continued to tweak and build upon this development path with new releases.
But then something interesting happened with the latest release. In an attempt to make its Facebook app on iOS the best solution for its users, Facebook broke from HTML5 and wrote the newest version in native iOS code. But why would Facebook step away from a universal solution and focus on a native app for only one of its user code bases? Obviously there had to be a substantial gain in order for Facebook to do the new development. The good news is that the new app is purportedly faster, smoother, and overall a better user experience.
Main Thread for the User Experience
In iOS, the main thread of the executing app handles the user interface and touch events. If you are using HTML5, this also has to be processed via this main thread. The end result is that the interface becomes sluggish and less responsive.
By pushing network activity, data parsing, and other computationally demanding tasks to a background thread, the user interface continues to be serviced by the main thread. The end result is an app that remains more consistent to user interaction, creating a better end user experience.
With the Facebook app, the team was challenged to get the user into the action as quickly as possible. After all, a user may access their Facebook app with only a brief moment to spare. If this time is spent waiting for a loading screen, then that user is basically lost from interacting with Facebook. Obviously time is at a premium in this scenario.
In order to get a working screen to the user quicker, smart (and creative) caching was taken advantage of on the native iOS app. For example, one of the main screen elements on the Facebook app is a long table that contains all of the story items in the user’s feed. When this table (UITableView, as it is known to developers) loads, it has to spin through all of its entries in order to calculate proper display heights for everything. This manipulation costs valuable time, and the requirement grew as the user acquired more stories in the collection.
During the development of the native app, the Facebook team discovered that they could store this height information and access it at runtime. What’s more, they could do the actual entry loading and additional height calculations asynchronously instead of being processed in the foreground. The end result was a faster loading screen than was previously possible.
Hybrid Solution for Growing Pains
The Facebook app does not do away with HTML5 coding entirely. The developers wisely used the existing rendering system as a “fallback” method of displaying new and changed elements. That is, if the app gets something in the feed that it doesn’t understand, it will throw it over to a HTML5 renderer, which can be loaded at runtime. This allows the Facebook team to release new content without having to sync up the objective C code base first.
On the next release, of the app, the native code base will be tweaked to handle the new items. In this manner, both the business need for timely new content releases and the user requirement of an optimal user interface can be addressed within reasonable bounds.
As the Facebook app shows, it is hard to truly match native code performance with a generic solution, but only if the development team is willing to explore and use the advantages such a solution offers. Otherwise a mediocre project is going to remain so, regardless of the development environment used. You can’t expect a development platform alone to solve THAT kind of problem.