Facebook Plans to Speed Up its iPhone App

Facebook's current app isn't slow because it's written predominantly in HTML5. It's slow because it takes forever to retrieve assets from their servers.<p>There's nothing magical about Objective-C that's going make the HTTP requests quicker.<p>The whole "native vs web view" performance debate is about things like animations and scrolling and rendering, not about the speed of retrieving assets from a remote server. And that's what's terrible about the current iOS app.

I think the bigger problem is still iOS's webview from within native apps, not that it has to pull most of the assets from the server. If you go to m.facebook.com in Safari it is much faster than using the native application and most of it is the same HTML5 code that is running within the webview of the native app. The twitter app is also painfully slow when clicking a link and it opens up the resulting page in a webview.

I think the biggest problem here is that iOS/Android WebViews are incredibly sensitive to memory and CPU, and if you just take an otherwise amazing desktop or backend developer and throw them in mobile webview, you're setting them up for failure.<p>The webview is a whole different ball of wax (my last gig was PhoneGap development on iOS and Android) and if you are not, from day one, incredibly focused on performance (CPU and Memory) you're gonna have a bad time.<p>Knowing what I know about making PhoneGap apps, there's nothing inherent in what FB is doing that the WebView is incapable of doing. It's just really hard to get it right, much harder than a native app.

I have tonnes of emails saved in my iPhone Notes app of people I met, tried to unsuccessfully find on facebook using the app, and later found them using the facebook.com from a normal computer.<p>I'm starting to feel that facebook purposely broke its iPhone app to limit use. There is simply no other explanation why the most basic feature of finding and adding a new friend would be so terribly broken.

There is no excuse for using HTML5 when the native platform offers you so much more and the user base is substantial. Only cheapos try to get away with it. Web is dead, welcome to app economy!

Jeff Atwood said it best: performance is a feature.<p><a href="http://www.codinghorror.com/blog/2011/06/performance-is-a-feature.html" rel="nofollow">http://www.codinghorror.com/blog/2011/06/performance-is-a-fe...</a>

Excellent news. I know it says that the design isn't really changing, but I hope that a few things get cleaned up, too — say, like the way comments views sometimes show Likes and sometimes don't. That one's baffling to me.

"the company had chosen to build its apps predominantly using HTML5 so that it could take advantage of reusing programming code across multiple mobile platforms"<p>This is certainly a benefit, but at Facebook's scale, it made sense to dedicate engineering efforts to have the best experience on the iPhone. I'm glad they're finally going in this direction. However, I think that one of the benefit that is not mention here is the easiness to change the UI at any point, which they've been doing all the time.<p>That being said, I would think that it would still be possible to modify a native UI without going through an App Store review, since more or less everything can be created and customized programmatically: so you can send some kind of file that describe the UI tweak. Surely, it can become a mess pretty fast, but it's an option.

Having done some PhoneGap dev lately, it is possible to make a great app using HTML5, but to make it perform well and have the right look and feel requires a ton of work, and the tooling around it still leaves something to be desired, especially on the UI side.<p>Libraries like Kendo UI or Sencha Mobile help a lot, but if I were Facebook, I'd spend the dev time to do it right and make it awesome.<p>Whether that means optimizing the crap out of their HTML 5 or going native is a judgement call.