Why We’re Focused on Native Apps
On the eve of Apple’s new iPhone announcement, it seems appropriate to revisit the web vs. native app debate that has been going on for years. For a couple years, Facebook has been touting their HTML5 approach from a technical point of view. And HTML advocates have been pointing to Facebook as the example of where things are headed.
In fact, Facebook CEO Mark Zuckerberg said building Facebook’s mobile app on HTML5, which was slow and clunky, was “the biggest strategic mistake we’ve ever made” on stage at TechCrunch Disrupt.
I’m still not sure how they made this mistake (which even I wouldn’t have made). But I can guess. My guess would be that Facebook optimized on developer time and effort and complexity – one HTML 5 app! – instead of user experience – Native App! – and in the world of mobile apps that really hurt Facebook. In particular it probably hurt usage among teens who have more access to mobile devices than laptops and desktops. Which helps explain the Instagram usage in the teenage years, and why Facebook paid so much for Instagram.
I’ve been asked several times over the last two years, as we pursued our strategy of Mobile BPM (now branded BP Mobility), why we didn’t just “do HTML5” or “do web apps”. It would have been the easy way out – might have saved us development effort in some respects.
But I was pushing and pursuing a native-app strategy. Even at the beginning, I wouldn’t claim to be an expert in mobile app development, but I was already what I would consider an expert user of mobile apps and HTML5. I was willing to accept the risk that after pursuing the native app strategy, I might later look back and regret it, and wish that we’d pursued a more HTML5-heavy approach. People I really respect – a lot – have had a totally different point of view on this (and on Flash).
If Dennis Crowley is designing Foursquare for his own personal use – and coming from his own expertise as a user in Manhattan, you could argue that I’m pushing the design of BP Mobility from the point of view of an expert process user and mobile app user. I want a great user experience. But I probably won’t get asked to do any Gap commercials.
There were a number of reasons I wanted to push forward with a native mobile app approach:
- I didn’t want any consideration of cross-platform requirements or behaviors to slow down our thought process about vetting requirements and getting them right, and getting them validated with customers
- I wanted to be able to fully leverage the iOS development tools in building our prototypes.
- I was an avid user of Foursquare. It was a native app shell around a primarily HTML5 set of functionality. And the user experience when not “on the grid” was terrible. It couldn’t remember where you had been recently, where you had just checked in, or even show you the page you had been on when you closed the app. Literally nothing worked if you weren’t online.
- But wait, what about Facebook, the most popular iPhone App of all time? It was terrible: slow, laggy, and also, quite useless when you’re not online.
- Apps like Instagram and Path pointed the way to how apps should work when they can’t connect. And how much better native apps are. I just feel that an app should do something useful when it isn’t connected to the Internet.
- I wasn’t interested in “the long term” when allegedly the HTML approach will win (as it appears to be doing in many respects on the desktop). The long term answer could be many many years away. It is already 5 years further on that even Apple itself predicted with the first iPhone (initially, Apple thought all the third party apps would be web apps rather than native apps).
- Finally, I just care more about user experience than I do about the technical details.
Its hard to believe, in retrospect, that I’ve been writing on this topic since April of 2010 (or possibly earlier). When we started BP3 in 2007, mobile wasn’t on our radar yet. It wasn’t even interesting to me until the iPhone SDK came out. But since switching to an iPhone in 2008, iOS has completely rewired many personal and professional processes.
Maybe another way to look at this: live in the world that is, not the world as you wish it would be. We wish we could write one app and deploy it everywhere and have it be an awesome user experience. But the world is just too fragmented. We need to provide great experiences, not just save dollars on development costs.