Don’t call me DOM

5 March 2010

Native Apps vs mobile Web

Yesterday night, I was participating to a BarCamp in Sophia-Antipolis (where W3C European offices are located) on the “mobile Internet” theme.

Among the topics that were discussed, one theme popped up in several of the sessions I took part to: the differences between “native” mobile applications and mobile Web sites, in particular to answer the question that a number of people asked on which path they should choose for their content or service.

I’m summarizing below the main points that I remember being highlighted as differences between the two approaches. Due to the very informal nature of BarCamp discussions, the summary below is unlikely to be an exhaustive look at that question, and should not even be expected to be self-consistent :), but hopefully can it serve as a fodder for further discussion on this topic — that I have seen pretty regularly discussed over the past couple of years.

User Experience

Mobile applications are expected to provide a more integrated experience, using the device specific user interfaces, and with higher expectations in terms of polishing; in contrast, mobile Web sites more often rely on the Web-model of interactions (e.g. links), are more likely to bring themselves out of focus (e.g. through links to other Web sites), and are not necessarily as slick as a specially crafted native application.

Mobile applications can be started whether the user is on-line or not, and are expected to work at least minimally off-line; while the technologies to make Web sites work off-line have started to be deployed (e.g. with HTML5 ApplicationCache), they are not yet prevalent, and users are at this time unlikely to know or remember that they can use a given Web site even when disconnected.

Ease of Development

Some of the developers reported on their experience that developing a given application as a Web site or as a native application required roughly the same amount of effort — although it was noted that it was much simpler and often cheaper to find someone able to produce a Web-based application than a native one, and that the said application could be much more easily ported to other devices as well.

Ease of deployment

The barriers imposed by many applications stores and the unlikeliness that users would upgrade their installed applications made Web-deployed applications quite appealing as they can be released without anybody approval or control, and can be seamlessly upgraded without any user interaction.

The integration of usage statistics was perceived to be easier and more widespread on mobile Web sites, although some solutions have already been deployed on that space for native applications and are likely to grow over time to more applications.

Some people noted that deploying a Web site that would work across a number of devices was not trivial (although it seems to me a priori much easier and cheaper than developing applications for all the existing mobile platforms out there).

For some contexts (e.g. for confidential content or services), mobile Web sites might remain the only available option, at least for platforms where the installation of third-party applications is restricted.

Business Models

Native applications (when distributed through a store) provide an easy way to make money since they make it relatively easy for the user to pay and the provider to be paid — although it was noted that it is increasing difficult to be profitable in a market where the prices and the individual applications visibility are brought down by the number of available applications.

Several people noted that it was possible to get relatively easy user payments for mobile Web provided services (e.g. through premium SMS or through the mobile operator bill), but that they required a lot of interactions with operators.

Advertising was obviously a model available to both channels when providing free applications.

In both cases, the application can serve as additional value to an existing service and thus not require payment of any sort.

Access to advanced devices capabilities

The possibility to send notification to the user, or to interact with a device accelerometer were mentioned as typical examples of features to which native applications have access but Web sites for the most part don’t.

While Web technologies are catching up with access to more advanced capabilities (esp. through HTML5 and the ongoing work in the Device APIs and Policy Working Group where I work), they are more or less guaranteed to lag behind capabilities available to native applications since they require a larger set of actors to agree with each other.

As a counterpoint, as the number of supported capabilities grow, the number of cases where capabilities not available in the Web platform are required diminish, to the point where most applications could be built on the Web; I raised the question of whether at some point the cost of maintaining the many platforms and operating systems that the mobile industry currently offers wouldn’t pass the point (both for manufacturers and developers) where making it only Web-based would be the only viable option.

Discoverability

Applications stores are obviously the main source of discoverability for mobile applications, where particular care needs to be brought on the choice of the description and keywords — very much like the first days of the Web; likewise, the comparison between applications stores and early-Web sites directories was made.

For well-known brands and simple requests, application stores provide a filtered view that can make it easy to be discovered; but for the rest, users are still more likely to use their search engines of choices, where Web-based services dominate since they can be linked to, indexed, etc.

It is unclear how scalable the current model of applications store is, but there is little reason to doubt that they will progressively integrate more advanced search-engines capabilities (e.g. searching for applications that are relevant to the location the user is in).

Convergence

The convergences between the two models were also mentioned:

mobile applications interacting with the Web
many native applications already interact with the Web one way or another, e.g. to get and publish data for their users;
mobile applications incorporating Web content
a number of applications incorporate a Web browser component (e.g. WebView on iPhone/Android) to display existing content from a Web site
mobile applications based on Web technologies
Through the operating system SDK (e.g. Palm WebOS), or through development platforms such as PhoneGap, or through the deployment of Web widgets run-time engines, a number of seemingly native applications are actually developed purely using Web technologies, making a number of distinctions between native apps and mobile Web sites less and less relevant.

6 Responses to “Native Apps vs mobile Web”

  1. Compte-rendu « Apps vs sites mobile » par Dominique HAZAEL-MASSIEUX du W3C- Barcamp Sophia Antipolis Says:

    [...] continuer à discuter avec lui sur les thèmes du mobile web, n’hésitez pas à aller visiter sa page sur le blog du W3C ou à me contacter, je pourrai vous mettre en contact [...]

  2. Sekhar Ravinutala Says:

    Nice summary, covers a great many aspects. IMO the point about being able to find talent more easily for web apps vs. native apps is going to be critical for mobile/web startups (like mine, AllureFX) and will be the key driver for the growth of web apps.

  3. Le problème des application natives pour smartphones | Web News - Web Marketing Says:

    [...] un réflexe qu’il va falloir perdre, au profit des sites web mobiles.Pour aller plus loin : Native Apps vs mobile Web Mobile App or Browser-Based Site? Report Says The Browser Will Win on Mobile Native Mobile App or [...]

  4. Anshul Says:

    Great Blog !!!!!!!!

  5. replica cartier watches Says:

    nice article. keep post like this…

  6. Murat Says:

    Cross platform can be a solution. smartface Designer allow you to build mobile apps without writing any line of code. Also, it works for Symbian,Java, BB… It is not browser based it generates native output files like jar,sisx….
    You can check out from http://developer.smartface.biz/

Picture of Dominique Hazael-MassieuxDominique Hazaël-Massieux (dom@w3.org) is part of the World Wide Web Consortium (W3C) Staff; his interests cover a number of Web technologies, as well as the usage of open source software in a distributed work environment.