Apps vs Web Apps Recap

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.

Updates:

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.

This entry was posted in Community, Mobile Monday, ThisIsMobility. Bookmark the permalink.

8 Responses to Apps vs Web Apps Recap

  1. Raj Singh says:

    Mike,

    I agree – I think we could have used someone on the panel (maybe the one audience member) who felt that we would never go to web apps (and remain native forever) – some more contention would have been nice.

    I did take the approach of covering numerous perspectives rather than deep-diving (by design), maybe a follow-up discussion! It is fascinating to think techies want web, biz folks want native, advertisers want native, operators prefer ??? etc – different selfish motives.

    The most interesting piece for me was the final polling w/ real apps and seeing what the audience felt. It was interesting to see the audience split on both Pandora and Google Maps (and maybe we bring a large native app publisher on the next panel).

    Raj

  2. Mike Lee says:

    That’s great that you guys are listening to the audience. This was my first MoMo event and I really enjoyed it.

    The mobile web vs mobile native app discussion is obviously a vast one. I thought this past MoMo talk was a good intro, mostly in terms of touching upon some of the main issues in this debate. It would be fantastic to slice up the discussion and deep-dive into each.

    For instance:

    1) From the consumer angle. Which do consumers currently prefer? Are there stats? Are they trending a particular way?

    2) From the business angle. Do businesses with both types of apps see more traction on either side? Are there stats & trends? How are their margins on either side?

    3) From the developer angle. Will multiple versions of mobile OSs and mobile browsers mean new cross-browser headaches? What are best practices in performance, code reuse, etc?

    4) From the technical/project management angle. Which skill set is easier to hire? What are typical development times? Anyone ever try developing the same app on the web & native, and letting the projects start at the same time (and assuming skill set can be normalized to a degree)?

    5) Even a case study by a few developers with both mobile web & native apps would be interesting.

    I’m sure there are many more. And I applaud you guys for taking a stab at this huge topic! Keep up the great work.

  3. The most critical limitation of an app system is that lack of an universal/crossplatform hyperlink framework.

    “Hyperlinks create a usable and connected experience.
    Tim Berners Lee created hyperlinks to serve as a thread to connect the Web. URLs allow anybody to link to anyone. Google turned those hyperlinks into currency. Search engines crawl the Web and follow hyperlinks in those documents to create relationships between content. Enter mobile applications. An overlooked limitation of applications is that they do not accept incoming links, there is no URL to open a certain piece of content in your newspaper or Facebook app. Without hyperlinks these apps are not first-class Web citizens and as such lead an isolated existence. Real World Scenario: You Google something and find an interesting piece in the New York Times. When you open the link it will open the New York Times Site and not the New York Times app even if you have it installed. Therefore, you must have a mobile Web site even for those users that have your app installed and your user is confronted with two interfaces for the same content. ”

    source: http://mobileanalyticssimplified.com/post/439404358/the-future-is-the-mobile-web-not-the-mobile-app

    I may add that this also undermines the social media strategy of brands. An app like twitter is most consumed in apps on mobile apps and they provide links to their content, but often those links don’t work that optimal on mobile browsers since they simply don’t give it it as much effort as they give to apps.

    Curious what you think.

  4. miker says:

    Hi Stan, great commentary. Certainly something I’ve seen some attempts to address in the past. Take http://www.myappmarks.com for example, they presented at a recent Mobile Monday London. Not a fantastic solution the problem, but further point that folks feel the cross-linking is a real issue.

    Personally however, I’m not quite sure if the concept of cross-linking to an app will build the right kind of experiences. I think the reason apps work currently is because they’re frequently put together blank slate. Many of the attempts in the past to concentrate on the content and to “mobilize” the experience fell completely flat. I’ve tried to do it a few times, so I have particularly strong feelings on that end.

    Now at least folks are rethinking the mobile experience from the ground up, and it was really necessary in order to build compelling applications for these devices. There was too much legacy thinking from the desktop floating around before we made this clean break.

    Now that perceptions and preconceptions have been realigned what is the role of the hyperlink going forward? As the commentary in the blog post you reference gets into, there are a few different ways to arrive at the same endgame. And the problems are really deep there. The Google example from your quote is excellent on multiple levels. Not only is there the issue of how does the search engine shovel you off to the right content, but how does that content get into the search engine at all. Doesn’t matter if you’re talking about native mobile apps, or just single page web apps for mobile or desktop, the information architecture is shifting away from a focus on content and into a focus on user experience. If the trend continues some of our core services are going to have to significantly evolve to keep servicing us the same way.

  5. Hey Mike, we focused our argument from the post on the great importance of the mobile web for social networks.

    http://mobileanalyticssimplified.com/post/1299627426/are-mobile-apps-derailing-your-social-media-strategy

    It answers your question: Now that perceptions and preconceptions have been realigned what is the role of the hyperlink going forward?: Paramount importance given the importance of social networks.

  6. Pingback: Thank You Twitter and Facebook

  7. Pingback: Mozilla Open Web App Prototype

  8. A couple weeks ago, I was at an ad industry conference where reps from the big (As in: “If your budget is less than $100 million, we don’t wanna hear from you”) agencies were all on a panel, rubbing their temples and trading stories about pigheaded clients who *insist* on having an app. They don’t know what it is, don’t have the slightest as to what they want it to do, they just know that they saw these really cool Apple ads on TV, and everyone else has an app, so they need one too.

    The breakthrough: one after another, they talked about how they had “fired” clients rather than take their money to build an app that just squats in the App Store, marinating in its own irrelevancy & failure. There’s a growing recognition that “Apps for the Sake of Apps” not only doesn’t make sense, but reflects badly on anyone with their fingerprints on it. Maybe they were just blowing smoke (some Machiavellian/Don Draper move, perhaps), but the consensus was that the Gold Rush days are dwindling in the app space.

    I’m guessing that if Android, WinPhone7, et al. start making a big deal out of the fact that they’ve standardized the APIs so that developers can snarf up data from the accelerometer, GPS, compass, magnetometer, or in-device DNA sampler (in Beta on the iPhone5, I hear), then the pressure will mount for Apple to start making breaches in the wall in the Walled Garden. That, or everyone will just start designing pages that can be used on everyone else, and Apple will once again experience the BoomSplat of the Pc vs Mac wars of the ’80s.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">