For a couple of years now, we’ve been talking about apps for a multitude of purposes. Mobile apps continue to be the preferred way to deliver new services or content to mobile devices.
But the whole idea of the “the app” might be heading for a big change. A day may soon come when, instead of visiting the App Store or the Android Market, you’ll just click a link on your home screen to launch an app in your browser.
To this point, most developers would agree, native apps have looked better and performed better than their browser-based counterparts. Most users have looked at the mobile browser as something to avoid, because it’s such a hassle to use–especially when you need to input data.
Native apps have been more predictable than browser-based ones, too. Because native apps run from the phone’s memory, they aren’t subject to unpredictability and inconsistency in the way various mobile browsers render them.
In addition, native apps rely less on the network: Since they store much of their content on the phone, native apps don’t rely on a network connection the way browser apps do. Browser apps typically reside on a server in the cloud and must constantly tap the cloud via a Wi-Fi or cellular connection for content. If that network connection is poor or unavailable, the browser app’s performance may suffer greatly.
But this rationale is beginning to lose force, in part because marketing native apps in an app store is hard for developers. In the case of iOS apps, even getting an app accepted to the App Store. Though Apple applies the same set of criteria to each app submitted to it for acceptance, developers say that if Apple doesn’t like an app–for any reason–the company rejects it.
Though developers have less difficulty getting their apps accepted at the Android Market, apps can quickly get lost among the store’s thousands of other apps, many of which are low-quality programs.
Another problem for app developers is that they must create multiple different versions of their native app for different mobile operating systems (iOS, Android, and others) and in some instances different versions of those OS families. So developers have to spend a lot of time and money “versioning” their apps, instead of improving them or creating new ones.
Shea says that poor cataloging of apps at the big app stores helps explain the rise of specialized app stores like WildTangent, which offers only games and categorizes them carefully so visitors can more easily find the apps they’re looking for.
In a nutshell, HTML5 will let browsers–desktop and mobile–do a lot of cool new things, such as location detection, and audio and video playback without plug-ins. Syncing will improve, too, so that you can watch part of a movie at work, and then continue watching it on your commuter train ride home.
Perhaps the biggest potential benefit of HTML5 is that it will enable app developers to focus on making one version of each app, which will then run smoothly in many kinds of browsers, freeing them to move on to bringing more and better apps to market. It might also encourage them to spend more money on marketing and promotion and less on the grunt work of versioning.
The network is a factor, too. With the advent of 4G networks, which can deliver content ten times faster than 3G networks can, users will be able to retrieve content from the network far faster and more reliably than in the past–and browser-based apps will have a far better chance of matching the performance of native apps.
As for promotional considerations, browser-based mobile apps reduce developers’ reliance on the app stores. In order for native apps to have a chance at success, developers must promote them through the app stores; but browser-based apps lend themselves better to Web promotion via social media like Twitter and Google+, proponents say.
One reason for this state of affairs involves the app’s access to the phone’s features. Many developers say that HTML5 apps can’t yet control and take advantage of a smart phone’s various hardware features–such as its processor and its accelerometer–as well as native apps can.
Nevertheless, considerable debate surrounds the question of how fast HTML5 is approaching parity with native apps when it comes to controlling the hardware assets of smart phones.
“JavaScript bindings that expose features such as location are of course already available on most mobile browsers,” says Sy Choudhury, product manager at Qualcomm CDMA. “Within the next six months, we’ll see this evolve to include even richer versions of location, plus new functionality such as WebGL to access the GPU, camera/camcorder access, and richer audio control beyond what exists today.”
Choudhury and his team are responsible for optimizing the performance of Web browsers and operating systems on Qualcomm’s Snapdragon processors for mobile devices.
“A few months ago, demos started to emerge from various browser vendors that highlighted the capabilities these apps can take advantage of, such as the accelerometer, device orientation, geolocation, and camera integration,” adds Mozilla mobile browser product manager Thomas Arend. Arend points to the example of the Dashboard highlighted at the Mozilla developer site.
Delivering a consistent experience is also an issue. HTML5 browser apps run differently from browser to browser and from device to device, some developers say, making it difficult for developers to ensure that all mobile consumers will like the way an app works in their setup.
But adopting a browser-based approach isn’t necessarily a disadvantage, Arend says. “Using the Web as a platform [using HTML5, CSS3] is the most promising path to a consistent and personal user experience across devices and platforms, rather than a siloed experience from device to device,” Arend says. “A well-designed Web app can be indistinguishable from a native application for the user.”
As with any new technology, adoption will take place on the pattern of a bell curve. And early adopters have already started to take action. Pandora has announced a switch to HTML5 for its application, for example, and the cloud storage company Box.net says that it will take the HTML5 route as well. Also intriguing: One juicy rumor asserts that Amazon will soon release a browser-based Kindle app made with HTML5.
For instance, a game developer might make a browser-based “lite” version of a game so that prospective buyers can try it out without having to visit an app store, as Mozilla’s Arend points out; and if they like the game, they might decide to buy the full version as a native app.
Moreover, developers build many native apps in much the same way that they build browser apps–using the same tools–but then fit them with a native app “wrapper.” For this reason, native apps and browser apps sometimes are as different as people may imagine.
Eventually, developers may decide between making a native app and making a browser-based app on the basis of distribution factors. A developer must ask whether distribution through an app store or on the open Internet (and through social media) is the best way to attract users to an app.
For many people, the idea of a smart phone came to their attention bundled with the concept of downloadable apps. When smart phones first reached the market, native apps clearly offered the best way of completing tasks on the device. But the situation has changed since then: With mobile browsers improving, broadband speeds quickening, and HTML5 right around the corner, many people in the wireless community are questioning the assumption that native apps are the best way to deliver content and services to mobile users.
When HTML5 arrives in full force, the mobile browser may be a better–or at least another–way.
