Facebook released version 5.0 of its mobile application for iOS yesterday touting greatly improved performance as its major feature. It looks almost exactly the same as the version it replaces but it runs much, much faster mainly due to a complete about-face the company made in terms of its application architecture and mobile strategy. Last year Facebook was in a quandary: it had millions of users accessing it using thousands of different mobile devices. At the time the company provided a custom mobile app for each of the major platforms – iOS, Android, Windows Mobile, Blackberry – as well as a mobile website that was available to any device. It took lots of time and energy to maintain all of those different applications and due to differences in programming languages, development tools, and frameworks, it was difficult to reuse code across platforms. It was difficult for the company to maintain all of the applications while still releasing new features to users in a timely manner. It needed a different solution.
Facebook decided to leverage its rich mobile website as its solution. Using a design called “hybrid” the company wrapped its mobile website inside of a native application for iOS, Android, Blackberry, and Windows Mobile. Small amounts of platform-specific code were written to wire it all together and give the user access to hardware features such as the camera but otherwise it was just the mobile website running inside of an app. Immediately the company was freed from tons of legacy native application code bases. It now had more time to spend developing new features, not porting the same features to a bunch of incompatible platforms. If it wanted to push out a new feature, it simply had to develop it for the mobile website and it would magically appear in all of the Facebook apps on people’s phones. It didn’t need to go through App Store approval every time it made a change and users didn’t even need to update their apps. It was a win.
For Facebook. The story for users wasn’t so hot. While the user interface wasn’t bad, the performance was terrible. Compared to the prior version of Facebook for iOS, version 4 was a dog. Android was even worse. Why? Because a mobile website will never run as fast as native code on a phone. It runs inside a browser (which is native) and is interpreted on top of that. It’s running an application inside of an application and it is just not possible to run as fast. There have been significant improvements in mobile web browser performance in the past few years but they still aren’t up to the task of running a complex application like Facebook. The iOS has one of the best implementations of a mobile browser and it still suffered from poor performance. The app’s hybrid design caused other problems as well – there were issues updating the news feed, viewing photos, adding comments, and more. There was just too much going on for a web app to handle. As a result ratings for Facebook hovered around two or three stars in the majority of app stores with performance being the main concern.
So what does that mean for Facebook’s software development strategy? They are definitely going to have multiple code bases again, but based on a developer blog post, it sounds like they have some default logic in there to fallback to selected mobile web components when they need to. Maybe that means that they won’t support an entirely native app for the other platforms. Maybe it means that users might have to suffer through some degraded performance for new features until they are updated in the native app. One of Facebook’s big concerns was getting features out to its users quickly. With mobile web as a fallback, it can still do that. I’m a huge proponent of native applications because it provides the best user experience but I understand why a company might choose hybrid as a strategy. Facebook tried it, found out it didn’t work, and tried a new strategy. I wish more companies did that.