Native Apps vs Mobile Web: Comparing and Contrasting
Let’s use this understanding of mobile apps being locally-installed and device specific and mobile web being centrally-hosted and device agnostic to further compare and contrast each.
Supporting multiple devices is an obvious area of contrast. With mobile apps, multiple code lines need to be developed and maintained for a solution that spans different mobile operating systems. Multi-skilled teams or multi-teams with their own areas of specialization are needed for both the initial development and on-going enhancement and maintenance. A costly operation the more mobile operating systems supported. With mobile web, that cost is significantly reduced. One code line is developed and maintained irrespective of the mobile devices out there keeping in mind the effort required in ensuring cross-browser compatibility. No different to developing web solutions for desktop based browsers. Internet Explorer behaves differently to Safari and to Chrome. Catering for those subtle differences is essential to avoid end user dissatisfaction.
Solution updates are another area of contrast. With mobile web, structural updates can be applied immediately, across the entire spectrum of supported devices at once and with no intervention by the mobile device owner. The next time a website or web application is accessed, any new features are immediately available. Structural updates to mobile apps, however, need to first be approved by the respective app storefront and then ‘promoted’ for downloading. How often people update their apps in general is anyone’s guess. It’s left entirely to personal, individual whim. A process that is not as ‘immediate’ as mobile web. A provider whose existence hinges on its consumers having the most recent capability can find itself in dire straits with such latencies.
The same can be said for refreshing content. Depending on how a mobile app is developed, refreshing content may also require a physical update to the App. Or, it may not. It’s possible the mobile app is designed such that it dynamically reaches out to the internet to refresh content presented within the app. With mobile web, this isn’t even a consideration. Content refreshes are instantaneous across the spectrum of supported devices.
If monetization is a consideration, then mobile apps have a leg up although this is starting to change with advances in mobile web technologies and in particular HTML, which will be discussed further later on. So far, consumers have shown they are apt to pay for a mobile app more than they are for access to a mobile web page. This has to do more with mindset and conditioning than anything else. Right from the outset, mobile apps have only been available from ‘stores’. And as with any store, there’s an expectation that in all likelihood one is going to have to pay for goods and services including, possibly, content. People were conditioned from the beginning to be prepared to pay. The same cannot be said about the internet or mobile web. The internet has its roots in being a free medium, barring the cost of admission of course, i.e. the cost to get access to the internet itself. Once there however, one could go wherever one wanted, free of charge. Although people have grown to accept, even embrace, paying for goods online, they have struggled to pay for services, particularly content. Regardless of goods or services, the challenge many online merchants have faced is garnering repeat business. Ensuring people ‘find’ their way back to the store. Search engine optimization, social media, getting customers to ‘bookmark’ are critical to sustaining repeat business. Anything that easily points a customer [back] to the store. With apps, that paradigm is slightly different. There’s generally only one way to get to get back to the provider…open the app. And it’s easy! There’s no need to first open the internet browser and then search or browse or retrieve a bookmark. Simply open the dedicated app. And making it easy for the consumer to do transact business has a direct impact on the bottom line.
When looking at content providers specifically, certainly they have placed a heavy emphasis on mobile apps hoping that In-App subscription services will be the answer to their woeful online revenue generating experience. The form-factor of mobile devices, particularly tablets, has the potential to change that. People are more comfortable reading a book, magazine, newspaper, what have you that ‘looks and feels’ like its real-world equivalent than they are reading ‘electronic content’. And they’re willing to pay for it. Mobile apps provide that level of comfort and familiarity. Mobile web typically does not.
One thing content providers are fully cognizant of, however, is that their value diminishes to zero if content can’t be accessed. This has been one of the primary deterrents for many to commit wholeheartedly to mobile web. Without a wireless connection, its as if the content never existed. HTML5 is meant to change that, allowing for offline access to web content. Although HTML5 is being trialled by a number of organizations, it is still years away from being fully ready for wide-spread industry use according to the W3C HTML Working Group developing the standard. They plan to announce ‘Last Call’ for specification feedback in May 2011 and then will move to final testing of the standard in hopes of making it an official Recommended standard sometime in 2014. In the meantime, mobile web users will continue to succumb to ‘Network Unavailable’ from time to time. Mobile apps don’t suffer this fate, only if purposefully designed so, e.g. the app integrates with and is dependent upon web-based systems. Once installed locally on a device, mobile apps are inherently always ‘on’ and accessible. Many see this as a huge advantage, particularly in commercial scenarios where people expect to access paid content and information wherever they may be.
Another key area of contrast is the the ability to easily leverage the unique hardware capabilities of mobile devices such as accelerometers, gyroscopes, camera, GPS, microphone, etc. Mobile apps can do this seamlessly, which can bring great benefit to the overall experience. It is difficult, if not impossible, to access these device-level features through mobile web. This is why many games and action-oriented type Apps have gone the mobile app route where their livelihood depends upon incorporating the accelerometer, gyroscope and GPS into its function. Again, HTML5 is expected to address this deficiency in mobile web by providing the seamless ability to access such device-level features and capability.
If response time is critical to an apps function, then mobile apps generally have the leg up. Processing information locally will more often than not be quicker than doing so over the wireless network. One of the biggest complaints of mobile web when comparing to mobile apps is response time. According to a study by Equation Research, users expect mobile Web sites to download on mobile devices as quickly, or even more quickly than they do on desktop PC’s. That’s simply not possible with current cellular, 3G and 4G, and mobile WIFI speeds. Many providers will direct consumers to their mobile app equivalent if they ‘sense’ that the device accessing its offering through mobile web is not capable of speeds consistent with expected response times.
And then there is the question of which is more engaging? Mobile apps rely upon buttons, slide switches and rolodex-type controls. Software features that mimic real-world controls. Mobile web on the other hand are simply websites optimized, hopefully, for mobile devices. Mobile web therefore is often characterized by hyperlinks, checkboxes and pop-ups. Not the most engaging of controls on a mobile device. Once again, HTML5 is changing that where mobile app type controls are now made possible within mobile web. Jakob Neilsen, called the “guru of Web page usability” by the New York Times, has proven that mobile apps are more engaging than mobile web in various mobile web studies proclaiming “it’s more painful to use the Web on mobile phones than on desktop computers”. He went on to say his “main conclusion from watching iPhone app users is that they suffered much less misery than users in our mobile website tests. In fact, testing people using iPhone apps produced happier outcomes than testing people attempting to use websites on the same phone”.
