Web app vs mobile app vs PWA: a decision matrix by device capability

Four names, four different things

"I want an app" covers four different things, and each has its own distribution, installation and limits. The question "web app vs mobile app?" often comes from these four names being mixed up. On our mobile app development page we take the same question through four questions; this article extends it by device capability. First, let us separate the names. The definitions of a PWA and a platform-specific app in the table come from MDN's comparison page; the split between a website and a web app is our own engineering definition.

The difference between a website and a web app is a tendency rather than a sharp line: a website shows everyone the same page, while a web app shows a signed-in person their own data and updates records, places orders and runs approval flows. How we build such systems is on our web application development page. A PWA is not a separate kind of technology but a web app that behaves like a platform-specific app: MDN notes that PWAs are technically still websites and need a browser engine. For cross-platform mobile apps, where one codebase ships to two operating systems, see the table on that page; we do not repeat it here.

Web app vs mobile app: a first screen in five questions

We extend the four questions on our mobile app page into a screen where every question can be answered. For each question, pick one cell for your own product. This table is our engineering judgment, not a standard; the capability detail is in the next section.

The output is one of three; the reading rule is our engineering judgment, not a standard. If all five rows land in the "Web is enough" column, the output is "mobile may not be needed." If no row is in the "Mobile app" column and at least one is in the "Consider a PWA" column, the output is "web app and PWA." If a row is in the "Mobile app" column: when it concerns a device feature or offline writing (rows 2 and 3), check the capability matrix in the next section and the test sheet first; if the browser covers the capability, the output drops to "web app and PWA," and if it does not, the output is "mobile." When it concerns frequency, store presence or audience (rows 1, 4 and 5), the output is "mobile." In every case the single row in the heaviest column decides, not the majority.

A hypothetical reading shows how to use the table; it is not a real project. Picture an internal approval app: it is opened rarely (web is enough), needs no device feature beyond camera and location (web is enough), does not need offline (web is enough), does not need to be found in a store (web is enough), and its users are known employees (web is enough). If all five rows land in the same column, the decision is clear. If the rows scatter, for example four say web but one says "offline writing," that single row can change the whole decision; that row decides, not the majority.

Every row that stays undecided is settled in the next section by looking at capability. Knowing your own answer before starting the commissioning process makes it easier to test a vendor's "it must be mobile" or "it must be web" recommendation; the scope document template in how to read a software proposal also lists a "second platform" as an example of an item to state explicitly as out of scope.

Capability matrix: what works on web, in a PWA and on mobile?

The matrix below is built from MDN, WebKit and platform documents opened and read on November 6, 2026. A capability that could not be read or whose source was unclear was left out of the table. The "Web" column describes an app running in a browser tab, and the "PWA" column an installed app. The "Mobile" column only shows that the platform documentation has an API corresponding to the capability; it carries no claim about how any app is written.

Two cautions help when reading the matrix. First, the "mobile app" column says the platform has an API for the capability; it does not say that an app using that API is easy or cheap. Second, the table shows that a capability exists, not how good it is: a PWA being able to open the camera does not mean the user experience will match a native app; the test sheet shows that too.

The matrix is dated to the publication day; browser versions and policies change. "Limited availability" means the capability may not work in your users' browsers; that is settled not by the document but by the test sheet below.

PWA on iPhone: installation, notifications and storage

iPhone is the device that raises the most questions in a PWA decision. Three concrete facts shape the article.

Installation is manual, from a menu. WebKit describes the user choosing "Add to Home Screen" from the Share menu. Before iOS 26, a site without a manifest (and without a meta tag marking it as a web app) was saved only as a home-screen bookmark; according to WebKit's Safari 26.0 post, on iOS 26 and iPadOS 26 every site added to the Home Screen opens as a web app by default, the user can turn off "Open as Web App" when adding to keep a bookmark instead, and Safari now has no installability requirements. A manifest still helps: the icons defined in it are used, and the benefits it provides become part of the user's experience. MDN writes that the beforeinstallprompt event, which triggers an install prompt from the page, is not supported on iOS. So you cannot put an "Install" button; explaining the step to the user becomes part of the product.

The notification path WebKit describes works in an app added to the Home Screen, and with permission. According to the WebKit announcement, the permission prompt must be made in response to a direct user interaction; if the user agrees, notifications appear on the Lock Screen and in Notification Center like those from other apps. The announcement covers Web Push for web apps added to the Home Screen; it describes no path for sites that have not been added.

Storage has quotas and an eviction policy. According to WebKit's storage policy post (August 2023, Safari 17 and iOS 17), localStorage, the Cache API, IndexedDB and service worker data are subject to quota limits; a quota is an upper bound, not a guarantee that the data can be stored. Data can be deleted, even if neither the user nor the site wants it, under system storage pressure, when the overall quota is exceeded, or when the site has not had user interaction for some time; eviction starts with the origin (site) that has gone unused the longest. The default mode is "best-effort," meaning persistence is not guaranteed; a site can request persistence with navigator.storage.persist(), and WebKit grants it by heuristics, for example when the site has been opened as a Home Screen web app (since on iOS 26 every site added to the Home Screen opens as a web app by default, that criterion may cover more sites there; that is our inference, and WebKit does not say it). Our judgment: data that must last lives on the server, and the device is only a cache.

The upshot: if your audience is mostly on iPhone, explaining the installation flow to users, designing when to ask for notification permission and keeping data in sync with the server become part of the design. We state no iOS version shares; measure your own audience's devices.

Do you need a store? Wrapping a PWA for the store

A store is only a distribution channel; it is an advantage if your users look for the app in the store, and not if they do not. MDN writes that an installable PWA can be packaged and distributed in the stores, and that tools like PWABuilder make this easier; the ChromeOS.dev page describes the Bubblewrap tool wrapping a PWA into an Android package for Google Play (ChromeOS.dev). But packaging does not mean skipping review. Apple's App Store Review Guideline 4.2 asks that an app include features, content and UI that elevate it beyond a repackaged website; 4.2.2 says that, other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators or a collection of links (Apple, version updated October 16, 2026). So merely wrapping a site is not a guarantee of approval.

Choosing the store route adds another cost and ownership job: rules such as the privacy declaration, account deletion and the privacy policy link are covered in the "Store rules are a cost item too" section of mobile app development cost, and whose name the developer account is opened under and who owns the review is covered in the "Store accounts, release and review" section of the mobile app development page. We do not repeat them here.

Offline: cache or data?

A service worker can cache screens and files and serve them without a network; MDN's example is an email that was written but could not be sent being sent in the background once the network is back. The availability of the Background Synchronization API used for deferred sending is limited, as you saw in the matrix. When offline writing is involved, the job changes: if two devices change the same record while offline, which one counts? Saying "it works offline" without solving that is incomplete. For a product that needs offline writing, ask your vendor or your own team these questions in writing: where on the device will a record be kept, in what order will it be sent once the connection returns, which change wins if two people change the same record, and will the user see a conflict? The answers are technical decisions and should appear in the quote as a scope line. Our judgment: read-only offline is a cache job, while offline writing is a data design job.

The article Designing for the Link You Don't Have: Offline-First Coordination for an Autonomous Survey Fleet explains the principle: on that platform, intermittent connectivity is not a failure mode but the operating condition, and concurrent writes are surfaced as conflicts instead of being silently overwritten. That article was written for a drone fleet, not for a web app; but the question of conflict resolution is the same. We do not repeat the article's numbers and details here.

Scenario table: eight typical situations

This table is our engineering judgment, not a standard. The portfolio rows only carry the sentences of the relevant card; the cards do not state a web or mobile choice (apart from the smart home card's "mobile-first"), and the recommendation is ours.

A test sheet for your own devices

The matrix rests on documents; your users' devices are a different story. Copy the table below and run it with a small prototype of your own product, or with any PWA, on iPhone, Android and desktop. "Unknown" does not count as green; write it as work to be tested.

Usage: run the tests with made-up data, not live data. Do the same test twice on the same device with the same browser and compare the results; do not write "passed" after a single attempt. The sixth test depends on time, so note the test date and look again later; the WebKit eviction policy lists "some time without interaction" as one of the conditions it mentions. If a row comes out "failed," the reason for the decision is clear: if you need that capability, a mobile app; if not, take that row out of the product scope.

How we do it

Every engagement is a paid project that starts with a written quote you approve. A clear scope, timeline and cost are in writing before anything is billed, and nothing is charged until you approve. As we say on our mobile app page, we build both, so we can offer a neutral recommendation; if the answer is web, we will say so.

Every technical decision is written down with its reasoning, and you talk directly with the engineer writing your code. On the projects we look after, we keep an eye on what yours depends on and raise what needs attention. Ownership of the delivered work transfers on full payment, as set out in our terms; and if you ever want your infrastructure moved to another team, we help you transfer it cleanly with accounts, domains and documentation. How we work is on our mobile app development and web application development pages; the steps are on the Process page. Tell us about your project.

Frequently asked questions

What is a PWA, and does it replace a mobile app?

A PWA is an app built with web technologies that can be installed like a platform-specific app and can work offline and in the background (MDN). Whether it replaces a mobile app depends: if the capabilities you need are covered in the web and PWA columns of the matrix, it does; if you need capabilities such as Bluetooth, NFC or background tasks and these do not work in your users' browsers, it does not. The decision is made with the device test.

Can a PWA send notifications on iPhone?

Yes, under conditions: according to WebKit, on iOS and iPadOS 16.4 and later, Web Push is supported for web apps added to the Home Screen; permission must be requested in response to a direct user interaction, and an Apple Developer Program membership is not required. No path is described for a site that has not been added to the Home Screen; test on your own device.

Can I put a PWA in the App Store?

There are packaging tools (MDN); but Apple's guideline 4.2 asks that an app include features, content and UI that elevate it beyond a repackaged website. So merely wrapping a site is not a guarantee of approval; approval depends on the review's decision.

What is the difference between a web app and a website?

A website is mostly content and shows everyone the same page; a web app shows a signed-in user their own data and runs business logic. There is no sharp line between them; this is our engineering definition.

Should the first version be web or mobile?

For testing a hypothesis, usually web: there is no installation and no store review, and distribution is a link. If one of the capabilities (for example Bluetooth or background tasks) is the core of the first version, mobile. To cut the scope of a first version, see our MVP development page; scope, timeline and cost become clear in the written quote.

Sources

The pages below were opened and read on November 6, 2026. Browser and platform information changes over time.

• MDN: Progressive web apps · What is a PWA · Making PWAs installable · Offline and background operation.
• MDN API pages: Push API · Background Synchronization · Web Bluetooth · getUserMedia · Geolocation · Web NFC.
• WebKit: Web Push for Web Apps on iOS and iPadOS (February 16, 2023) · Updates to Storage Policy (August 10, 2023) · WebKit Features in Safari 26.0 (September 15, 2025).
• Apple: App Store Review Guidelines (October 16, 2026) · documentation: UserNotifications, Background Tasks, Core Bluetooth, AVFoundation, Core Location, Core NFC.
• Android Developers: notifications · WorkManager and persistent work · Bluetooth Low Energy · CameraX · location · NFC.
• ChromeOS.dev: List your PWA in Google Play (no date on the page).