Aug 24 2012 · Random
Facebook recently released a new version of its iOS app in order to fix a number of issues with the previous releases. The Facebook app has been notorious for being slow, buggy, and simply lackluster overall. The problem touted by many was the fact that it was not a native iOS app in that it relied on UIWebView containers to display content; this post brings such speculation front and center. However, I’m not sure I agree that the blame lies with UIWebView. The problems with the Facebook app, as far as I could tell, centered around lag in loading content, or or simply not loading content due to connection timeouts. Two comments in the post, I think, point out the real issues:
This article is ridiculous. Not caching data is [the] 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.
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.
The last quote brings up an important point, many are now soured by the idea of a HTML5 hybrid mobile application, which is unfortunate because it’s a architecture that would work well for many developers and alleviates the burden (at least to some degree) of supporting multiple mobile platforms.
Looking ahead, I’d bet on HTML5 and web technologies in general. You’ll never get native performance, but as mobile devices become more powerful the tradeoff, platform flexibility and ease-of-development in exchange for lower performance, will become a non-issue for all but the most intensive applications (e.g. games). I toyed around with PhoneGap (before it was bought by Adobe and split off into PhoneGap and Apache Cordova) last year and was pretty happy with the results. I did have a number of frustrations, but those weren’t due to performance, but to bugs and rendering issues in a number of HTML5 mobile frameworks (jQuery Mobile, jQTouch) and webkit mobile itself (support for position:fixed; not available in iOS 4 at the time, supported in iOS 5 which had just hit the market); I’m not pessimistic here, these are things that will improve (or have already improved) as mobile software development matures.