The right answer to the question posed in the headline is, simply, yes. Depending on the scope, depth and complexity of a given mobile application and its intended deployment, any of these three approaches will work. The more interesting perspective however is one in which the three approaches are not viewed as being mutually exclusive. Depending on how simply an application may initially be scoped and the possibility of that application becoming significantly complex over time, an application could conceivably go through iterations that cross all three approaches.
The scenarios shown below define the approaches available for building mobile applications.
Native mobile applications - those apps using the core programming languages, APIs and features directly associated with a given mobile OS and specific mobile device features - will always be reserved for any applications requiring the highest possible levels of computing performance and the highest levels of graphics - such as intensive real time business analytics processing a great deal of data
Pure Mobile HTML5 Web Apps - as the HTML5 standard becomes more robust, and as third party HTML5 platform vendors such as appMobi deliver increasingly robust functionality to HTML5, the need for either native or third party APIs from mobile app platform vendors becomes less and less of a requirement for delivering applications that are hard to distinguish from native or hybrid counterparts
Mobile Web applications - mobile apps that are entirely browser-based and that are able to run in any mobile browser environment - including those browsers found on feature phones. Such mobile apps are critical for the simple reason that the largest percentage of mobile phones by far on a global basis is still that of feature phones. Mobile Web apps are easy enough to create with the right mobile app development platform partner, but while apps that run on feature phones can be fairly sophisticated, they will always be far more limited in capability than their smartphone counterparts. The key point is that the right app development platform will allow building the complex app while automatically handling the transition to less complex, browser-based feature phones - as well as also automatically handling the differences between upwards of 10,000+ different feature phone types
Which of the mobile applications shown below is a native app and which is a hybrid app? It doesn't matter. That is the key development point to understand in today's marketplace - look, feel and functionality are rapidly evolving to be equal across the board for each type of mobile application.
In the early days of mobility - circa pre-launch of the iPhone, approximately up until early Q4 2007 - all mobile application development was essentially an exercise in developing native applications that were closely tied to any given specific device and the specific version of the mobile operating system supporting that device. Application development was an inherently slow process, applications were not, in any sense of the term, “cross-platform capable” and they were inherently, if not notoriously, difficult to develop within a “pilot, field test, tweak and quickly redeploy as needed” scenario.
Even when enterprises worked specifically with veteran mobile application platform vendors - such as Antenna,Verivo Software (formerly Pyxis) and various iterations of Sybase, or with difficult to use Java-based tools from the likes of Research in Motion — the process of mobile application development simply remained hard to do. There were also simple platforms available (such as from Volantis, now a part of Antenna) that produced browser-based mobile Web applications based on simple menus and menu-based navigation. Such applications lacked easy to use UIs, and tended to be simple in terms of overall functionality. Does anyone remember WAP (wireless application protocol)?
This lack of enterprise “mobile application quality” is a key reason why prior to the iPhone’s launch mobility had been slow to catch on outside of field service operations — many people in the mobile industry often wondered in those days what it would take to jump start mobility and to turn it into the dynamic industry most of us had anticipated since at least 2003.
And then the iPhone launched.
An Entire Generation Skipped
The impact of the iPhone - as well as iOS and the mobile ecosystem Apple had the foresight to not only invent but to also make real - cannot be understated. Literally overnight the world was transformed from a static to a dynamic mobile environment. Shortly thereafter Google followed with Android, and both the consumer and enterprise markets became rich with complex and native mobile applications. Android and iOS — along with the key mobile device vendors that immediately got behind Android in order to compete with the iPhone — started a revolution - there is nothing “evolutionary” about iOS or Android.
The industry missed an entire generation — it didn’t evolve in an orderly fashion from a “static” pre-iPhone period to a dynamic post-iPhone period. The entire industry moved in one revolutionary swoop in less than a year. Along with that move came sophisticated new mobile applications, a major emphasis on ease of use and exciting and enticing user interfaces - along with sophisticated operating systems, and the sophisticated devices that now drive BYOD (Bring Your Own Device) and enterprise willingness to adopt and adapt to BYOD.
From an enterprise mobile application perspective this mobile revolution and BYOD have created a number of problems. Chief among a variety of issues are the following:
The need to build sophisticated applications quickly that will run across different smart mobile devices — smartphones, tablets - regardless of operating system, and that look and behave exactly the same across all platforms
The need to securely manage these apps, ensure proper version control, and their controlled actual distribution to employees and partners (for B2B apps) or to consumers (for B2C apps)
The desire to build an effective enterprise mobile app store (something that will eventually simply become an “app store,” with “mobile” factored out over time, likely before we hit the end of the decade)
Verivo Software economically sums this process up as a “Design, Publish and Manage” cycle. Antenna Software takes it several steps further, and defines the mobile application cycle as consisting of the following steps:
Design - Typically using a drag and drop approach
Build - Drive designs into actual mobile applications
Integrate - Tie mobile applications into back end systems
Publish - Publish (deploy) the mobile app to an app store (Apple, Android, Windows, BlackBerry) or to a custom and enterprise-branded app store (in Antenna’s case, using its AMP Storefront)
Run - Run mobile apps through either a mobile cloud infrastructure or on-premise
Manage - Control and management of an entire enterprise mobile operation and deployments, ideally through a single console; management of an enterprise app store
Analyze - Use granular analytics to fine tune both application performance (how the mobile app itself behaves) and application awareness (improving app discovery amongst potential users, especially in B2C deployments)
These seven stages - whether utilizing Antenna’s platform or any other - are key to not only the overall mobile application development process, but also integral to whichever approach proves the best for a given app. These seven steps remain the same whether a mobile app is ultimately deployed as a native, hybrid or pure Web app.
From Design to Published Mobile App
The design process will typically be the same process regardless of the complexity of a given application. Overall functionality and capability can grow in complexity, but basic core UI functionality should remain the same throughout. A UI can more easily begin life as a Web app — which makes user testing, re-design and re-test an easy process. If, or as, a mobile app becomes more complex, it can easily grow from a pure Web app to a hybrid app, or possibly to a native app design.
The build and integration stages will typically determine what approach will be taken to create the actual mobile application. As with the UI, an application can begin life built as a pure HTML5 Web app; a Web app can in turn be “up-scaled” to include the greater functionality of a hybrid app; finally a mobile app that is particularly complex to execute (perhaps because it needs a great deal of processor and graphics optimization, or access to special device functionality not otherwise available through hybrid APIs) can be further up-scaled to be delivered as a pure, native app.
A key advantage of native mobile applications is that they can be deployed to operate even when there is no wireless connection in place, either to the enterprise or to the Internet. The ability to work in disconnected mode is a key feature of native mobile apps. HTML5 however, has blurred the line because it is able to store a non-trivial amount of data directly on a smart mobile device, so that, to a fairly significant extent, users can continue to work even when an HTML5 app loses its connection. It is not by any means as robust a capability as native apps offer, but it is good enough in many cases. This was often the clean line of demarcation between native and non-native apps, but it is no longer the case thanks to HTML5’s flexibility and capabilities.
The publish phase is ultimately the most critical in terms of the flexibility an enterprise will have in being able to control mobile applications from start to finish. A native-build application for iOS will always have to appear via Apple’s App Store before it can be run (although Apple is making progress to give enterprises more flexibility). A native Android application doesn’t have that requirement, but Google Play (formerly known as the Android Marketplace) is necessary if no other enterprise storefront solution is available.
Work with a Trusted Partner
Though HTML5 makes it easier to develop mobile apps, and in some cases will eliminate a number of complexity headaches, it isn’t a panacea. In particular, for both the publish and manage stages of mobile app deployment, it offers no simplicity at all.
Nor is it our intent here to suggest that HTML5 makes it easy to bring mobile application development entirely in-house. A trusted mobile app development platform partner is still, we believe, the best asset an enterprise can have in hand, especially in terms of evaluating options and making the decision to pursue a native or non-native hybrid or pure HTML5 approach. Building on top of a mobile app development platform is still critical to succeed, regardless of the development approach.