In the PWA vs native app decision, a PWA is enough when the app displays data, takes orders, bookings or forms, uses the camera and location only while it is open, and users reach it from a link, an email or a QR code. An app from a store is needed when it has to work in the background (route tracking, sync), connect to devices over Bluetooth or NFC on iPhone, show widgets, or when being in the App Store and Google Play is in itself a client requirement.
The choice between these options too often comes down to "an app sounds more serious". That is an expensive hunch: an app in the stores means two developer accounts, a review of every version, yearly tooling requirements and sometimes a commission on sales. A PWA has none of these costs, but it does have hard limits, especially on iPhone. Below we lay out both.
- Start with the feature list. Most decisions come down to one question: does the app have to do something while it is closed.
- Push notifications from a PWA have worked on iPhone since iOS 16.4, but only after the app has been added to the home screen.
- Bluetooth, NFC, background work and widgets still require an app installed from a store, at least on iPhone.
- An app in the stores means ongoing costs: an Apple account paid for every year, a closed test in Google Play for new personal accounts and raising the tooling versions every year.
- A PWA and an app can use the same backend, so starting with a PWA does not rule out an app in the future.
PWA vs native app: the feature list first, then the technology
The decision gets easier if you write down everything the app is supposed to do before the words "PWA" or "native" are even mentioned. Not in general terms ("convenient customer service"), but as actions: a customer scans the code on a parcel, a courier records their route all day, an employee approves a leave request, a customer gets an appointment reminder the day before.
Tag each action with three questions. Does it need access to the phone's hardware, and if so, to what: the camera, location, Bluetooth, NFC, sensors. Does it have to work when the app is closed or the phone is lying locked. Does it have to work offline, and if so, is it about viewing data or about saving it and syncing it later.
After this analysis, it usually turns out that the choice is decided by one or two features, not by the whole scope. An app with forty form screens and one feature that tracks a route in the background needs a native or cross-platform app because of that one feature. An app with two screens but no background work at all will probably manage without a store.
The second question is who will use the app. Customers who deal with the company once or a few times a year rarely install anything from a store. Employees who use the app every day will install whatever the company tells them to. Regular users of a consumer service, for example a fitness app, expect to find it in the store and look for it there.
What a PWA can do in 2026 on Android and iPhone
A PWA, or progressive web app, is a website with a manifest file and a script that runs in the background of the browser (a service worker). Thanks to these, it can be added to the home screen, launched without the address bar, work partly offline and receive notifications. What it can do depends on the browser and the operating system, though, and the differences between Android and iPhone are large.
| Feature | Android (Chrome) | iPhone (Safari and other browsers) | App from a store |
|---|---|---|---|
| Icon on the home screen | yes, with an install prompt | yes, manually via the Share menu | yes |
| Push notifications | yes, also in the browser | yes since iOS 16.4, only after adding to the home screen | yes |
| Camera and code scanning | yes | yes | yes |
| Location while the app is open | yes | yes | yes |
| Location in the background | no | no | yes |
| Offline use (data saved earlier) | yes | yes | yes |
| Background sync once the network returns | yes | no | yes |
| Bluetooth | yes (Web Bluetooth) | no | yes |
| NFC | yes (Web NFC) | no | yes |
| Fingerprint or face login (passkeys) | yes | yes | yes |
| Apple Pay and Google Pay | yes | yes | yes |
| Home screen widgets | no | no | yes |
| Presence in an app store | possible via a TWA wrapper | requires an app with features beyond the website | yes |
The table reveals a pattern that repeats in practice. On Android, a PWA has access to most hardware features, so an app for Android users, for example an internal warehouse app on company devices, can do without a store even with Bluetooth and NFC. On iPhone the same features are unavailable, so an app for customers in general, who include iPhone users, has to be designed around the weakest platform.
The reason for the differences is the browser engine. Popular browsers on iPhone use the WebKit engine, so in practice Chrome on iPhone can do the same as Safari. Access to new interfaces for web apps on iPhone therefore depends on the decisions of a single company, not on which browser the user chooses.
The table describes the state of things in 2026, and it is worth checking again when you make the decision. Browser capabilities change every few months, and a single new feature in Safari can change the outcome of the whole analysis. Current support for a specific feature is easy to check in public browser compatibility tables.
Push notifications on iPhone: they work, with a condition
For years, the lack of push notifications on iPhone was the main argument against PWAs. Since iOS and iPadOS 16.4, web apps can send notifications, but only if the user has first added them to the home screen. An ordinary website open in Safari still cannot ask for permission to send notifications.
This means two steps the iPhone user has to take themselves. First they open the website, choose the Share menu and the option to add it to the home screen. Then they launch the app from the icon, and only then, after tapping a button in the app, can they agree to notifications. The permission request has to result from an action by the user, so it cannot be shown automatically at launch.
For some uses this process is acceptable. An employee who is shown the instructions during training will do it once and forget about it. A regular customer who uses the service every week will do it if they get clear instructions with pictures and a reason why the notifications are useful to them. A one-off customer of an online store will almost certainly not do it.
So before choosing a PWA because of notifications, answer the question of what share of your users are on iPhones, and whether notifications are a convenience for them or a condition for the service to work at all. If an appointment reminder is a nice extra on top of an email and a text message, a PWA is enough. If the whole service relies on an instant notification, for example about a new job for a courier, an app from a store is the safer choice.
On Android, notifications from a PWA also work without installation, in an ordinary Chrome tab. If your users are mainly Android owners, for example employees with company phones, the iPhone limitation may not affect you at all.
Installation and distribution: a link versus an app store
You distribute a PWA with a link. You send it by email, print it as a QR code, put it on your website. The user clicks and uses the app straight away, with no store account, no downloading of dozens of megabytes and no waiting. Adding it to the home screen is optional and can happen later, once the user decides they will be coming back.
An app from a store has to be installed before it is used for the first time. Every step between clicking a link and the app's first screen is a point at which some people give up: going to the store, downloading, launching, system permissions, registration. For services someone uses once, for example ordering at a restaurant table, this path is too long.
The store does have advantages a link cannot give, though. Users search it for apps by category and name, so your app can be found by people who do not know your company. Being in the store with ratings and a download count builds credibility. Some clients, especially in business-to-business sales, require an app from a store, because their IT departments manage work phones through systems that allow only apps from the stores.
Links are also worth keeping in mind. A link in an email that leads to a specific PWA screen always works, because it is an ordinary web address. In an app from a store, similar links have to be configured separately for iOS and Android, and when the app is not installed, the link needs a sensible fallback address. That is extra work a PWA does not need.
The cost of getting into the stores: accounts, tests, reviews
Publishing in the App Store requires membership of the Apple Developer Program, which costs USD 99 a year. If you do not renew the membership, the app disappears from the store. A Google Play account costs a one-off USD 25. Both fees are small compared with the cost of building the app, but the Apple account is a recurring cost for the whole life of the app.
New personal accounts in Google Play have an additional requirement. Personal accounts created after 13 November 2023 must, before publishing, run a closed test with at least 12 testers who stay opted in continuously for 14 days. Organisation accounts are exempt from this. If the app is to be published on your company's account, set the account up as an organisation, because you will save two weeks and the hunt for testers.
Every version of the app goes through a store review. Apple's review checks compliance with its guidelines, including the minimum functionality requirement: an app that is nothing more than a wrapped website with no added value may be rejected. A rejection means fixes and resubmission, which on a first release can push the date back by several days.
On top of the entry costs come the store materials: screenshots in the required sizes, descriptions, a privacy policy and declarations about the data collected. Apple and Google require a detailed description of what data the app collects and what it uses it for. That is work where technology meets law, and a PWA on the company website does not require it in this form.
Store commissions: when they apply to you and when they do not
App stores take a commission on sales of digital content and services inside the app. In the App Store the standard commission is 30%, and for developers in the small business programme, with revenue of up to USD 1 million a year, it is 15%. Google Play takes 15% of the first USD 1 million of revenue each year and 15% on subscriptions. In the European Union, Apple also offers alternative terms resulting from the Digital Markets Act, which change this calculation, so before you decide, check the terms that currently apply to your case.
The commission does not apply to everything you sell through the app. Physical goods and services delivered outside the app, for example a food order, a ride, a visit to the hairdresser or a product from an online store, can be paid for with ordinary payment methods, without the store's payment system. The commission applies to digital content and features: premium subscriptions, video courses, virtual items, unlocking features.
For companies selling digital services, this is one of the strongest arguments for a PWA. A subscription bought on a website does not go through any store, so the whole amount goes to you, minus only the payment provider's fee. Some companies combine both models: the app from the store is used to access the service, and the purchase happens on the website, within the limits the current store rules allow.
An example calculation, based on assumptions made purely for illustration: a subscription of PLN 40 a month, 500 active subscribers, a 15% store commission and a 2% payment provider fee on the website. In the app store, the commission comes to 500 x PLN 40 x 15% = PLN 3,000 a month. On the website, it is 500 x PLN 40 x 2% = PLN 400 a month. The difference of PLN 2,600 a month adds up to PLN 31,200 over a year. Set that amount against the cost of building and maintaining the app before you treat being in the store as a given.
Maintenance: yearly store requirements and the speed of updates
An app in a store needs regular work even if you add no features. Since 28 April 2026, Apple accepts new apps and updates only if they are built with Xcode 26 and the iOS 26 SDK. Since 31 August 2026, Google Play has required new apps and updates to target Android 16 (API 36). Both stores raise these requirements every year.
In practice, this means that an app nobody has updated for a year can no longer be updated without first adapting it to the new tools. When an urgent bug appears, you first have to raise the versions of the tools and libraries, and only then fix the problem. It is worth planning for this in the budget as a fixed item, not as a once-a-year surprise.
A PWA does not have this problem. An update means deploying a new version to the server, and the next time they launch the app, users get the new version, with no review and no waiting for someone to tap "update". A fix for a critical bug reaches everyone within minutes. In an app from a store, the same fix waits for review, and then for users to install the update.
Apps written in cross-platform frameworks can partly narrow this gap. In many cases, changes to the interface layer and the app logic can be sent directly to users without a full review, within the limits the store rules allow. Changes that involve native modules, permissions and the system version still require a new version in the store.
Offline, background work and access to hardware
Offline mode in a PWA works well when it comes to viewing data. The service worker can store screens and data on the device, so the app opens without internet access and shows the most recently downloaded information. You can also save the data entered locally and send it to the server the next time the app is launched with network access.
The problem starts when data has to be sent without the user doing anything. On Android, a PWA can sync pending data in the background once the connection returns. On iPhone this mechanism is not available, so the data will only be sent when the app is opened again. For a service technician who fills in reports in a basement with no signal and closes the app before leaving, this means a risk that the data will reach the server only the next day.
Background work is a line a PWA does not cross on any platform. Tracking location with the screen locked, counting steps, playing and controlling audio the way dedicated players do, periodic data sync, reacting to getting close to a specific place: all of this requires an app from a store. If any of these features is in your scope, no further analysis is needed.
Access to hardware splits by platform. The camera, microphone, location while the app is open, vibration and screen orientation work in a PWA everywhere. Bluetooth and NFC work in Chrome on Android, but not on iPhone. Integrations with health data, watches, the car's system or the voice assistant are available only to native apps.
Do not keep the only copy of important data in a PWA's storage. The browser can delete data saved by a website, for example when the device is running out of space. Treat local data as a buffer and let the server be the source of truth.
When a PWA is enough
A PWA is a good choice for a company's internal tools. A panel for sales reps, an app for reporting faults, approving requests, viewing orders and stock levels. The users are known, they can be shown how to add the app to the home screen, and the company avoids publishing in the app stores an app that is not meant for anyone outside the team. When a tool like this makes sense in place of a spreadsheet is something we describe in our post admin panel instead of a spreadsheet.
The second case is services the customer uses occasionally or only once. Ordering at the table, booking an appointment, tracking a parcel, filing a complaint, registering for an event. The customer reaches the service from a link or a QR code and does not want to install anything. Every installation step reduces the number of people who make it to the end.
The third case is digital products sold by subscription, for which the store commission would be a big cost and whose features do not require background work. Course platforms, planning tools, booking systems for businesses, analytics dashboards. Here a PWA lets you keep the whole margin and update the product without reviews.
The fourth case is testing a product before investing in an app. A PWA with the key features lets you check whether users come back, which features get used and whether notifications make sense. That data is a much better basis for a decision about a store app than the assumptions made at the idea stage.
When you need an app in the store
An app from a store is necessary when the core feature requires background work. Apps for drivers and couriers that track the route, fitness apps that record activity, apps for monitoring devices that have to react to events with the screen locked. These features cannot be worked around in a browser.
The second situation is connecting to physical devices when your users include iPhone owners. Controlling devices over Bluetooth, reading NFC tags, pairing IoT hardware. On Android, some of this can be done in a PWA, but a product for customers in general cannot leave iPhones out.
The third situation is apps in which notifications are the core of the service and the users are consumers who cannot be put through training. Messaging apps, apps for couriers who accept jobs, apps with safety alerts. The requirement to add a PWA to the home screen before notifications can be enabled on iPhone means that some users will never get them.
The fourth situation is a business one, not a technical one. A corporate client requires an app in the store because it manages its employees' phones through a system that allows only apps from the stores. A consumer product competes with apps that users find in the store, and being there is part of the strategy for reaching people. In such cases, an app from a store is needed regardless of what the browser can do.
The middle way: a PWA now, an app in the store later
The choice does not have to be final. The most important architectural decision is to separate the backend, meaning the server with the data and business logic, from the app that displays it. If the PWA talks to the server through an API, a native or cross-platform app built later uses the same API and the same data. The work put into the backend is not lost.
On Android, a PWA can be published in Google Play without a rewrite, as a Trusted Web Activity. This is a lightweight app that displays the PWA full screen, without the browser bar, and in the store it looks like any other app. For many uses, this is enough to be in Google's store at zero cost for rewriting the interface.
On iPhone, a similar wrapper is risky. The App Store guidelines require minimum functionality that goes beyond a website, and an app that is only a wrapped website may be rejected. If you need an app in the App Store, plan features that justify its existence: notifications, integrations with the system, offline use beyond what the website offers.
It is also worth taking platform risk into account. In early 2024, Apple announced that it would disable web apps added to the home screen for users in the European Union, and a few weeks later it backed down from that decision. The episode showed that what PWAs can do on iPhone depends on the decisions of a single company. For an internal tool this is an acceptable risk, but for a product the whole business rests on, it is an argument for having a fallback plan.
How to prepare a quote request and what it costs
The price of an app depends on the number of screens, hardware features, integrations and platforms, and the choice between a PWA and an app from a store changes it more than any single feature. That is why a quote request is best based on the feature list from the first section of this article, marking which features need background work, Bluetooth, NFC or notifications.
A PWA is a web app, so it is priced much like a web platform or a panel. Our prices start at: Mobile Apps from PLN 749, Web Platforms from PLN 899, Panels & Dashboards from PLN 699, Integrations & Automation from PLN 299. These are "from" values for the simplest scope, not packages. For a general outline we give a price range, and a specific figure once the scope, deadline and requirements have been agreed. We describe the scopes on our pages for mobile apps, web platforms and panels.
We usually split the payment into three parts: a deposit, halfway through the project and on handover. The price includes a buffer for fixes equal to 15% of the project time, and during the work you have access to the repository and the test version. On handover you get full rights to the code and documentation, so another contractor can develop the app, and monitoring is free, usually for 90 days. We sign an NDA on request.
If you do not know whether your project needs an app in the store, send us your feature list via the contact form. Quotes are free, we reply within an hour and you talk to the person who writes the code, so a question about whether a given feature will work in a PWA on iPhone gets an answer straight away, not after being passed on.
