We had our Apps vs Web Apps discussion at Mobile Monday SV Monday night, and unfortunately lots of folks thought we didn’t really do the topic justice. I want to thank Raj and the panel participants for making a go of it, I think they did a great job of covering a ton of ground. This is by no means a criticism of them, just an attempt to summarize and extend the conversation and feedback that came up after the panel. Which actually is a fantastic sign. Most of the time when I talk to folks after a discussion at MoMo they don’t have a strong opinion. But this time we definitely got some reactions! So maybe we did do our job well after all :-)
These are the three top points that people either tweeted or grabbed me after the event to express:
- There were a ton of points raised. Any single one of them would have been great for a deeper dive, but we breezed through them all without digging into enough of the details of any one to pull out some real meaty discussion.
- Apps were severely under-represented. Even the ‘native’ folks on the panel effectively do web development, just connected to native functionality. So there was no real conflict, and conflict tends to bring out the most interesting points of a panel conversation.
- The tone of the panel seemed to be that web development for mobile is great, but not a really viable path currently. Lots of the web folks took issue with that. The web on mobile devices is here now, and it’s a workable environment. It just takes significantly different tactics than app store models to make it work.
I want to try to lay down a high level overview of the issues I hear most frequently discussed, and that’ll probably help explain why we had some of the issues in trying to present the topic. Hopefully I can pull in some other folks very knowledgeable about the topics to follow up and fill in some specifics.
This topic as a whole is enormous, that’s the first problem with trying to cover it. It pulls together technical conversations, standards discussions, and business issues all into one. The first set of questions around using web technologies for mobile devices normally focuses on the computing power of the platform, are handhelds powerful enough to process the set of HTML, CSS, and JS to make a compelling user experience. Generally speaking it takes more computing to render a UI designed with web standards than it does to generate a native UI. Web standards have mostly been evolved with a full desktop as the target rendering platform, so the expected amount of power available has scaled as the average desktop has increased in speed and memory. Mobile devices don’t normally have the same level of resource available, and even when they do, rendering a web based UI could force them to draw so much power that secondary issues like battery life are negatively affected.
This doesn’t have to be the case of course. Web rendering engines are evolving and getting better at pulling in hardware optimizations in a way that makes the web UI as smooth and efficient as a natively coded version. But there’s also a design time solution, forming your UI in a way so that it’s compelling to the user but also not overly taxing on the rendering platform. It’s a set of design skills that are relatively hard to find currently, but as mobile grows so does the number of folks with the right skills. One of the benefits of developing for the web instead of native is that you can deploy updates at will. Just like with any web app, just push a new release to the server and it’s available to all users. Normally with native apps there’s an update process that users need to go through, and at any time you might have users on two, three, or four different versions of your software depending on how frequently you update and how quickly your users update.
The standards questions relates to the formalized spec that covers what HTML, CSS attributes, and JS APIs are available for a developer to work with. Currently much of the functionality that ties into controls specific to mobile devices isn’t presented in a standardized way. The first major chunk of functionality that got exposed in mobile browsers was access to GPS data. For years there were different ways to get to that data through different browsers and on different platforms. Just now it’s settling down to the point where that bit of functionality has been standardized enough so that a developer only needs to know one technique for getting the data. That’s just one bit of functionality however, there’s access to the camera, contacts on the phone, accelerometer and magnetometer data – all bit of functionality that many applications can do without, but would be necessary if we want the mobile web to replace native for all applications. The problem is the standards process is slow. Even the people doing the standards know they’re slow, there’s just no easy fix for that problem.
Some folks say we don’t really need the standards to evolve in order to make the mobile web work. All we need is a critical mass of devices that all use the same APIs, and developers can target the set of devices they care about and ignore the rest. That generally leads to lots of complaints about mobile web developers being lazy, some folks feel it’s the responsibility of the mobile web dev to understand and target the different platforms out there. Other folks feel that toolsets will evolve to plaster over differences in browser implementations. Even if the standards don’t pull together all the functionality you want to use as a web dev, as long as the mobile HTML/JS toolkit you use gives a consistent interface to the underlying functionality that should be good enough.
And finally there’s the business issues. To be honest, this shouldn’t be a web app vs native apps issue, this is really an Internet vs app store discussion. If Apple decided to distribute digest form HTML5 applications via the app store, you could develop with web technologies and still get the benefits of the app store model. However, Apple doesn’t allow that, and if you want to look at a world larger than just Apple you need to think about how you get onto additional handsets. For those of you who haven’t been part of the discussion for a long time, “the app store model” means a model where some third party takes your application, helps to distribute it to users, and normally provides a payment system to go along with that so that you can charge for downloading your application. This is true for most of the stores (App Store, Marketplace, App World, Ovi). However, some folks like GetJar provide distribution but leave the decision (and all the profit) related to payment with the developer. This is in stark contrast to the standard web model, where anyone can get to any website. There is no good system out there for providing “paid web apps” as folks normally call them. Part of the value that the app stores bring to the table is a billing relationship with users. It’s relatively easy to get someone to purchase a new app when they’re already given billing information to iTunes. If you want to get someone to pay you for your mobile web app you’ve got to implement your own payment system. Most folks who try this don’t see great results. There’s a lot of checkout dropoff, people not completing the transactions. The set of motivations going on here is too deep to dive into in detail, so I’ll leave it as monetization on an app store is simpler from the developer perspective than it is with a web app.
The flip side of this from the business perspective is that there’s less channel risk with the web. Generally, no one can keep you from releasing your web app because they feel that another equivalent web app exists out there, or because they object to your application. In the app store there are plenty of stories about developers who spent months developing some application, only to have it rejected by Apple without a solid reason for why it was rejected. And there’s no real way to eliminate that risk currently. The only way to find out if Apple will reject your app is to submit your app. There are also very thick margins on transacting through the app stores. Generally the split is 70% to the developer and 30% to the user both for app sales and for any sales transacted in the application. Some folks think that margin is just too high. Others say that it’s the tax for having a mobile payments system that actually works. There’s no equivalent mobile payments system out there that seems to work at the same scale, so who can really say if that 30% is too large of a cut.
Hopefully that’s helped to lay out the set of issues, all huge problems each and of themselves. And many of the leaf nodes in the decision tree (like tools for mobile web development), are a whole set of conversation in their own right.
This is the part where I weigh in with my own opinion. So where does that leave us? Is mobile web development a viable option for reaching a mobile audience today? I think it definitely is. There are certain applications (highly graphical, or which need access to local resources) which don’t work out very well on the web yet, and certain business models (if you just want to charge up front and forget about the details) that aren’t as well supported in the web environment. However the web as a runtime for mobile has evolved to the point where you can deliver compelling applications, and there are certainly advantages with respect to getting to market and being able to iterate quickly. I’m starting to see startups begin to develop for the mobile web, and then plan to go native if they feel they need to. Over time I suspect that line with shift further and further out, with the web being the preferred way to get to market – getting augmented with a native version later on. With the assumption that over time less and less folks will cross that line to needing a native version.
For those who couldn’t make it to the event UStream has a video of it online: Mobile Monday Native vs. Web apps.
Also worth a read is PPK’s post Native iPhone apps vs. Web apps.
If you’re interested in the deep tech end check out WhiterApps, James Pearce rewriting some native mobile apps to show they can be done just as well or better using the web.
Ronan has a Mobile Apps vs Mobile Web post up on mobiForge that does a great job of laying down the overall landscape, in particular the evolution from single platform to multiplatform.