PWAs vs native apps: Which should you choose?

Which approach should you take when building an app? Should you take up the PWA/web technologies route or should you go native and design for specific platforms? Both options have their pros and cons, and in this article we concentrate on a few of the popular choices used to create web and native apps.

PWAs (Progressive Web Apps) aka web apps, are built with popular web technologies HTML, CSS and JavaScript and work in a web browser. (Check out some of the essential HTML tags to help with your builds.) PWAs are effectively mobile websites designed to look like an app, and the use of web APIs gives them functionality similar to a native app.

Progressive Web Apps have the advantage of being installable and live on a device without the need for an app store. And, part of the process is the Web App Manifest which allows developers to control how an app appears and how it's launched. Also, web designers/front end developers will already have the skillset needed to start building immediately. There's no need to learn a new language, unlike native apps.

Native apps are built with a specific OS in mind – ie. iOS and Android – and use a framework or language to fulfil that purpose. iOS applications typically use Xcode or Swift, and Android apps, JavaScript. But, for this article we concentrate on a couple of JavaScript-based open source frameworks – React Native and NativeScript – that work for both platforms.

The advantages of native apps is that they typically bring better functionality as they make better use of a devices hardware and software, are faster and more responsive and you get quality assurance though ratings in app stores. But, it will mean having to learn how to use a specific framework or library.

Here we look at three different options – one for web (PWAs) and two for native (React Native, NativeScript) – for building an app. We run through how they operate, what they can do and look at their strengths and weaknesses to help you decide which option you should choose to build your app.

In this approach, we don’t need to package and sign the resources of our app: we just host the files in a web server and the service worker will be responsible for caching the files in the client and serve them after installation. This also means if an app needs updating, you just change the files on the server and the service worker’s logic will be responsible for updating them on users’ devices without user or app store intervention.

In terms of distribution, the most common method is the browser. Users install the app from the browser by using the Add to Home Screen or Install menu item, by accepting an invitation to install or by using a custom web app user interface on compatible platforms. It is worth noting that Apple rejects pure PWAs published in the App Store and encourages web developers to distribute it through Safari.

The user interface is purely managed by the web runtime, which means the web designer is responsible for rendering each control on the screen. If you use a UI framework, such as Ionic, or a Material Design library, HTML and CSS will mimic native interfaces on Android or iOS but it’s not mandatory. When doing PWAs, applying web performance techniques is mandatory in order to keep a good user experience.

In terms of abilities, a PWA will have access only to APIs available in the browser engine on that platform and it can’t be extended with native code – with the exception of app store PWA distributions. In this matter, iOS and iPadOS are the more limited platforms for PWAs, while Chrome (for Android and desktop OSs) has more availability and is working hard to add every possible API to JavaScript with the Fugu project.

However, all the JavaScript code will be executed in a JavaScript virtual machine on-device, so there is no JavaScript to real native code conversion when compiling the app. There is a set of well-known APIs for web developers, such as the Fetch API, WebSockets and the browser’s timers: setInterval and requestAnimationFrame. Other abilities are deployed in the platform through custom APIs, such as animations.

Your JavaScript or TypeScript code (transpiled) is executed in an on-device JavaScript virtual machine with a bridge to/from the native environment. In that bridge, the entire native APIs from Android or iOS/iPadOS are exposed so despite having access to cross-platform APIs, we can instantiate or call any Java or Objective-C code from JavaScript/TypeScript and NativeScript will marshal data types.