
Native App, Web, or PWA: The Platform Decision That Changes the Design
How to choose between a native app, a web app, or a PWA based on notifications, offline use, discoverability, and the cost of maintaining several platforms.
What is each option?
A PWA (progressive web app), according to MDN, is an app built with web technologies that provides a user experience similar to a platform-specific app. It can be installed on the device, operate offline and in the background, and integrate with the device and with other installed apps. It relies on service workers and the Cache API, among other elements.
A native app is installed from the system store and is written for a specific operating system. A web app is the site opened in a browser, without installation. MDN adds that a PWA, like a website, can run on multiple platforms and devices from a single codebase.
Why does this matter for a junior designer?
Because the platform changes what you can design. A notification that reaches the lock screen, a swipe from the edge, or a screen that works in the metro without signal depend on the platform. A junior who proposes a flow without knowing whether the platform supports it may be designing something that cannot be built.
The platform also decides how people reach your product. An app goes through the store; a web app is found in search results and shared with a link. That difference affects the first experience and how you measure use. If your design starts on mobile, mobile-first explains why the platform weighs so much.
Which capabilities change by platform?
These are differences documented by the platform vendors themselves:
- Installation in Chrome. Chrome only offers to install the PWA if it meets certain criteria: a manifest with a name, 192- and 512-pixel icons, a
start_url, and a display mode such asstandalone; HTTPS; and the person must have clicked at least once and spent at least 30 seconds on the page. These are the installability criteria published by web.dev. - Bringing a PWA to the store on Android. A Trusted Web Activity opens the PWA full screen in Chrome 72 or later, with Digital Asset Links tying the app and the site to the same developer. The host app has no access to cookies or
localStorage, and each screen is either fully web or fully native. - Notifications on iOS. WebKit explained in February 2023 that, since iOS 16.4, push notifications work in web apps added to the home screen with
displayset tostandaloneorfullscreen. Permission can only be requested in response to direct user interaction. - Home Screen on iOS 26. WebKit announced in 2025 that, by default, every website added to the Home Screen opens as a web app, although people can turn it off with “Open as Web App”.
These differences change with each system version. Before deciding, check the current status in each platform’s documentation and in the version your audience uses.
What does NN/g say about apps and the web?
NN/g published “Mobile: Native Apps, Web Apps, and Hybrid Apps” in 2013, last reviewed in 2016. It remains useful as a framework even though it is old. Its main ideas: a native app is the best choice if it must work without connectivity; web apps win on discoverability, because they are found through search engines; native apps win on speed. The article adds that features such as notifications, background execution, and accelerometer data were out of the browser’s reach “at least from now”.
That last part no longer describes the present: MDN today lists notifications, background synchronization, and offline operation among the technologies of a PWA, although each browser decides what it supports. Use the NN/g article as a decision framework, not as a list of technical limits.
How do you decide, step by step?
- List the device features the product needs. Camera, sensors, notifications, contacts, payments, location, Bluetooth.
- Define offline use. What must work without signal? If the answer is “everything”, the decision leans toward a native app or a PWA with a large local cache.
- Measure how people arrive. If the product depends on search or shared links, the web wins. If it depends on the store and the trust it gives, the app wins.
- Calculate the cost of maintaining each version. Two native apps mean two design, development, and testing teams; a PWA lowers that cost but limits some features depending on the platform.
- Test the critical feature on the real platform. Reading the documentation is not enough: try the notification or the offline mode on the devices your audience uses.
For offline use in particular, the article on offline-first flows describes how to design what happens when there is no signal.
When is a PWA NOT the right choice?
- When you need critical notifications on iOS with no alternative. iOS conditions are strict. A backup channel, such as email or messaging, reduces that risk.
- When you need deep device access that a PWA does not cover. This depends on the platform and the moment; check before promising it.
- When the store is the main channel. If your audience searches in the store, a website does not appear there.
The policies of Google Play and the App Store on publishing websites wrapped in an app change over time: review them before planning that route.
Example
Illustrative example: a gym chain wants an app to book classes and record attendance.
- Device needs: notifications to remind people of the class, a QR code to enter, and optionally location to detect arrival.
- Offline use: the QR must work in the locker room, where signal is poor. That requires a local cache of the code.
- Platform: half the users have an iPhone. iOS notifications only work if the app is on the home screen, so the onboarding must ask for that installation with a clear explanation.
- Decision: a native app for entering the gym, and a web app for booking from the browser. Two channels for the same service.
The decision is not ideological. It comes from counting what each feature needs and on which platform each person will use it.
To understand how gestures change by platform, the article on mobile gestures explains why a gesture that works in an app may not have the same meaning on the web.
Common mistakes
- Choosing a platform for fashion’s sake, without counting the device features the product needs.
- Designing a critical feature without checking whether the platform supports it.
- Assuming a PWA installs the same way on iOS as on Android.
- Asking for notification permission on page load, without a user gesture.
- Assuming push notifications are reliable on iOS without testing them.
- Ignoring the cost of maintaining two platforms in the budget.
Sources
- MDN, Progressive web apps
- web.dev, Installability criteria
- Chrome for Developers, Trusted Web Activity overview
- WebKit, Web Push for web apps on iOS and iPadOS
- WebKit, News from WWDC25 (2025)
- Nielsen Norman Group, Mobile: Native Apps, Web Apps, and Hybrid Apps (2013, revised 2016)