Back in February of 2010 I interviewed for a new job. It was the typical Google hiring-process siege; I talked to six or eight people over the course of the day. At least half of them asked me “Native vs Web apps on mobile; what do you think?”
I think about it all the time. And I talk to developers all the time so I think I know what they’re thinking. Thus this piece, which goes on and on and on but that’s OK, blogging is for long-form pieces! Includes a case study with screenshots.
Disclosures · I’m a Web guy. I started using it early, personally built one of the early search engines, and staged one of the first million-hits-a-day sites. I helped write the architecture doc and Chapter 6 of the URI RFC.
The Web has provided me with a steady paycheck since 1994, and there’ve been a couple of extra paydays along the way. So, I understand the Web, I like it, and I owe it.
What Do You Mean by “Web”? · If you crank the pedantry and purism up, the Web is about URIs and REST. If you crank the controversy down, the Web is about using HTTP for your network traffic. And if you ask an actual non-geek human, the Web means there are links and forms and a “Back” button.
I’m not going to argue in this space about REST or URIs or HTTP because I don’t see anyone wanting to take the other side. Basically, almost everything on a mobile device needs to use the network, and almost everything does it via HTTP. This has nothing to do with whether the client is a browser or a compiled native app.
I’m pedantic enough to be a little irritated by the common “Web vs Native” usage. They’re all Web apps, and this argument is really about client platforms; no more, no less.
Digression: Games · We’ve all seen the snazzy demos of this game or that being made to run in a bleeding-edge browser. But at this point in time, few game developers are interested in anything other than C/C++. There’s a small reason for this, and a large one. The small reason is that they think they’re going to get better performance than they can with Dalvik or the Objective-C runtime. I’m unconvinced, but they don’t care what I think.
The big reason is that they want to use existing game engines like Unity and Unreal which are in C-family languages, and that they want to share code between, for example, iOS and Android, which is perfectly possible at that level.
Speaking of Sharing Code · Of course, sharing is the single best argument for building on the browser; doing it once is in principle cheaper and faster than building multiple native apps. The cost saving depends on exactly what you mean by “multiple”. Right now it might mean as little as 2: Android and iOS. If one or more of WinPhone7, WebOS, and RIM get real platform traction, the value of “multiple” goes up and so does the economic argument for browser-based clients.
The Big Problem · It’s about tooling and culture. The Android and iOS frameworks are built by elite, energized teams working with a laser focus on making it real easy for developers to build snazzy native apps.
If you want a database-backed list, or a scrolling image panel, or an alpha/translation animation, or a modal checkbox dialog, or a map with some graphics drawn on top, there are recipes to follow and open-source code to re-use. If you need to run a background service or react to something being plugged into something else, same story. There are IDEs and debuggers and profilers and screen designers and they’re free and they’re good and they have user communities hundreds of thousands strong.
In the browser, there are ways to do most of these things, and some of them may even be better than the native-SDK alternatives. But the story in terms of tooling and recipe-ware and mobile orientation is weaker.
Obviously, lots people of are working on browser client tech; but I don’t know of any effort out there that’s close to the pedal-to-the-metal intensity and focus of the native-framework teams. It’s far from obvious that the browser is catching up.
So yeah, it’d be nice to just build everything once, but if you’re stuck with multiple native-app engineering projects, you’ll be working with really first-rate tools that are getting better fast.
Cross-platform? · There are tools out there like PhoneGap and Appcelerator which aim to improve the trade-offs. The idea is that you can work mostly with shared code and still have some native-app look and feel, and be native in the sense that you appear in app stores.
This area is so fast-moving that I’m reluctant to say too much. The problem these guys is trying to solve is really hard; much harder than it seems on the face of it. On the other hand, the upsides are big; it’s an area to watch.
Case Study · TripIt is the most important not-from-Google app on my phone. It’s a travel organizer; I can’t say how well it compares to the competition because I’ve been using it exclusively for over a year. Its best feature is that when you book travel, you just forward the acknowledgment email to TripIt and it gets auto-added to the app.
When you go to tripit.com in your Android device’s browser, you’re given three choices: Download an app, use the mobile site, or visit the full site. So let’s have a look at the front page of the site in all three presentations:
The mobile browser can’t squeeze the whole front page onto the handset screen very well, but a little bit of double-tapping and zooming does make it usable.
Let’s zero in on a single trip. Once again, full site, mobile site, and native app:
On the mobile site and the app, you can zoom further in to a single leg of the trip:
So, having seen all that... what do you think? Did TripIt really need to invest both in a mobile site and a native app?
There’s absolutely nothing in this app that requires access to the mobile-device hardware or to Android-specific APIs. In fact, someone sufficiently skilled at browser-based development could probably come very close indeed to replicating the look-and-feel of the native app.
Here’s another piece of evidence: On my phone, I use the app always, the website never. Also, I’m a paying customer, and it was the slickness of the native app that helped push me over the free-to-paid line.
What do you think?
Further Reading · You can bet that I’m not the only person thinking about this.
Why Mobile Apps Will Soon be Dead, by Christopher Mims in technology review.
Why “Web vs. Native” Isn’t a Black-and-White Battle, by Colin Gibbs in GigaOM.
Mobile Web vs Native App: Give It a Rest, by Josh Clark in Global Moxie.
HTML5 Is An Oncoming Train, But Native App Development Is An Oncoming Rocket Ship, by MG Siegler in TechCrunch.