PWA or native app: what a web app can and cannot do
A progressive web app is a website that installs to the home screen, keeps working offline with whatever it has stored, and can send notifications, and once it has logins and your own data behind it, it is a step 04 build: EUR 3.500 to 7.500 over 6 to 12 weeks. A native app is a separate product for the App Store and Google Play, it is not on our price ladder, and you need one only when your product depends on something the phone gives to native code and keeps from the browser.
The simpler option first: you may not need an app
If the goal is that customers can find you and get in touch from a phone, a well built responsive website already does that, and it starts at step 01, EUR 600 to 900. Opening hours do not need an app.
An app of either kind earns its place when the same person comes back to do something repeatedly: check a booking, log a session, reorder, see their own account. Try this test. Describe what a customer does on their third visit. If you cannot, build the website and come back to this page later.
What a PWA actually is
Under the name there are three ordinary parts. A website. A manifest, which is a small file giving the app its name, icon and colours. And a service worker, a script that sits between the app and the network and can answer from stored files when there is no connection.
Installed, it opens in its own window without the browser bar and looks like an app. It is still one codebase at one address. When we deploy a fix, every user has it the next time they open it, with no store review and nobody stuck on last year's version.
What it can and cannot do on a phone
| Capability | PWA on Android | PWA on iPhone | Native app |
|---|---|---|---|
| Install to the home screen | Yes, and the site can show an install button | Yes, but the visitor has to choose Add to Home Screen from the share menu | Yes, from the store |
| Work offline with stored content | Yes | Yes | Yes |
| Push notifications | Yes | Yes, since iOS 16.4, and only after it is installed | Yes |
| Camera, photo upload, location while open | Yes | Yes | Yes |
| Sign in with Face ID or a fingerprint | Yes, through passkeys | Yes, through passkeys | Yes |
| Location tracking with the app closed | No | No | Yes |
| Bluetooth devices | Yes, in Chrome | No | Yes |
| Health data and home screen widgets | No | No | Yes |
| A listing in the store | Possible on Google Play through a wrapper | Not as a plain website in a wrapper | Yes |
Read the iPhone column twice. Everything in it works, but installing is a manual step your customer has to know about, and notifications only exist after that step. A plan that needs push to reach iPhone users who have installed nothing does not work on the web.
Background work is the other hard edge. A closed web app on an iPhone can receive a notification and do very little else. Android allows a bit more, not enough to count steps or follow a delivery route with the phone in a pocket.
The platform owners also set the rules. In early 2024 Apple announced it would remove home screen web apps in the EU, then reversed the decision. They still work, but the ground under a PWA belongs to someone else, as it does under a native app.
What native adds, and what it costs beyond the build
Native gets you everything in the right hand column, a place in the store, and the trust some customers attach to seeing an app there. It also gets you two platforms to build for, or a cross-platform framework to maintain, store review before every release, users running old versions you still have to support, and store billing rules on any digital goods sold inside the app.
There is a middle route: a wrapper such as Capacitor puts the web app inside a native shell with some native features added. It then goes through store review like any other app. Our price ladder covers web builds only, so we will not put a number on native here.
What moves the price of a PWA
Making a web app installable is the small part. The cost sits behind it.
- Showing stored pages offline is straightforward. Letting someone change data offline and merging it safely when they reconnect is real engineering, and across many customers it moves the project toward step 05.
- Sending a notification is easy. Deciding who gets which one, and when, needs a server and rules.
- Login, roles, a dashboard, an API, a CRM connection or payments make it step 04 on their own.
| What you actually need | Step | Price | Timeline |
|---|---|---|---|
| One page that works well on phones, with a form and analytics | 01 | EUR 600 to 900 | 1 to 2 weeks |
| A business website with service pages, a CMS and booking or contact | 03 | EUR 1.500 to 3.500 | 3 to 6 weeks |
| An installable app with login, dashboard, notifications or payments | 04 | EUR 3.500 to 7.500 | 6 to 12 weeks |
| A platform with offline editing, billing and an admin for many customers | 05 | From EUR 7.500 | After discovery |
Process and timeline
Scoping comes first and ends in a fixed quote. For step 05 it is a discovery phase. Then design, then build, then testing on a real iPhone and a real Android phone, since the table above is where the surprises live. Week ranges are on our price list, and how we build is on design and engineering.
Two decisions belong to you: which screens must work offline, and what the notifications say. This is the part that waits on you, and an answer to both before design starts keeps the calendar honest.
You own the code, the repository and the database. We can host it, agreed per project. After launch, Care at EUR 100 to 300 a month covers updates, monitoring, backups and small fixes. It does not cover a redesign or new features.
When to spend less
- If the app idea is really a way to be on the home screen, skip it. A fast mobile site does the job.
- If you do not yet know whether people will use it, put a step 01 page up with a waitlist form and analytics, and read the numbers before you commission step 04.
- If your product truly needs background tracking, Bluetooth on iPhone or health data, do not build a PWA first in the hope of converting it. Then do not hire us yet. Talk to a native team, and come back when you need the website around it.
Common questions
Can a PWA go in the App Store?
Not as a website in a wrapper. Apple's review guidelines turn away apps that amount to a repackaged site. Google Play accepts a PWA through a Trusted Web Activity wrapper, and the Microsoft Store accepts them too. If an App Store listing is a requirement, plan for native or a wrapper with native features.
Will my customers know how to install it on an iPhone?
Not unless you show them. There is no install button a site can trigger in Safari, so the app itself should explain the share menu step at the moment it matters, for example right after someone books. Android users get a proper prompt.
Can we start with a PWA and go native later?
Yes. The API, the database and the business rules carry over, because a native app would talk to the same backend. The screens get rebuilt. The code and the data are already yours, so nothing is held back.
Does a PWA help us in search?
Its public pages are ordinary web pages that search engines can index. Screens behind a login are not indexed on either route. If search matters, SEO foundation is a one-off EUR 450 to 750 and applies to the public side.
Tell us what the app has to do on a phone and we will tell you whether the web can do it. Start here.
Building something?
JP Studio designs and builds websites, storefronts and product interfaces.