Given the profusion of mobile applications and the high demand for mobile developers and skills, if you are a software industry decision-maker you’ve probably been confronted with producing a mobile application. If not, you almost certainly will be soon.
Warning. This article has potential to stimulate feelings of controversy, so let me say from the start that the intent of this article is not to make a blanket recommendation. Instead, it is intended to give a very high level look at both sides of the app-versus-browser decision.
I chose this topic because it’s relevant to a recent decision I had to make, necessary for the continued growth of our company. At Stout, we use a proprietary online system for customer relationship management (CRM). This system is implemented on a widely used commercial platform with an Open Source database. Given the high amount of out-of-office time spent by our team, we badly needed a smartphone interface to the system. One of the decisions we had to make was whether to develop a native app for 2-3 mobile devices or a single browser-based version adapted for smartphone use. (Yes, even we haven’t standardized on a single smartphone platform.)
Mobile apps are hot. The mobile app market is projected by some experts to grow in an explosive progression to $30-40 billion worldwide within 2 years. That makes it a market worth considering by any company with a commercial application.
Popular, sleek, cheap (usually) and easy to use, mobile apps have, in many cases, replaced Web surfing by delivering content directly to users. While media content delivered by an app is silo’ed, in theory the user just needs to download another app to get other content. Of course, that can result in having to download a lot of apps, as well as continually update them.
The downside, and it’s a very real consideration you must take into account, is that mobile apps are platform-specific. To create an app requires a developer with specialized knowledge and experience. It also means that the platform and developer tool knowledge must become part of a company’s core competence for it to successfully maintain its commercial apps. So there are additional cost-of-entry and cost-of-staying-in-the-game factors with native apps. For example, developing a commercial iPhone app necessitates a knowledge of Objective C and the Coco platform, which are Apple iOS specific. It also necessitates a willingness to obtain an Apple license and work through Apple’s approval process when releasing a commercial app to the store. Oh yes, there’s the 30% Apple gets as a sales royalty. And when the iOS undergoes an upgrade, it may force software changes to the app, and if so, rapid turnaround is necessary to avoid complaints.
If you intend to profit from your mobile app, you also have a business concern to consider: developing an app for multiple platforms means that you must be do your homework in your market and be very confident that your app is going to be a commercial success. After all, you are going to need to employ developers with different competencies to create and maintain multiple versions, and that development time is going to cost you something.
Apps were originally envisioned by Apple as browser-based, accessible by widgets. That vision changed quickly. While current browser technology is inadequate and slow to effectively implement fully functioning apps, there are changes coming and you should know about them.
HTML5 will be with us likely in two years. If you aren’t up on this technology, in a nutshell, it’s not simply the next version of HTML, but rather a set of Web standards, with the capability to run applications within a Web browser. It’s designed to support contemporary multimedia and graphics without having to use proprietary programming interfaces (APIs) and plugins. Since HTML5 applications are browser-based, the user experience will be the same across all kinds of mobile devices.
Like mobile applications, users of HTML5 applications will be able to download and cache data while online, then access that data later when working offline.
HTML5 will embrace both HTML and XHTML and retain the human-readability and browser-friendly parsing enjoyed by earlier versions, making it highly accessible, even to non-technical people. As such, the coding, testing and debugging cycles would be reduced from that of native mobile apps.
A potential risk of HTML5 is shared by any standard implemented by multiple vendors: different browsers could implement the standard a bit differently, requiring HTML5 apps to be thoroughly tested using multiple browsers before being released.
Stout has several times been through the process of developing commercial native applications for the Android and iPhone for customers, so had no trepidation about working in this arena. Stout also has its own iPhone app in the Apple Store, so we have been through the trials of the app approval and ongoing support process; here is a link to a SlideShare presentation about our experiences developing our app, iSoBusy: http://slidesha.re/IXRQkf.
At Stout, we took all of the above factors into account in deciding how to implement our proprietary CRM system on mobile devices. Stout’s ultimate decision was to implement a browser-based smartphone-compatible version. Here’s why: