by paul, on 08.28.2012
Facebook has just launched a fantastic new iOS app, a huge upgrade in performance and user experience from their previous application. This has re-sparked the debate over native vs portable mobile apps. I think that the reality is more nuanced, and talking about html5 vs. a native app presents a false dichotomy.
The problem with the "native vs portable" debate, is that it implies if you're writing a native app, you won't be using html5. In practice, this doesn't have to be true, and frequently isn't. When I was at GS, my team built GS Research, to showcase equity research to our clients. Equity Research functions quite a lot like a newsroom, and our app is built around a business that publishes timely research, sometimes based around market events, sometimes more general economic forecasting, etc. We wanted our clients to be able to download our app from the app store, and have a first class experience browsing through the research we publish.
When we architected the GS Research app, to allow our clients to read our investment research products, we made a couple of important decisions that allowed us quite a lot of flexibility:
Number one, after some debate, we decided we wanted to do a native app. The usability of the portable frameworks we tried like SenchaTouch weren't quite up to speed. Since our app is iPad only, and would have a lot of visibility, we opted to use objective-C. I would note that none of us, including myself, had ever written a line of objective-C before we started on the project. We used books, I even wrote a small metronome app to prepare. Our attitude was that we are good technologists, and can use whatever technology is required to get the job done. Programming languages are not like spoken languages; they usually have a lot of common ground, and are relatively quick to learn, and as programmers, we love to learn new languages.
Number two, we didn't want to rebuild the whole enchilada if we wanted an android client. Most publishing and news apps have a non-trivial server side component, and for our app, we had roughly three times as many developers working on the server side as we did on the client side. I don't want to trivialize client development; but we had to implement services for search, app activation, personalized content, email alerts, etc.
In general, the decision to use html5 and JSON as a contract between our web services and client application served us very well, and I would readily architect another web application this way. In fact, my colleague Bryan Irace, who was instrumental in the planning, crafting and implementation of virtually everything I've just described has, as far as I know, done just that at his current gig. My current job is pretty far removed from the mobile space, but my experience and feeling is that architecting your app using a native wrapper, but html5 for transient content, is a very sound, flexible approach.