Here’s why the Facebook iOS app is so bad (UIWebViews and no Nitro)

May 14, 2012

It’s the week of the Facebook IPO, and a lot of talk in the Facebook roadshow is about its 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?

  1. app is slow 
  2. inconsistent information notification icons say there are new messages or responses, actual window does not show anything new.
  3. 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.
  4. tons of other bugs scrambled views, photo upload, text boxes disappear, no sharing.

What is the origin of these issues?

1. HTML and UIWebViews without Nitro JavaScript engine
I did some network sniffing (I like sniffing 🙂 ) and found out that the data that the iOS app downloads from is a mixture of REST (XML format, no JSON) and HTML. The HTML is used for your personal timeline, and profile and groups timelines. See for yourself, go to and see that it is the initial view of the iOS app. Also from the screenshot above, you can see something went wrong while downloading the html and images/stylesheets/JavaScript. To display HTML in an app, a developer uses a Safari component called UIWebView. Very convenient, but also dangerous. The HTML downloaded is pretty big (15kb), and contains links to images, stylesheets and JavaScript. For a starter, caching of unchanged content cannot be controlled by the developer. The FB app downloads the whole timeline HTML every time, and it is up to the UIWebView to determine whether it needs to download images, stylesheets etc. again. Second, performance of UIWebViews is less than in mobile Safari. This has a lot to do with the absence of the new Nitro JavaScript engine in UIWebViews, apparently for security reasons. I ran some tests on my iPhone 4 with iOS 5.1.1, the JavaScript benchmark Sunspider running in Mobile Safari was 3 x as fast as running in a native app with a UIWebView. Also, to communicate from the UIWebView to the native app, a JavaScript bridge is needed. This is tricky stuff, slow and not really thread safe.

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 (, then the actual content is retrieved in a separate call ( 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?

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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?

Update 8/23/2012: Facebook agreed and today released a completely rebuilt iOS app, using native technology.

Update June 2014: With iOS 8 Apple has released a new set of classes to replace UIWebView, namely WKWebView.

Update June 2015: With iOS 9 there is a new class SFSafariViewController that allows 3rd party apps to basically use Safari to show web content inside their app. This gives all the power like shared cookies, bookmarking and autocomplete to the user while still maintaining a high security standard. Watch the WWDC 15 video about Safari View Controller


Dirk de Kok


54 responses to Here’s why the Facebook iOS app is so bad (UIWebViews and no Nitro)

  1. I’d like to see the Facebook app like the new Google+ app…that’s fluid and smooth…

    • I agree, the Google+ app looks amazing and is fast and fluid. The only problem is that none of my friends use it. Somebody should make some facebook group thats says if you join, you agree to switch to google+ on day X. I’d get all my friends to join and could ditch facebook. That couldn’t happen though, FB would take down the group if it got too much attention. Second, I think a lot of people who would join would go through with it because many of their friends arent on Google+.

  2. The Facebook iOS app also has a horrible process for loading external links through, which ends up being redirected to the actual URL but is very slow and often fails to load. I’m sure Facebook does this for analytics, and probably some link security but its not very reliable and also breaks caching in alot of cases.

    • yeah they also do that on the web, keeps the receiving site from discovering via which user profile the site was reached. Would be good to know, but in this one case FB prefers to keep the user data private 🙂

      • The difference between the redirection in the iOS app and on the website, is that it in the app it almost always seems to fail to load the page in a remotely timely manner.

  3. Thanks for the break down. Facebook’s iOS app is God-awful slow and has forced me to switch over to its mobile web app for the time being.

  4. The Facebook app for WP7 is quite different. You know it’s not HTML because a single post will “tilt” when you tap it (and keep pressed), a consistent experience across WP7 and its apps.

    The problem is that it has lesser features than its iOS and Android siblings, at least as of today.

    Anyways, nice analysis!

  5. Hey Dirk
    Good analysis. I completely agree with you on most of these points. As the behemoth that it is, Facebook owes its (500m+ !!) mobile users a much better experience.

    However, I wonder about how you wrote the first point – ‘No Nitro Engine’. There’s no technical way to leverage that till iOS enables that for UIWebView, so that’s not on FB. That’s a cupertino issue.

    If one wants to write HTML code (and there are tons of justifiable reasons to do so) for multiple platforms or for even iOS alone, there’s no way to use that extra boost currently. One can talk about the difference between the different wrappers on the market, but ultimately you are rendering in a UIWebView and that’s it.

    Besides that, I completely agree that FB can do a number of obvious and not-so-obvious things to optimize our mobile ux.

    Thanks for the article.

    • no, it’s not a cupertino issue. the article is explaining why the *new* FB iOS app is slower and less responsive than the previous versions. thats a fault, and its due to decisions FB made (namely, building a HTML-based app w/ an iOS wrapper). thats an engineering decision that rests solely on FB’s shoulders, since we all known the performance costs of UIWebView.

      there are many arguments against wrapped HTML apps and for native apps. this poor responsiveness could certainly be one of them.

  6. Hi! First, thanks for this great post 🙂

    Second, I thought that Apple prohibits downloading code from the application (as its guideline review), Apple considers JS-code as program data?
    Anyone who is not Facebook can do?

    Kind regards!

  7. Hi !

    Good article. However you say it’s very hard to display fluid contents on a native iOS application. Path isn’t written in Obj-C ?

  8. How does this compare with the LinkedIn iPad app, which uses a similar web architecture? Until Apple allow auto updates for IOS apps, using a web architecture certainly has benefit. I can’t tell you how many of my apps are out of date, it’s constantly in the double digits!

    • Yeah I would also like to know how LinkedIn is getting good reviews, if they are apparently also using HTML on IOS.

    • As far as I know LinkedIn uses backbone.js and a different templating system. Meaning they don’t download the full HTML+CSS+JS content, just the relevant data in JSON format. That’s way lighter than what Facebook is doing.

  9. Thank you for the info! I’ve been wondering for some time why the Facebook app is so terrible. It’s a shame that Facebook has been touting mobile a lot lately without any regard to its app too. But we’re not forced to use it. The mobile web app is great on the iphone and the standard UI works great on the iPad. I’ve deleted the app from the my iPad and may soon on my phone except the notifications are useful.

  10. I use flipboard on iOS to read my FB timeline, it read very little FB data but what it does read it shows very quickly unlike FB

  11. Robert Jacobson May 15, 2012 at 12:11 pm

    This article is ridiculous. Not caching data is te fault of the developers, not Uiwebview. And seriously, blaming the slowness on HTML? What does the format of the data have to do with anything? There is no reason their dev cycle isn’t compatible with a decent iOS app. iOS development at Facebook is not a priority. Period. That is the only reason the app sucks. It sucks because they wrote a shitty app. Not because of Uiwebview. Not because they use HTML. Because they wrote a shitty app.

    • er, no. it is purely because they are using a heavy HTML app vs. a faster compiled Obj C app. dur. thats the whole *advantage* of compiled code. look it up.

      • Late to the conversation here but Robert Jacobson makes an excellent point: your criticisms are specific to the implementation of the FB app and not the concept of hybrid HTML5 apps. You specifically point out inefficient and inconsistent web service calls that cause many of the problems. Even a native app will be at the mercy of a poorly written web service. I appreciate all the research you’ve done for this article but it is disappointing that it is getting referenced elsewhere on the web for an example of why HTML hybrid apps are bad. You’ve got a good critique of the Facebook iOS app implementation here. This does not even come close to a fair analysis of HTML5 hybrid mobile applications as an implementation strategy.

    • “shitty app.” wow, that’s a really deep technical analysis there, thanks.

  12. Hello everyone,

    On Monday I wrote a Business Insider article called “Open Letter to Mark Zuckerberg, Sheryl Sandberg and Facebook Mobile”. It addressed a lot of other items related to this discussion 2 days before all of the Facebook S-1 amendments regarding mobile exposure filed last week.

    I think that you will enjoy the read as I think the work done here is a good additional level of detail behind the high level description that I tried to provide in parallel. Here it is:

    Alan Knitowski
    Phunware, Inc.

    • nice article, hadn’t seen it. Yes, HTML5 is the future but not now. Both on iOS and Android should they go native: better technology, user experience specific for that platform. Or be as good as LinkedIn in HTML5 in mobile apps

      • Amen. In the comments section of my post, the Worldwide Head of Facebook Mobile Relations suggested that they already had native iOS and Android versions of their apps. I tried to humbly suggest that he was perhaps missing my point … which was that they needed GOOD native versions of their apps … NOT what they currently have. I requested a meeting to discuss things with them, but unfortunately they have yet to be interested in having a dialogue. Disappointing for sure as we know mobile incredibly well and can help immensely. Guess we shall see, but I am optimistic that they will at least entertain a meeting. Cheers.

  13. my 2 cents: the UIWebView blocks the main thread, so if you are a user like me (with 300+ friends) I got 250+ http requests. Using the chrome’s network inspector.

  14. For others in the extremely frustrated boat, there are other options.

    1. Use Safari to create a link on the springboard to the facebook mobile site.
    2. There are 3rd party facebook iOS apps, for instance MyPad & Facely HD. Not sure how these stack up, but they are sure as hell faster than the official app.

  15. Very good analysis. I think it is important to underscore that the bulk of their issues aren’t caused by the things they can’t control, like the obj-c/js/http bridge, but by poor architectural choices with in the app and services. It seems ridiculous they are having the issues with the size of their development budget. It is going to be very interesting to see how they respond to and fix this issue. As much as people would like to draw parallels between Facebook and Google from my experience with their software, Google is head and shoulders above Facebook in engineering practice, and so as they begin to compete on that level it is going to be interesting to see if they are really an engineering company like Google or more of a marketing company as they grow.

  16. One problem with Fb’s mobile site — they don’t have the meta tags to enable the iOS home screen shortcut to run in full-screen mode. Harrumph!

  17. I’d say that there are alternatives to the facebook app. Facebook long ago lost the war for the Android version of chat and allowed companies like SpartanBits to make some profits with their own chat app.

    I’d expect something similar to happen with other functionalities (btw, the facebook app for android is just as bad as the iOS one)

  18. Not sure why you are saying it doesn’t have access to Nitro. Apps and webapps that use UIWebViews have been able to use Nitro since iOS5.

    Apple Insider – iOS 5 supports speedy Nitro JavaScript for full-screen Web apps

  19. Very interesting article/breakdown indeeed – thanks for that!

    Whilst the Webdesign for the regular Facebook-App (+ the mobile version) seem to be working fine, the native App really is slow and until now I didn’t see why.

    One would guess that Facebook has got brain & resources enough to fix this sooner… Maybe all this attention will give the dev a “push”.

  20. Frangonil1991 May 16, 2012 at 12:44 pm

    I have been working for the last year or so on a new facebook app for the exact same reasons I have been working really hard and hopefully it will look as slick as the path app for facebook.. And it should look the same on Android/WM/IPhone… Look for it sometime soon i am just doing QA ATM!!!!

  21. I wish it weren’t true but, alas, this is precisely what I’ve found as well (in my http proxy explorations). It’s embarrassing, to say the least, and a blatant disregard of usability at worst.

    Point taken about Nitro. I’d say UIWebView in and of itself is fine, but the gratuitous abuse of it here simply takes the cake. Talk about your crutches!

    As a developer, I grew NOT to be a fan of Three20 from an architecture perspective (in terms of how it squares with existing Objective-C design patterns), but I give Joe Hewitt heaps of credit for writing the thing at all, and also for “putting the eyebrows” (little UI details) on the original Facebook app.

    As for now, if ever there was a poster child for the pitfalls of lowest common denominator cross-platform apps that cut corners and do not play to the strengths of each one (be it Windows Phone, Android OS, or iOS), the Facebook app, sadly, is in the catbird seat.

    Here’s hoping FB can take this dismal situation, start anew, give each OS platform the proper attention it (and their user base) deserves, and hit a honest to goodness home run. Remember, FB: “There’s no substitute for the work. Not even genius.”

  22. You should contact @jamespearce at FB.

  23. The Android app is even worse!

  24. As someone who uses the Android app (much less these days but still sometimes) it is interesting to read about Facebooks cross platform mediocrity.

  25. my facebook android app is absolutely useless. I often can’t leave comments and i don’t get to see other peoples comments till after about seven minutes. I might as well not use it. It’s total crap.

  26. Does anyone know what i can do to get a facebook that actually works. I got galaxay tab, gingerbread. I installed fb android app and now its so slow i cant use it and my comments dont get sent.

  27. Facebook’s iOS app is superb…smart technology…i like this apps…superb feature…thanks for your blog post.

Trackbacks and Pingbacks:

  1. Facebook Hires Team Behind Android Photosharing App Lightbox | TechCrunch - May 15, 2012

    […] has been frequently criticized for the slowness of its mobile apps. This talent acquisition of engineers could help it speed […]

  2. Does your Facebook mobile app suck? Here’s why — Mobile Technology News - May 15, 2012

    […] for Android or iOS. But I’m not a developer, so I couldn’t be sure. Now I am, thanks to Dirk de Kok’s detailed post at Mobtest, which tests mobile […]

  3. Here’s What Could Kill Facebook | TechCrunch - May 15, 2012

    […] eyeballs. However, while it has a huge footprint of over 500 million mobile users, there’s widespread discontent with the speed of its mobile apps. Many people think they’re cluttered, and complain of slow […]

  4. Waarom de Facebook iPhone-app zo traag is - - May 16, 2012

    […] […]

  5. Quora - May 16, 2012

    Why is the Facebook app for iOS so bad?…

    These are the technical reasons why the app is bad: * Excessive use of inapp browser views (UIWebView) with no Nitro Jascript engine availability for webviews because Apple decided that was not secure * different REST calls that render different inform…

  6. Facebook Camera Could Backfire and Get All Of FB’s Apps Buried In A Folder | TechCrunch - May 25, 2012

    […] web-based social network into a single mobile app hasn’t quite worked out. Many people complain the app feels slow and requires too many clicks to get to core services. Honestly, I think the click friction concerns […]

  7. Facebook please do not create a phone. Create great apps/mobile ads - May 28, 2012

    […] Right now Facebook problem on mobile by far is the performance of its mobile app. It is one of the worse mobile app ever created by a great company: it is slow. insanely slow. The reason? it is not native. Not really. It is a web version of the site, wrapped in a native shell. The results is a slow poor experience. Read more about why here […]

  8. Facebook News Feed Is Getting Faster, So I Made It This Tramp Stamp | TechCrunch - July 3, 2012

    […] details from a few nameless Facebook engineers, so it seems surely on the way. Considering the flack Facebook’s been getting for the laggy iOS app, you know, possibly the most popular app in the world, I think it’s […]