Mobile apps unleash a world of capabilities. Commonly used to bond with family and friends through social media and picture-sharing, as well as to pass time with games, they also provide businesses and organizations the ability to work and collaborate on-the-go with a variety of productivity tools, such as Microsoft Office Mobile. They allow us to receive the latest news and events instantly through alerts, push notifications and so much more. Mobile apps work with us (and for us), designed to support a variety of features that enhance the end-user experience when interacting with a company’s or organization’s information and services.

Evolving trends, techniques and toolsets continue to refine how best to build mobile apps, be they for businesses or consumers. As with every year, there comes a host of new mobile advancements and best practices for developers—most recently new-wave JavaScript and citizen developers. However, one longstanding mobile battle continues to overshadow all other developments: the debate between native apps and Web apps.

(Related: Where does mobile testing fit in an IoT world?)

Originally, native apps were the only reliable method to develop and deploy a reasonable mobile app. However, a new approach has come into the mix. In 2015, Alex Russell, a Google Engineer, improved upon existing techniques, including the dynamic Web, Responsive Web Design and new features in HTML5. He introduced the mobile development world to a strategy coined “Progressive Web Apps,” a series of technologies and techniques to build a Web app that acts much like a native app. A Progressive Web App (PWA) is a Web app with additional characteristics, such as a native-like interface, the ability to build a relationship with the end user over time, and the capacity to function in low- to no-bandwidth situations.

In this article, we will explore the most recent headway in the mobile app realm. We will review native, progressive Web and hybrid solutions to mobile apps and the pros and cons of each. By the end of this article you will walk away with a better understanding of the current state of mobile app development, as well as a plan to help determine which method is best for you and your organization.

Driving factors of a successful mobile app
Deciding whether to pour resources into a native or mobile Web app can be a tough call for many businesses and organizations. However, targeting mobile users opens up a wealth of possibilities, so the decision to invest is very important. Currently there are a variety of factors found in successful mobile apps that contribute to user adoption that all mobile app developers should address.

One of the most important characteristics of a successful mobile app is the user interface design. An ideal UI is one that is clean, intuitive and easy to navigate. Through both functionality and customization you convey the main purpose of the app to your users, in addition to setting the guidelines for how and why they use it.

Functionality includes not only the required features to match the needs of your app, but also fast load times, smooth scrolling and accessibility. If your users run into long, unexplained wait times, or an app has a disjointed or jerky experience, app uninstallation is sure to follow.

Successful mobile apps should also include customization abilities. End users are looking for apps that respond to and remember their preferences and personal requirements. Apps require logins should utilize open, accepted standards such as Facebook, Twitter or other OAuth authentication as users prefer not to have to remember multiple accounts. Utilizing social media for authentication also allows mobile apps to provide a sharing mechanism that may be used to drive buzz and excitement around their experience.

With an expected UI and a desired end-user experience in mind, you should then ask yourself, based on your app requirements, what is the best approach to develop your app? Should you go native, Web app or something in between?

Native apps
Native apps, or mobile applications that are built in the native language of a particular device’s operating system, continue to be the go-to solution for most app developers. In a June 2015 survey by Statista, 86% of end-users’ time spent on mobile devices was dedicated to native mobile apps. Native apps provide the most customizable, responsive end-user experience because they can tap into a mobile device’s “native” features.

Pros: Higher performance, app store approval (which provides safety, security and support), and easy accessibility are among some of the many reasons to use native apps, according to Moovweb. Further, through a variety of alerts and push notifications they keep users engaged every step of the way. By tapping into the native UI components of an operating system, developers can get as close to the native OS bits as possible to capture a unique look and feel that runs quickly and smoothly.

The native app approach can also allow for optimum performance, both online and offline, with the ability to access a variety of an OS’ native components, such as the camera, GPS or accelerometer. There is a reason why native apps have been around so long: They offer an end-user experience that is unparalleled by the Web, according to About.com.

Cons: Native apps by definition are developed for one particular mobile platform at a time, such that if you build an app for iOS, it will not function or perform on another device such as Android. This is the native app’s Achilles heel.

In today’s environment, it may be cost-prohibitive to build, test and support an app for even just one type of device. In order to not alienate a large segment of mobile users, multiple app development groups may be required to build and support native apps across device types within an organization. This approach may be neither cost- nor time-effective. Consider the time it may take to build one app for one device; now multiply that by the types of devices you want to support.

In addition, once the app is completed, it must be approved by the app store before it is put on sale and/or available for downloading. Apps are subject to the will and whims of each App Store operator. Plus, if any app updates are needed (as they always are) they must be pushed through the App Store as well.

Web apps
Web apps, or applications that are built to be used in a common browser and delivered in real time via the Internet, have been available to mobile app developers since the first iPhone. Web apps are built using standard HTML, CSS and JavaScript. While this makes development, testing and cross-device support much more straightforward than native apps, and thus extremely appealing, there remains shortcomings that relegate them as a second-tier solution.

Web app shortfalls include limited access to a device’s features (i.e. camera, GPS and accelerometer), performance issues inflicted by the browser, and UI limitations due to HTML/CSS/JavaScript. Not to mention they have one of the biggest requirements: a reliable network connection. With these limitations in mind, a new approach was introduced: the progressive Web app (PWA).

Progressive Web apps
PWAs seek to produce the same user experience as that of a native app, but rather than downloading an application, a PWA employs your browser. PWAs attempt to tap into the best of both worlds. They intend to leverage the benefits of Web apps, such as their HTML base and cross-platform availability, while still addressing their shortcomings, including their UI and touch, personalization, access in low to no bandwidth situations and deployment to the home screen.

You can think of a PWA as a Web page or set of Web pages, utilized by a person via their device’s browser, originally loaded via a standard Website URL. A PWA Web page set utilizes HTML/HTML5, CSS3, media queries, and JavaScript/jQuery. It also uses a Web Manifest (a JSON-based manifest that describes a Web app), a service worker and an application shell architecture to provide a native app-like experience that is feature-rich, fast loading, responsive, secure, and has the ability to acclimate to each particular user.

Additionally, the application shell framework and the service worker make all of this possible.

Service workers: One of a Web app’s biggest issues in the past was the ability to access information or content both online as well as in a low- or no-bandwidth situation. The requirement for always-available, high-quality bandwidth greatly limited Web apps’ acceptance. Services workers look to solve this limitation by effectively acting as a JavaScript-based proxy between the Web page and the back-end server that is handling the request.

Using the Web manifest, a Web page may register the service worker with the browser. The Web page then begins talking to the service worker, not the Web server. The Web page stops worrying about the Web server in question; it simply makes a request to the service worker, and the service worker provides a response dependent on the PWA developers’ requirements.

Service workers have a state unlike the general Web. They are able to respond to push notifications from the back-end Web server, sync background data, receive updates, maintain cached data, and provide an experience for the front-end PWA so that the app may work even with no bandwidth.

App shell: The app shell provides the key component that allows for fast load times of a general PWA, as well as for the ability for the service worker to do much of its job. The App Shell is used to store the general interface and design (or shell) of the PWA. The app shell itself is primarily the HTML/CSS/JavaScript required to provide the general wrapper of the PWA. It is stored in the browser’s cache and utilized by the service worker to provide an always-available application interface, even while additional content or data is being retrieved from the Web server.

The app shell and the service worker come together to increase both speed and functionality. While the app shell provides a native-like interface in terms of UI and design, the service worker provides the glue that allows the overall PWA to be responsive and quick.

Pros: Preferences for Web apps stem from their ability to offer affordable cross-platform development solutions. The main appeal of going progressive is the ability to code once for multiple devices, in addition to saving both time and money. Going progressive also alleviates the burden of App Stores by removing delays when updating a mobile app. Service workers increase the ability for the app to work despite limited internet availability and quality.

As Alex Russell stated at the Chrome Dev Summit 2015, Progressive Apps are “low friction”—they don’t require as much clicking and loading. A recurring roadblock with those developing native apps is the amount of time and money it takes them to develop an app and then market it. The low-friction environment enforced by the Web can increase users, while providing cost savings for development.

Cons: As promising as PWAs are, the techniques are new and not fully vetted. PWAs still do not provide access to all native features such as the camera and GPS. They do not work on older browsers/devices. Also, as painful as getting a native app approved in an App Store can be, once in, the App Store does provide a measure of credibility. With PWAs, app developers must find ways to get visitors to find and use their Web app outside of the App store.

PWAs do show great long-term promise, but what happens when we combine native and Web apps? Can we get the best of both? Possibly.

Comparing strategies
After weighing the pros and cons of each approach it is clear that a native/hybrid approach is still the most reliable solution for most app developers. However, there is no single solution for everyone. The correct development path continues to come down to weighing app requirements vs. time and cost.

In particular, native apps are best for consumer apps, as well as apps that largely use 3D-rendered graphics. This includes highly interactive, real-time games and other apps that require a high level of processing power. When an app must load extra fast, even when not connected to the Internet, or when an app is looking to squeeze every CPU cycle out of the bare metal, native is the only choice.

True mobile Web apps, including those based off of Progressive Web App concepts are best for business-line applications that are created for a particular organization. These apps can provide a responsive experience that is the most simple to maintain, (including across device types) as there is no app store and the code can be used across most devices and browsers.

When looking at hybrid and cross-platform approaches, React Native is based on JavaScript and thus good for JavaScript developers and those who prefer MVC. Xamarin is geared toward .NET developers as code is written in C# and uses primary MVVM. If you prefer to work using HTML5/CSS/JavaScript, then you may also consider PhoneGap/Cordova or Trigger.io.

By providing a native shell that uses a WebView, an app gets a chrome-less browser that can include components such as a native UI and native navigation while at the same time pulling in content from a Web app that may be used across platforms as well as maintained outside the app store. In this case, consider a cross-device development platform tailored to your language choice.

A path forward
When trying to decide the right approach for developing a new mobile app, consider the following path. Due to the ease of deployment and cross-device support, start with an investigation into PWAs. If your app requirements are not met, then before jumping into true native, look into a hybrid approach. Look at a platform/framework that uses a preferred language, then expend the search to other platforms if app requirements continue to exceed limitations.

If you are still unable to accomplish what you need, then there is nothing wrong with falling back to full native development. Just be aware that you will have to develop and maintain a specific app per device market segment.

Building a mobile app requires the consideration of many factors—among the most important: purpose, function and audience. However, at the end of the day, it is clear that in order for your mobile app to be successful (be it native, Web or hybrid), it must feel integrated and work seamlessly with the device in question.