Thep Urai - Fotolia
Developers have been making the case for web apps over native mobile apps for many years now. Native apps, the argument says, are expensive to create and support; responsive web apps leverage a single code base and design to support all devices.
You don't have to look far to find counterpoints to the web app argument, but actions may speak louder than words in this debate. In 2016, an article on GovInsider fanned the flames of the mobile platform debate. In the piece, Ben Terret, former head of design for the U.K.'s Government Digital Service (GDS) discussed the reasons why the agency has banned native app development in favor of HTML5 web apps with a common UX framework. These reasons revolved primarily around the huge cost of building and maintaining those native mobile applications on a large scale.
Should you ban native mobile apps, too? Are they worth the cost of development? What are the criteria for making that decision?
At the iPhone's launch, the price of entry was distributing compiled Objective-C binaries through Apple's App Store. Objective-C wasn't the friendliest language for the average web developer to learn, but at least there was just one platform, and an active community quickly developed to offer support and encouragement.
That was nine years ago, and in the interim, Google launched Android with Java as its native language, HTML5 was designed and adopted by the World Wide Web Consortium (W3C) with features that made responsive web apps practical, and cross-platform libraries like Xamarin and PhoneGap (Apache Cordova) emerged that attempted to bestow the best of both worlds. After almost a decade of evolution, there are basically four paths you can take: native, cross-platform, web and hybrid apps that have some features of each.
Given a specific set of user requirements, native app development is still likely to be the most expensive path, especially in environments with heterogeneous device populations. In order to deploy on both Android and iOS devices, you will need engineers skilled in Java and either Objective-C or Apple's newer Swift language. The tool chain, deployment path, release approval criteria and support requirements are different in each case.
Moreover, because these approaches rely on users pulling compiled binaries to their devices, you cannot update the client experience without following through on a new binary release with each change set. You can surely leverage a common back end through REST APIs, but on the client side, the world will look a lot like it did in 1995.
The web and hybrid
This last point is also true of so called "hybrid apps," which are responsive web apps contained within a native binary hosting a web browser control. The application starts up, creates the web control and then the control loads the markup from a server. The advantages of a hybrid app over a straight up HTML5 app include more control over the app lifecycle, a better user experience around notifications and access to slick native effects and controls that can still be difficult to recreate in a web browser. Among the disadvantages: You still need developers who can work in the native language of the device to create and maintain the wrapper app, but most or all of the complicated user features can be done as web pages.
Which one to choose
Given these choices, why would you not follow the lead of the GDS and ban native mobile apps? There are several valid business reasons for bucking that trend, and the decision factors mostly boil down to the following two: how many different versions do you need, and how important is the tactile and visual nature of the user experience?
In situations where all of the users are on a common device platform and OS, the costs of native development are reduced, simply due to needing fewer of the things mentioned above: engineers, tools and processes. This is even more prevalent with the Android platform, where the deployment model is more open than that of iOS, or that of Windows Phone, where you can own the distribution pipeline if you need.
In terms of the client-side experience, it isn't hard to see that many organizations that continue to focus on native development are investing much of their brand capital in awesome user interfaces. Companies working on chat apps, news feeds, video streaming, gaming and other apps where a lot of the value rests on the way the client looks and feels have a strong incentive to invest in that piece.
The situation may be different for enterprise line-of-business (LOB) apps where security, information accuracy and availability are all more important considerations. Some organizations will find themselves walking both sides of that line when both internal LOB apps and broad retail customer bases expect sophisticated and smooth user experiences that delight their senses.
For the rest of us, the trend of hybrid and responsive web apps being the default choice is likely to continue. The same economic issues that made the web more attractive than the fat clients of the '90s come into play when enterprises support native apps on heterogeneous device populations, and those forces will continue to direct organizations toward tools that make it easier to create and deploy mobile applications.
Developing a native app may very well be worth it if your brand depends on competing for fickle user eyeballs, but the average enterprise LOB application will not see a big return on investment from choosing native over responsive web or hybrid application models.
Is MBaaS necessary when developing mobile apps?
Discover why UC as a service may be a viable deployment model
How to match mobile app development skills with enterprise demand