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.
Around June rumors started spreading that Facebook was working on a complete rewrite for iOS, throwing out HTML and JavaScript and replacing it again with native code. This required the company to rewrite all of their mobile website as a native app again, essentially erasing the gains they had made with version 4. The release finally came to pass this week. Performance is greatly improved while the look and feel of version 4 remain. Facebook explained its reasoning in a blog post, basically saying that hybrid was a great idea but it later “found out” that iOS users wanted an application that performed well and behaved the way they expected it to. As an iOS user myself, I agree. But what does that say about the rest of the mobile phone users out there? Do Android users want a slow, buggy application? Probably not. How about Windows Mobile users? Doubtful. My guess is that the iOS crowd was the one that complained the loudest (and possibly has the larger user base) so it got the native app first. I would assume that the other platforms will get native apps again too.
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.
Relatively Ambitious 