Closing the gap with native apps

Mind/the/gap by futureshape

I was last week at Mobile World Congress, one of the world biggest events dedicated to mobile, and it was great to see so much enthusiasm on the role that HTML5, and by extension the Web, can play on mobile devices.

HTML5 logos plastering booths, developers hunting for our “HTML5 everywhere” t-shirts, the large number of people that stopped by at our booth to learn how they can be involved, and the various announcements on Web-based operating systems (FirefoxOS, Tizen) all reinforced the Web’s importance on mobile.

A lot of the visitors at our booth had questions on the state of various APIs or technologies they need. Every quarter I publish answers to those questions in an overview of Web apps technologies most relevant to mobile. Yesterday I updated the report, which I hope will allow all those interested in Web and mobile to track the abundant work happening in the field.

Yet, while it was great to see so much energy behind the Web, I could not ignore those who were not so enthusiastic: the ones that had tried to base their mobile development on the Web but failed to do so due to a variety of missing features, the ones that are investing in hybrid applications but are encountering hard to workaround bugs, the ones that have been hampered by specific performance issues in implementations, or the many that reported that Web apps are much harder to make known and monetize than their native counterparts.

As part of our annual W3C headlights exercise, I have agreed to lead a task force with the goal of tackling the most important ways in which Web applications lag behind native on mobile.

Our goal is to take a broad view of that gap, identify where the Web platform remains weak, define where its strengths lie compared to other platforms, and based on that analysis, propose an action plan to reduce our most critical weaknesses and take greater advantage of our strong points.

The topic of comparing Web apps and native apps has been discussed (and even sung) at great length; it is certainly not my goal to repeat these discussions (and trust me, you don’t want me to sing). Nor is my goal to eliminate native apps: they’ve always co-existed with the Web (even back when we called them software), and will probably continue do so for a long time.

But it is also clear that many people would rather take advantage of the ability of the Web to reach every device rather than develop many versions of the same application, or would rather keep control on their link with their users rather than abandon it to an intermediary. The recent developer survey from Kendo UI was certainly heartening in that regard. Still, many encounter a number of barriers when they try to do so.

Some of the barriers that I’ve heard mentioned frequently include:

  • performance, in particular when it comes to user interfaces (e.g. scrolling), as it can affect the user experience dramatically; a whole headlight project is actually dedicated to the topic;
  • discovery: how can developers expose their Web apps to their potential users? How can users rate and review Web apps? What is the right equivalent of application stores for the Web? How centralized would it be? How does it relate to search engine? How can we make it possible to discover context relevant Web apps?
  • developer tools: when native SDKs come with full-fledged IDEs, debuggers, profilers, the experience for Web apps developers remain ad-hoc in the best cases; are there systematic problems in our technologies that have made it hard to build good developers tools? how much of a barrier is the design inconsistency among our technologies that the Web legacy requires us to keep around?
  • capabilities (e.g. hardware integration): we have already a lot of ongoing work in this space, but are there items that are so important we should dedicate a lot more resources in getting them done faster? Should we boost the efforts such as what the CoreMob Community Group has been doing to get greater convergence among implementors on a smaller set of features?

Some of the probably under-used strengths of the Web as a platform would be:

  • users don’t need to install Web apps, removing the need to “garden our phones” (as I heard Scott Jenson eloquently put it), and thus enabling use cases that are out of reach for native apps;
  • the Web is pretty much the only contender when it comes to create apps that run in any connected device, and maybe more futuristically, that break the device barriers completely (e.g. in so called multi-screens scenarios).

Part of the difficulty of this problem is that addressing these barriers, and taking advantage of these strengths depends on whether we’re talking of Web apps inside the browser context (with its specific security contraints), Web-based native apps (as defined by the W3C System Applications Working Group), or even hybrid apps.

I have started to collect a lot of my still messy understanding in the W3C wiki.

But the problem is broad enough that I or other people already closely involved in W3C are likely to miss some important perspectives.

So, what is it that you would fix to make the Web the best platform out there on mobile? How would you fix it? Feel free to either join our mailing list, send me mail or simply post comments to this article if you want to share your views!

7 thoughts on “Closing the gap with native apps

  1. A native app, as i see it, has only the following advantages over a (hybrid) web app: performance and native look and feel. This i find is ok so – there has to be some benefit for taking out the time and effort to develop in a device specific operating system/language.

    This then implies, for me, three categories of app for now and the coming years:

    Apps aimed at devices: native apps
    Apps aimed at browsers: hybrid apps specialized to bring out the best in a browser flavour
    Apps aimed at cross browsers: web apps.

  2. While certain standards-oriented groups have gone a long way toward making information on the evolving browser technologies available, the information is still not as accessible as it needs to be. I feel the framework mentality also stands in our way of seeing the innovation in webapps that many of us hoped for. The browser incompatibilities that our client-side frameworks solve often plaster over the areas which would yield the greatest innovations (and probably assert themselves as new innovations). We created a platform-agnostic chess game at chess.ecomware.com, but we would not have achieved the quality implementation had we not looked beyond those libraries. Finally, the revenue paradigm is blocking progress. Companies often expect to make money from their native apps–even those offering a poor user experience–and consumers often expect not to pay for web content, no matter how good the experience.

  3. I apologize in advance for rambling.

    I am grappling with how to think about this topic. How would this conversation change if:

    • all browsers on all devices were continuously and instantaneously upgraded to the latest version?
    • upload and download speeds were near-infinite, enabling Opera Mini-style server-side rendering, therefore shifting the burden of consuming new versions to a limited number of servers rather than a growing number of clients?
    • the space in which the user starts a native app is the same as starting a web app? (E.g., maybe installing the NYT app would be installing a shiny icon that just loaded up their web site.)
    • apps were executable within the browser?

    As HTML 5 has become more widely embraced (although not in some places I would expect, like the default browser on my Droid 3 which doesn’t support input type “range”), I see a return to WYSIWYG-style web site builders. Combine native apps and HTML app bits into that space and full-featured rich internet applications are now plug-and-play. Or does that force us to repeat the Netscape Composer/MS Frontpage sins of the past, only this time in a thus far unforeseen way?

    A new crop of web buzzwords could get (or may be getting) the current crop of middle and upper managers to seek reinvention of their products to include drag-and-drop, sliders, mobile versions, app versions, etc. It’s Web 2.0 all over again; however, this time with more than just reflections, drop shadows and AJAX. Managers feel like they need an app. Can we head this off before every major company is invested in an “app version?” Do we need to? Or are we too late? I failed when I tried to talk my company out of a mobile-specific version.

    The company I work for is large (14k+ employees), serving the employees of many of the biggest corporate names in America with a web-based product. We have only two dedicated HTML developers (and I know more on the subject than both of them). But we have probably 150 or more programmers and analysts (the latter on the SQL end), most of whom at one time or another are writing HTML but have no idea what they are doing. Need more space? Add some P tags. Want a bullet point there? Just use LI. Attributes in A and IMG other than HREF and SRC, respectively? What for? It looks fine without them. Semantics are out the window. But when you try to sell them on this shiny, new future, they will see the instability in their own product as a deficiency of the platform on which they are interacting with it.

  4. Hi,

    There is a suggestion i posted on the WhatWG : http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-December/038389.html

    Let’s give a simple use case i met. I have an application manifest having a FALLBACK section :
    /controllers/jean/installations.dat /controllers/jean/installations.txt
    /controllers/jean/controls.dat /controllers/jean/controls.txt
    /controllers/jean/interventions.dat /controllers/jean/interventions.txt

    The resources it loads are big (100-200ko average). When you have a 3G connection, there’s no problem. But when you have an edge it takes a long time to load.

    That’s why i think the AppCache manifest lacks of a section of that kind :

    TIMEOUT 3:
    /controllers/jean/installations.dat /controllers/jean/installations.txt
    /controllers/jean/controls.dat /controllers/jean/controls.txt
    /controllers/jean/interventions.dat /controllers/jean/interventions.txt

    So, if it take longer than 3 seconds to load the resource, then it fallback to the offline resource.

    How can i get this or something like this added to the spec ?

  5. Interesting that you’re talking about that ‘gap’ but do not mention the phonegap project. Phonegap’s goal is to make itself superfluous (replaced by web standards) long-term while pragmatically bridging the web/native gap short-term, so agenda items could be drawn directly from obstacles that keep phonegap-style hybrid apps from being a complete solution to the issue.

    • performance

      Just moving a web browser app to a webview container app switches to a second-class browser => performance and spec support hit.

      Last I checked, phonegap overrode the webview’s ‘prompt’ implementation to fake a foreign function interface (to give webview apps access to native capabilities beyond current web specs) => performance hit and unnecessary conversions at the webview/native interface.

      These seem to be the main reasons why hybrid apps can’t scale freely between all web and all native – one can plug some gaps in web apps, but if the problem solution would involve too many native calls, going all native might become necessary.

      How about trying to standardize a proper JavaScript native interface instead, and encouraging browser implementors to consider optimizing JS/native calls the same way as JS/builtin calls are at the moment?

    • discovery

      Web app stores are being proposed, but there are too many standards for what a web app is – useful standardization means developing collaborative standards, not just everybody proposing new ones.

      Webview container apps can go into the native stores, but take the second-class browser performance hit and come with the disadvantages of native apps.

    • developer tools

      have a look at (and help keeping up-to-date)


      and join the js-tools mailing list?


      In the age of powerful big-screen tablets with external keyboards, mobile browsers having no onboard developer tools is a gaping hole; memory profiling could be more widely supported; too much reinventing the wheel or depending on projects that lose support later; nevertheless, the situation and prospects do not look so bad.

    • capabilities (e.g. hardware integration)

      a standard web/native interface could allow easy and efficient access to not-yet-standardized native capabilities (one half of phonegap is about faking such an interface inefficiently, the other half is about providing standard APIs). That would involve a single, generic solution to interface, efficiency and security, followed by problem-specific API design on top of this generic solution. Sounds more efficient and flexible than solving the same problems again and again for every new capability API.

    1. Hi Claus,

      I’m well aware of PhoneGap and its role in this space, and when I was mentioning hybrid apps as on the paramters we need to take into account, I certainly was thinking in particular to what PhoneGap has allowed many developers to do in the past few years.

      A number of people from PhoneGap project are already involved in the Working Groups that try to indeed remove the need for PhoneGap in the first place (I’m thinking in particular of the System Applications Working Group).

      One open question I have regarding hybrid apps à la PhoneGap is how W3C could effectively make them run better; the performance issues you mention, as well as subtle differences in how the actual integration of WebViews with the underlying system have caused troubles to quite a few developers. Encouraging browser makers or OS makers is, in W3C space, easier if it comes with some concrete specification of tests they can relate to.

      On your note on making Web apps discoverable, I agree that there is a clear lack of consistency in this space, and I’m certainly hoping this “closing the gap” project will help.

      I will investigate your list of developer tools for JavaScript programming, and would certainly be interested in hearing more about your thoughts on where W3C could help promote greater consistency, or accelerate deployment of tools.

      On hardware integration, while a generic efficient and secure solution sounds indeed ideal, the many hours of work that I and others have put in this space make me doubtful that such a thing exists. That being said, greater consistency across these hardware APIs would certainly be useful, and I’m also expecting the task force will dive into this topic.

      Will you join us in this adventure? :)


Comments are closed.