Web apps and native apps are trade-offs
A native app is built for one phone system and installed from a store. A web app is a web page that runs in the browser and can be added to the home screen. Neither is always better.
This lesson shows how to choose between them from what the product needs. This module teaches the web platform, so the lab has no emulator and no store, and native tools are not part of it.
By the end of this lesson
Note
I can choose between a web app and a native app from a set of requirements.
Key words
| Word | What it means |
|---|---|
| Native app | an app built for one phone system and installed from a store |
| Web app | an app that runs in the browser and is reached by a link |
| Permission | a person's yes to the app using a feature, such as the camera |
| Distribution | how an app reaches people, such as a link or a store |
| Trade-off | a gain that costs something else |
The cells students fill in are left blank in this preview.
What a web app does well
A web app has one set of code for every phone and laptop. People open it from a link, with no store and no install. You update it by changing the files, and everybody has the new version at once.
It can also be added to the home screen, work offline with a service worker, and keep data on the device.
What a native app does well
A native app can use more of the phone. It can run in the background, talk to nearby devices over Bluetooth, and draw heavy 3D graphics at full speed.
It is found in a store, which gives it reach and a way to take payment. The cost is a separate build for each phone system, and a review before each update goes out.
Worked example: web and native side by side
| Question | Web app | Native app |
|---|---|---|
| How do people get it? | Open a link | Install from a store |
| How do updates arrive? | At once, when you change the files | After a store review |
| How many code bases? | One | One for each phone system |
| Use of device features? | What the browser allows | Wide access, with permissions |
| Work in the background? | Limited | Much more possible |
| Battery and speed? | Fine for forms and lists | Better for heavy graphics |
The cells students fill in are left blank in this preview.
Find the device features the app uses
docker exec jupyter grep -o "navigator\.[a-zA-Z]*" app/app.jsShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
What the command prints
The command searches the habit tracker's script for anything it asks the browser's navigator for. It prints one line, navigator.serviceWorker, the feature that keeps files for offline use.
The app uses no camera, no location and no Bluetooth, so it needs no permission from a person. That is one reason a simple tracker suits the web.
Permissions are a person's yes to a feature
A camera, a location or notifications need a person's permission. The browser asks, and the person can say no. Both kinds of app ask, but a store app often asks once at install, while a web app asks at the moment of use.
Ask for a permission only when it is needed, and explain why in your own words first.
A common mistake
Warning
Many people think a native app is always faster, or that a web app can do anything a native app can. Both are wrong. A simple form or list feels the same in either. A feature the browser does not offer, such as steady background work, cannot be added by clever code.