It’s the week of the Facebook IPO, and a lot of talk in the Facebook roadshow is about it’s mobile strategy. Out of the 900 million monthly active users, 500 million use Facebook on mobile. Mobile is booming and will so the next few years as these numbers are showing, so rightfully so a lot of attention goes to mobile.
On the iPhone in 2008/9, before the iPad was out, the first version of the Facebook app was seen as one of the great examples how to build an iPhone app. It was developed by one person, Joe Hewitt, and parts of the app were open sourced as the Three20 project. When he left Facebook and stopped working on the iOS app, a new team took over which resulted in a complete rewrite for a universal app that also supported the iPad (November 2011). In spite of growing numbers, not a whole lot of users actually like the current iOS app. In the US iTunes store, the rating average is 2 stars, with out the 21,803 ratings, 11,839 1 star ratings (!). One star ratings are often a sign of frustration, and you can see that in the comments. For most of the apps an average of 2 stars is deadly, but we all use Facebook so yes we will all have to use its iOS app if you own an iPhone or iPad.
So what is wrong with the iOS app?
- app is slow
- inconsistent information notification icons say there are new messages or responses, actual window does not show anything new.
- app is slower than mobile web site while everybody is used to speedy apps, the Facebook mobile web site is faster than iOS app, and offers almost the same functionality.
- tons of other bugs scrambled views, photo upload, text boxes disappear, no sharing.
What is the origin of these issues?
2. Different calls for similar information that is not in sync
For notifications, messages and friend requests regular REST calls are done, returning XML data. First check is to see what number of new notifications are there (https://api.facebook.com/restserver.php), then the actual content is retrieved in a separate call (https://api-read.facebook.com/restserver.php). As far as I can tell, the Facebook service calls return inconsistent information. When you check too fast what new notifications are awaiting you, you don’t get the new information.
Why would Facebook use HTML technology inside a native iOS app?
- HTML is easier for displaying fluid content. Objective-C really sucks when it comes to fluid display. An image with text around it, buttons with varying text labels are really hard to create yourself in Objective-C as you have to calculate dimensions and positions of all elements yourself. In particular for a timeline HTML will be much easier.
- Creates code that can be shared across different platforms. iOS, Android, BlackBerry, Windows Phone are all different technologies and a developer’s nightmare. Sharing some content/functionality in the form of HTML makes sense.
- HTML is much more in line with Facebook’s continuous deployment process. FB developers are responsible for their own QA, and part of that is to push code out to a limited set of servers, see results and then push it out to more and do this each day if not more often. With Apple taking as least a week of review, rolling back a code change is a nightmare.
- They can get away with it. Yes Facebook is not a bank, there are no other iOS FB apps out there and we will still use the service as it has a virtual monopoly on social networking with 900 million users now. We just have to suck it up.
- Feature phones is where growth is. A very high percentage of iPhone and Android users already have the Facebook app installed. The next frontier is feature phones, in particular in non-western parts of the world. These new users will first encounter Facebook on their mobile, and it will not be a shining iPhone.
For a company like Facebook a slick and fast fully native iOS App like Path would be much better. Faster means better user experience which will lead to higher user engagement. And higher user engagement is key for better monetization through ads. I’m afraid it will not be soon . What do you think?