What is the future of the mobile Internet? Are native applications going to be the dominant form of digital interaction? Will new and developing browser technologies like HTML5 make the mobile Web preferable to apps? Developers, engineers, product strategists and brands large and small want to know what the future will look like in order [...]
What is the future of the mobile Internet? Are native applications going to be the dominant form of digital interaction? Will new and developing browser technologies like HTML5 make the mobile Web preferable to apps? Developers, engineers, product strategists and brands large and small want to know what the future will look like in order to make spending decisions.
When to Make a Native Application
I’m obviously a big supporter of the mobile web; however, I am the first one to admit that making a native application can be the best thing for a product. This is usually true when you need to take advantage of the features of a device that a mobile web browser does not allow.
The following sections discuss some of the key features you may be considering that almost immediately point toward creating a native application.
CHARGING FOR IT
Nowhere is it written that you can’t charge people to use a mobile web app, but for some reason, people think you can’t or shouldn’t. Historically, charging for things on mobile devices has come down to two obstacles:
Entering a credit card number in the mobile device is cumbersome and can be insecure on older devices. Typically, if you want to charge for it, you set up an arrangement with operators to do Billing on Behalf of (BoBo) so purchases just show up on the subscriber’s bill. This means you need to have BoBo arrangements with every carrier your application is on, which is its own headache. This is usually the preferred method, because a lot of people with phones don’t have credit cards, such as young people.
Another route is storing subscribers’ credit card information on a secure website. The user is then able to log into her mobile profile and make purchases against it. This two-step process is less than ideal and basically means that people can’t just go and buy from their device.
MANDATORY REVENUE SHARING
Operators want their cut. A native mobile application directory, either through the operator or through a device maker, always includes a means to collect payment for it. They typically just take their cut and pass on the rest of it to you, but it means that you must work within the rules and regulations of their marketplace. Getting onto the operator marketplace has historically been a colossal effort, requiring full-time staff just to negotiate terms. Since those days, device maker markets have made it much easier to get products to market, but are plagued by most, if not all, of the same problems and red tape.
Applications and services that encroach on the operator or device maker’s business model will likely be blocked or removed from sale. Mobile websites that earn too much money without the carrier getting a percentage have been shut down in the past, but you don’t hear many of those stories these days.
The bottom line is that if you want to charge for a native application, you are going to have to work within the rules of the marketplace and give up a decent percentage of your profits.
CREATING A GAME
If your goal is to create a mobile game—one of the biggest mobile content markets—then you need to create a native application. Games are resource-intensive and almost always require the use of a device or platform API. Although there have been quite a few compelling games created using just web technologies, the competition in the native application game market is just too stiff. When users launch a game, they have some expectations of what it is going to look and act like. The mobile web is close to providing an analog experience, but is not quite there yet.
When making mobile games, you need to carefully consider which platforms to support. Luckily, there are a variety of game porting houses that can help get your game onto multiple platforms, but as you might imagine, it can be a costly endeavor in terms of money and time.
USING SPECIFIC LOCATIONS
The next feature is location, or being able to detect the users’ locations by GPS or cell tower triangulation for the purpose of presenting users with information based on their current location. Traditionally, the only way to access users’ locations is through native application APIs, but the W3C Geolocation API is quickly being incorporated into the most popular mobile browsers. Devices that run WebKit, like the iPhone or Android devices, as well as devices that run the Opera or Mozilla browsers, will all have the ability to detect user’s locations.
I believe that location is the holy grail of the Web. If it can be made available to the web browser, then web publishers can begin to use location and context in new and interesting ways. Although it is not a technical hurdle, the issue has mostly been with privacy. We like to think of the web browser as an anonymous portal into the World Wide Web. Adding location means sharing sensitive information with websites, which could actually be quite dangerous. But for all location-aware applications, providing your location requires your direct authorization from the device for each instance, and you have the option to disable it entirely.
The camera is another device function that can come in handy in your applications. Traditionally, mobile MMS (Multimedia Messaging Service) is used to handle mobile photo interactions. In other words, you take a photo, send it via MMS to a shortcode, then a server somewhere does something with the photo and sends an alert to you when it is done. This process is complicated, time-consuming, and fairly unreliable.
With access to the camera, native application developers can simplify the task to just taking a photo from within an application. The user then can do limited processing on the client side, sending to a server only if necessary, through a much more reliable HTTP connection. The W3C is working on an API to allow for camera access, but it has yet to be incorporated by the browser vendors.
The camera is useful in several types of mobile applications, from sharing snapshots or videos of friends to capturing important events as they happen and recording visual information, such as an important advertisement or sign found while out and about. The camera can even be used to process bar codes and then to redeem promotions. Not long from now, we could see cameras that are able to translate different printed languages just by holding our mobile camera up to a sign—a technology that is already popular in Japan.
A popular feature in more recent mobile devices is the addition of an accelerometer, a small instrument that measures physical acceleration and gravity and sends data back to the device. The most common use of an accelerometer is to detect when the device is physically rotated, adjusting the display from vertical to horizontal orientation (or vice versa).
Using the accelerometer can be a benefit to mobile users, enabling them to interact with a device in a more natural way; being that the device is likely held in the hand, it can adjust content to suit its physical orientation, like rotating the screen, or detecting physical movement, and can therefore have limited prediction of the users’ context. A simple example might be that if the user is walking, detected by slight movement or velocity, the user interface might display larger text than normal to make the experience easier for users on the move.
However, developers should be cautioned against relying too heavily on the accelerometer for frivolous interactions. Every mobile interaction should pass the “transit test.” You should always assume that the user will interact with a mobile device the same way she would if she were sitting on a crowded bus or train. Ask yourself what the likelihood is that the user will shake the phone while standing in a packed subway or riding in a car. Typically, the likely answer is slim to none. So be sure to always include an alternative way to perform the same task that attracts less attention.
ACCESSING THE FILESYSTEMS
Another reason you would want to create a native application is if you want to use the data stored on the device itself. This might be the user’s address book, photos, an email message, or even data from another application.
Such filesystem access is obviously a big security and privacy issue. An errant application potentially could alter or delete your data, or worse. An infected application could use your contacts and constant connection to spread a virus to multiple phones, something that occurred quite often before widespread adoption of mobile application certification.
On the other hand, mobile devices are becoming highly personal, mobile computers that store an increasing amount of content and information about their owners and the owners’ friends and business contacts. The idea of leveraging this information across applications is appealing. Though not without risk, using stored data is a powerful way to present contextually relevant information to the user.
Developers should be cautioned to use stored information only in limited doses. We’ve seen a trend with applications that leverage too much user data without the user’s express permission as being mistakenly perceived as spamming or phishing information, even though the application was actually attempting to perform a valuable service. False perceptions of your application can and will significantly affect your ability to distribute it, either in loss of direct sales or possibly by being pulled altogether, if the operator receives enough complaints.
The rule of thumb here is to never do anything with the users’ data without their express permission to do so: a precaution far too many mobile applications skip.
Again, we are seeing some progress by the W3C to establish a standard API for mobile vendors to follow, but we aren’t there yet.
The final reason to make a native application is because you know the user is likely to be offline or out of range of a mobile network. For those of us who live in the city, that may seem like a rare occasion. Even for those who live in more rural areas, network dead spots are becoming increasingly rare. But going periods without a connection does of course happen frequently and your application should be designed to take this into account.
Think about the context of the user and when he is likely to use your application. The likelihood that a mobile game will be played on an airplane would probably be pretty high. A trail map application will likely be used in more remote areas, with less coverage. A mobile travel guide will probably be used in a foreign network, where roaming and international fees could occur. Each of these applications should have an offline mode in which the user can still perform the most common tasks of the application without the need of a wireless connection.
The mobile browsers that support HTML5 actually include the capability to create offline apps today, but it isn’t made apparent to the user. As support for offline storage increases across multiple mobile browsers, we need to define metaphors and conventions for the users to know when their mobile web application will work when the device is offline.
I find that many native applications assume reliable network connectivity far too often. Applications are often designed under the best of circumstances, in a closed environment with a healthy wireless signal and a fast network. Mobile devices by nature move from the best of circumstances to the worst quickly. Native applications should always be tested under the worst possible conditions. For example, what happens if the user starts a task with a full signal, but tries to complete it with no signal?
Users don’t think about being online or offline when they load native applications—they just expect them to work. It’s our job to make sure that they do.
When to Make a Mobile Web Application
I believe that unless your application meets one of these native application criteria, you should not create a native application, but should instead focus on building a mobile web application. Like I said before, I’m a big fan of native applications and I feel that there are a lot of great innovative and market opportunities here, but mobile web apps are the only long-term viable platform for mobile content, services, and applications.
Native applications don’t service the user better in any significant way; they only add cost to your project, decrease your distribution channels, plus cause you to lose the ability to incrementally improve your application, lose control and profit, and add to the device fragmentation problem. Plenty of short-term opportunity exists with native apps, but not without great personal risk, not to mention damaging the long-term viability of the mobile content market.
The most interesting case for mobile web apps is actually composed of the reasons stated earlier. If those are the only reasons that you need to create a native app, then what happens if you take away those obstacles from the mobile browser? Something like that is being done by Palm’s webOS. They have created an entire mobile operating system built on WebKit, turning the phone into a web browser. Your “native applications” are just web applications.
Another innovation is the PhoneGap project, an open source effort that allows you to create native applications for iPhone, Android, and BlackBerry devices, exposing many device features like location and filesystem access to your web app. These applications can be distributed and sold in device marketplaces, but they share the same code and design. And because it is a web app, we can make a less capable version of our app available for free to lower-end mobile browsers. Build once, and deploy everywhere.
For those who have spent some time in mobile development in the past, you might have noticed the omission of “If you want to create a rich experience” from the reasons why to make a native app. Although there are certainly plenty of devices out there where this still might be the case, you can now create incredibly rich interfaces with mobile web apps. Not only can they be just as compelling as native apps, but they can work across multiple device frameworks with no alterations in code.
The rate of innovation for creating mobile web apps across every mobile device maker is at its highest level in years, but more important than that, for the first time device makers are all working toward achieving the exact same standards, which just happen to be the same standards as the desktop web. In addition, the devices that either lead in mobile web app innovation or support third-party browsers that do, are becoming the top-selling devices in multiple markets.
So, instead of asking yourself, “When to make a mobile web app?” I challenge you to start asking yourself “When not to make a mobile web app?”
source : Orally Book
Comparison between Native Apps and Web Apps
|The Issues||Native Apps||Web Apps|
|Internet access||Not required||Required, except for rare apps with offline capability|
|Installation/updates||Must be deployed or downloaded||Hit refresh|
|Device compatibility||Platform-dependent, hardware-dependent||Platform-agnostic, content can be reformatted with CSS to suit any device|
|Animation/Graphics||Fast and responsive||Web apps are getting closer, but will probably always lag|
|Streaming media||Few problems with audio and video. Flash works, but only if the device supports it||Flash works where supported. Browser-based audio and video are getting there, but still beset by compatibility headaches. Give it a year or two|
|Fonts||Tight control over typefaces, layout||Almost on par, thanks to advancements in web standards. Give it six months|
|Is my content searchable?||Not on the web||By default|
|Sharable/Tweetable?||Only if you build it in||Web links are shared freely. Social APIs and widgets allow easy one-click posting|
|Discussion and collaboration||Only if you build it, and it’s more difficult if data is disparate||Discussion is easy, all data is stored on a server|
|Access to hardware sensors||Yes, all of them: camera, gyroscope, microphone, compass, accelerometer, GPS||Access through the browser is limited, though geolocation is common|
|Development||Specific tools required for some platforms (like Apple’s). You have to build a new app for each target platform||Write once, publish once, view it anywhere. Multiple tools and libraries to choose from|
|Can I sell it?||Charge whatever you want. Most app distributors take a slice, up to 30%||Advertising is tolerated, subscriptions and paywalls less so. No distribution costs beyond server fees|
|Distribution||Most app stores require approval. And you gotta wait||No such hassle|
|Outside access to your content||No, the reader must download your app||Yep, just click a link|
|Advertising||Control over design (though limited in iAds) and rate||More choices for design, plus access to web analytics. Rates vary widely|
Mobile Web Applications
Mobile Web applications offer the widest penetration into a client’s customer base. Advantages include; direct control over distribution, low development costs and faster time to market. Furthermore, since these apps run on common browsers, device-specific customization/update delivery is much simpler. Cost benefit increases as hardware fragmentation increases. XRG develops highly optimized Mobile Web applications to ensure simple, intuitive and quick access to information and e-commerce. Applications most suitable for Mobile Web include; retail and shopping, communications and news and weather publishers, where iterative design and capturing user analytics are essential.