It's a mobile-crazed world, and companies and developers are struggling to keep up with the demand for consumer-facing mobile apps, and for mobilizing enterprise services and data. It's a particularly difficult problem for businesses -- Gartner says that by the end of 2017, the demand for mobile apps in enterprises will grow at least five times faster than IT can deliver them.
The problem is not just skyrocketing demand. It's that developers need to choose the right technologies for building mobile apps. Today, there are three broad choices: building native apps for each platform (iOS, Android, and Windows Phone); building a mobile Web app that can run on browsers, using HTML 5, CSS, and JavaScript; or taking a hybrid approach by building mobile Web apps, and then putting them in native wrappers so they'll run on devices like native apps do.
Native applications
Native applications are built to run on a specific mobile platform -- iOS, Android, or Windows Phone. Code is written directly for the specific hardware, and can't be ported directly from platform to platform. Development tools used to build native apps are typically provided by the owner of the platform. For example, iOS apps are typically built using Apple's XCode. Google's official platform for Android development is Android Studio. For Windows Phone it's Visual Studio.
Native apps can take full advantage of all of a device's built-in hardware, including sensors, GPS, graphics acceleration, and more. Because the apps have been written specifically for each device, they offer high performance, particularly important for games, and also useful for graphics and media apps. They're distributed via each vendor's store -- the Apple App Store, Google Play, and the Windows Store. They use common controls and have a common look-and-feel for each device, so that it's easy for users to quickly get up to speed on using them.
There are drawbacks, though. Developers with skills for writing native apps are in short supply, and charge top dollar. Those costs aren't just for the initial app. Apps need constant maintenance and bug-fixing. They also need to be updated regularly. So the high costs tend to be ongoing.
That's bad enough for an app for one platform. But if you want native apps for the two major platforms, the expense is doubled, and tripled if you include Windows Phone. And if you want a mobile Web site, you'll also need a separate mobile web development team.
Web apps built with HTML 5, CSS and JavaScript
Web-based applications are Web sites built with HTML 5, CSS, and JavaScript technologies. Unlike native applications, they aren't downloaded as apps onto mobile devices. Instead, people visit a web page on a mobile browser to run them. Keep in mind that we're not talking about static Web pages. These are full-blown apps, with the interactivity and features you'd expect. Web apps can also make use of some mobile hardware such as GPS, although the support tends to be limited for sensors.
They're easier to build than native apps because they use the same skill set as that for building non-mobile Web pages. It's easier to find Web developers than it is to find developers of native apps, so there's a larger pool of talent from which to choose.
When you build Web apps, only one code base needs to be maintained. You don't have to build multiple, separate native apps, and then have to develop each, maintain each, and make updates separately to each. Deployment is simple, via a Web server. Apps don't need to be compiled or go through the sometimes arduous process of the app store processes of Apple, Google, and Microsoft. So it's less expensive and faster to build Web apps than native apps. In addition, users don't need to download an app to use it --- they merely go to a Web page.
There are some drawbacks, though. Web apps don't tend to perform as well as native apps, although because of fast multi-core mobile processors, this is less true than it used to be. However, it's still true for games, and can also be an issue with graphics- and media-rich apps. Web apps aren't always able to take advantage of sensors on every device. They also don't have access to a device's contact lists and other kinds of data. Because they're not distributed on app stores, it may be difficult to get new users to find them, because people are accustomed to using apps they find on app stores. Their interfaces also might not look like interfaces of native apps, which can be off-putting to some users.
Hybrid applications
A hybrid application is a Web page that you've built with HTML 5, CSS, and JavaScript, that is then put in a wrapper so that it runs on a mobile device like a native app. It is downloaded to a device from an app store just like a native app. It can take advantage of most, but not necessarily all, of the sensors and other features built into each platform, such as notifications. Just like a native app, it has an icon on the home screen that you click on to run it.
As with Web apps, hybrid apps don't tend to perform as well as native apps, although fast mobile processors have made that less of an issue than in the past. However, it still matters for games, and possibly for some graphics and multimedia applications.
With hybrid applications you often first build a Web page as you would normally, using HTML 5, CSS, and JavaScript. After that, you use a platform such as the open source Apache Cordova or Adobe's PhoneGap (based on Cordova) to turn the code into a native app. There are also a variety of complete development environments that let you write the code in HTML 5, CSS, and JavaScript or in some other language, and then convert that code to run as native apps. The main benefit of this approach is that you don't have to hire multiple developers for multiple platforms. Web developers can use their skills to write mobile web pages, and tools then do the conversion to native apps. One drawback to this approach is that the resulting apps often don't look like native apps and have the same interface and controls that native apps do.
Making the decision
So what should your organization do --- go native, use HTML 5, or deploy a hybrid approach? To decide, you need to take a long look at your mobile needs, resources, and timeline, says Forrester analyst Michael Facemire, who has co-authored a number of reports about the topic, including "Web, Hybrid, And Native Mobile Apps All Have Their Place."
"First take a look at the kind of app you're looking to create," he says. "Is it a business-to-consumer app, or instead business-to-business or business-to-employee app?"
For the moment, he says, "there is gravity around using native apps for business-to-consumer" because he believes they generally offer a better user experience than Web apps or hybrid apps. That user experience is particularly important for brands who want to show "thought leadership" in mobile, he says. In addition, he believes consumers have become used to finding new apps in app stores, which makes native apps superior to Web-based apps for reaching consumers.
However, for business-to-business and business-to-employee apps, he recommends going with either Web-based apps, or taking a hybrid approach. "HTML 5 can do whatever businesses and enterprises need, and so a hybrid or Web app is the way to go," he says. "Doing it that way reduces costs, and makes upgrading and maintenance easier."
According to a Forrester developer survey, in 2014, 31 percent of developers were writing native apps, 27 percent were writing Web-based apps, 22 percent were writing hybrid apps, and 12 percent were using a "cross-platform" approach in which they wrote code in a platform such as Xamarin, which is not based on HTML 5. Facemire believes it would be a mistake for companies to standardize on only one approach. "Saying you should only build native apps, mobile websites, or hybrid apps would be very short-sighted," he says. "Match development to your needs. A company may want to build native apps for their consumer apps, but go with the mobile Web for their internal use, such as company directories."
Will the Web surpass native apps?
Matt Asay, vice president of mobile for Adobe, agrees with Facemire that it's a waste of time and money to build native apps if they will only be used for company employees.
"I'm struggling to think of why you would ever build a native app in that instance," he says. "With internal apps, you're not competing against Uber, you're not competing against other consumer-based apps. There's no reason for all that cost."
Asay goes beyond that, though. He believes that in general, native apps are a passing phase, and eventually almost all apps will be Web-based ones. So that, he says, is where companies should focus their development work.
"As an industry, we've thought that apps are the only thing that matters, and we've forgotten about the Web," he says. "That's going to change over time. We started with native applications on desktops, and over time most applications migrated to the Web. You're going to see the same thing happen with mobile as well -- the Web will become more important than native apps."
One reason for that, he believes, is the near-impossibility of creating an app that people will find and download from an app store.
"If you're an independent publisher, your chance of your app standing out are basically less than zero," he says. "Because of that, independent developers would be better off developing a Web-based app."
People can get to the Web-based app in multiple ways. They can type it into their browser, get to it from their bookmarks, or can pin it to their home screen. When it's pinned, the icon looks like a native app.
As for well-known brands, people know the brands' URLs, so there's no need to create an app to build visibility and brand awareness, he believes. He also says that for online retailers, the mobile Web is superior to apps.
"The head of mobile for a major retailer that does several billion dollars of sales a year in mobile told me that 90 percent of his mobile traffic is from the Web, not the company's native app. So why should he spend all that time and money continuing to build a native app?"
Using a centralized API
Tom Dale, co-creator of Ember.js, a JavaScript development framework, believes that there's a way to future-proof mobile development so that one need not make an all-or-nothing decision among native app development, mobile Web development, or hybrid development. He says companies should build a common API that can be used by all development methods.
"Take a tech startup that's small and has no market. Usually they'll start with an iOS app or maybe an Android app," he says. "For that app, you need to build an API on the back end. So it makes sense to build an API in such a way that it can be used by a native app, a mobile Web page, hybrid app, and even a desktop app."
He agrees with Asay that eventually most mobile development will migrate to the mobile Web and away from native and hybrid apps. One advantage of native apps will eventually go away he says.
"Native apps have had the advantage of accessing all those sensors. But at some point, there will be no new sensors built into mobile devices. They'll be mature, and then Web-based apps will catch up and be able to access them as well."
The upshot
The upshot for developers? For now, native apps are best for companies that are building consumer-facing apps, need their design and interface to stand out, and want top performance, for example, for games. Web-based apps are best-suited for internal apps, B2B and internal apps. Hybrid apps take the middle ground between the two, allowing apps to look somewhat like native apps, but are built using Web standards.
For more help in deciding which to choose, see the accompanying snapshots, which provides a look at the pros and cons of each method, and includes a list of development tools for each.
This story, "How to choose the best mobile development environment" was originally published by ITworld.