Progressive Web Apps: The Non-Technical Guide Part 2

This is part 2 of a multi-part guide to progressive web apps for those who do not have advanced knowledge of web technologies. Part 1 of the guide introduced progressive web apps and how they differ from native apps. This post compares the two technologies in more depth with a focus on the reasons you might choose one over the other. A future post will explore the middle ground between the two technologies, native apps built using frameworks like React Native.

Now that you know what native apps and progressive web apps are, how do you go about deciding which is the right format for you? The answer can be complex, but ultimately comes down to balancing 3 factors:

1. cost of development;
2. technical requirements; and
3. distribution expectations.

Let’s look at each of these in a bit of detail.

1. Cost of development

While it is impossible to talk about precise figures in a guide like this (your cost of development will ultimately depend on the requirements of the app), progressive web apps will be cheaper to develop than equivalent native apps.

The reason for this relates to the programming languages which progressive web apps and native apps are written in. As we saw in the last part of this guide, progressive web apps are essentially enhanced mobile friendly websites. This means that a progressive web app can be written once in the prevailing languages of the web (HTML, CSS and JavaScript). While some features will not be supported on all phones (more on this below), the experience can be tailored to provide a baseline working minimum with a single codebase.

Native apps on the other hand have to be written in or compiled to a language that the smartphone operating system understands. Unfortunately, these languages differ depending on the operating system (Android understands Java, while iOS understands Swift or Objective C). In addition, the libraries used to interface with the phones’ native features (such as the GPS, camera, microphone and accelerometer) are different. This means that any native app will need to be developed at least twice: once for Android and once for iOS. On top of that, you will probably still want to have a website with at least some of the functionality of the app. While there will be a possibility to share code between the apps you have developed, such sharing will be limited and the process for getting apps listed on the App Store and PlayStore will always be separate.

This duplicate development will result in extra cost. The long and the short of it is that native apps will be more expensive to develop than progressive web apps. So why would you choose to develop a native app?

You might have to raid your piggy bank to develop a native app

2. Technical Requirements

One possible answer to this question is technical requirements: either (i) your app needs access to a smartphone feature that is not available (or only patchily available) to progressive web apps or (ii) your app needs to run smoothly while making a lot of complex computations (i.e. it’s a game).

Some smartphone features which were typically the reserve of native apps are now available in progressive web apps; for example GPS, push notifications, accessing the phones files and working offline. Other features, such as detecting device motion and bluetooth & NFC connectivity are coming to progressive web apps. However, the support for advanced features like these in progressive web apps remains subject to the operating system and browser the smartphone user is running (with Android being ahead of iOS and Chrome being ahead of other browsers in most instances). In addition, some features, such as access to the user’s contacts, are not available in progressive web apps and there are no plans to make them available. For more detail on the features that are potentially available to progressive web apps (and an indication as to whether your phone & browser support them) head over to this site (an example screenshot is below).

Screenshot from https://whatwebcando.today

The discussion of technical requirements would not be complete without mentioning the elephant in the room for progressive web apps: Safari still doesn’t support the main technology powering offline support. While there are promising signs that this will be developed in the long run, a fully featured offline experience is not possible with a progressive web app running on Safari on iOS. With this (and the patchy support for other advanced technologies) in mind, it is really worth thinking about what the requirements of your app are before making a decision between a progressive web app or native app.

(We won’t spend any time discussing graphically advanced game development within progressive web apps. In short, while there are promising developments in the use of the GPU by browsers, this remains an area where native generally wins.)

3. Distribution expectations

In part 1 of this guide, we saw that the main difference between progressive web apps and native apps is how they are distributed. Only native apps can be installed from the App Store or PlayStore. If you want your app to be distributed on one of these stores it has to be native but, before you make this decision, it is worth noting some interesting statistics:

• It is hard to be discovered and make money from App Store listings. Recent statistics show that 94% of App Store revenue comes from just 1% of the monetising apps on the store (U.S. statistics from May 2016).
• A part of this is down to difficulties with discoverability. 60% of Apps have never been downloaded according to statistics on this Google video.
• Data has also shown that for each step in your apps install and use process, you can lose 20% of your users. This means that your user funnel (after you have been discovered on the app store) can look like the following:

Source: http://blog.gaborcselle.com/2012/10/every-step-costs-you-20-of-users.html

• A case study from Google demonstrates that the amount of data required to be downloaded can be significantly reduced in a progressive web app versus a native app (in the case study the figure was a 92% reduction). This is a major consideration if you are worried about the data connections of your users (for example, a lot of the apps created by PastPortal are targeting tourists who may be using roaming or free wi-fi for their data).
• The commission for most sales made on the App Store or Play Store are 30%. If this isn’t economically viable, you will need to make your users set up an account with payment details on the web and login to the native app downloaded from the store. Even if you do this, there are instances where Apple have blocked apps from being listed in the App Store if they don’t agree with the process you use (have you ever wondered why the Kindle app for iOS doesn’t allow you to buy books? Now you know).

While native apps have a monopoly over app store distribution, it is the drawbacks of this distribution method that have led many influential commentators to predict that native apps will die (for example, you can see the less tech heavy article by Eric Elliot on this subject).

A Middle Way?

In this part of our guide we have looked at the main factors you will need to consider when deciding between progressive web apps and their native counterparts. However, there is a third type of app that we haven’t discussed yet: an app created with a framework (like React Native) that allows it to be written once and separately compiled for distribution as a native app on the major app stores.

The next part of this guide will discuss the pros and cons to using such a framework. Make sure you don’t miss out on the next part of this guide by following the PastPortal publication on Medium. Alternatively, head here to sign up for our email list.