PWA or mobile app: what your business really needs

“We need an app.” It is one of the things I hear most often when a business starts to grow. Sometimes it is true, but very often what is really needed is for customers to book, check or order from their phone in two taps, and that does not always mean going through the App Store and Google Play. Between a regular website and a native app there is a middle option that covers more and more cases: the PWA, or progressive web app.

In this article I explain what a PWA is, what it can and cannot do today (especially on iPhone, where the most surprising limitations are), how it differs from a native or hybrid app, and what hidden costs come with publishing in the app stores. By the end you will have a few simple questions to decide what suits your business, without being swayed by trends or by whoever wants to sell you the most expensive project.

A PWA is a web application built with standard web technologies that behaves like an app: it can be added to the phone's home screen, opens full screen without the browser bar, can keep working on a poor connection and, in many cases, send notifications. Underneath it is still a website: it is visited from a URL, it updates as soon as you publish changes on the server, and Google can index its content.

Technically, two pieces turn a website into a PWA: a manifest (a small file that defines the name, the icon and how the app opens) and a service worker, a script that lives on the device and decides what to cache, how to respond when there is no connection and how to receive push notifications. If you want to dig deeper, the Progressive Web Apps guide on web.dev is the most complete reference.

What a PWA is not: it is not an app downloaded from the App Store by default, it does not have full access to the phone's hardware, and it is not an old website with an icon stuck on top. A good PWA is designed for mobile from day one, with a fast, touch-friendly interface, just as you would build any custom web application.

Web capabilities have come a long way in recent years. With a well-built PWA you can offer your customers:

• Installation on the home screen, with its own icon and opening as a standalone app.
• Offline or low-connectivity use: the main screens and recent data are stored on the device.
• Push notifications to flag an appointment, an order that is ready or a new message, with the user's permission.
• Access to phone features such as the camera, geolocation or sharing content with other apps.
• Instant updates: you ship an improvement and every user has it the next time they open the app, with no reviews or downloads.
• A single codebase that runs on Android, iPhone, tablets and desktop.
• Visibility on Google, because the public content is still an indexable, linkable website.

For many businesses that already covers everything they had in mind when they said “we want an app”: letting customers book, pay, check their history or get a reminder without having to look up the website every time.

Here comes the small print. On Android, Chrome treats PWAs almost as first-class citizens: it can show an install prompt and your site can offer its own “Install” button. On iPhone and iPad the story is different, and it is worth knowing before you decide:

• There is no automatic install prompt. Safari does not let a website trigger an install button: users have to tap Share and choose “Add to Home Screen”. That is why PWAs that work well on iPhone include a small visual guide explaining those steps.
• Since iOS 26, adding a website to the home screen opens it as an app by default, as the WebKit team itself announced in its Safari 26 overview. It is a step forward, but adding it is still a manual gesture.
• Push notifications have existed since iOS 16.4, but only for websites added to the home screen and after the user grants permission. If your customer does not install the PWA, they will not get your notifications on iPhone.
• Some hardware features are not available in Safari, such as Web Bluetooth or Web NFC, nor the background sync that Chrome offers on Android.
• Local storage is not a permanent archive. The system may clear stored data from websites that have not been used for a while, so anything important must live on the server, not only on the device.

There is also an element of uncertainty: Apple decides what Safari supports and when. In 2024, for instance, it announced it would remove home screen web apps in the European Union to comply with the Digital Markets Act, and reversed course a few weeks later. They work today, but it is a reminder that on iOS you depend on the decisions of a single manufacturer.

A native app is written with each platform's own tools: Swift for iOS and Kotlin for Android. It has full device access, the best possible performance and integrates with everything the operating system offers: widgets, background tasks, Bluetooth, NFC, in-app payments or Siri shortcuts. The downside is that, in practice, they are two separate apps to build and maintain.

A hybrid or cross-platform app is written once with frameworks such as React Native or Flutter and compiled for both platforms. It is published in the stores like any other app, reaches almost all the hardware through plugins and costs far less than two native apps. For most small businesses that need to be in the stores, it is the sensible starting point.

Both share something that is often forgotten: they need a backend. The app is the visible face, but the data, users, payments and notifications live on a server with its API, database and admin panel. That backend is the same one a PWA would need, so it is not an argument for or against, but it is a cost that must be in the budget from the start.

Building the app is only the first invoice. Publishing and maintaining an app in the stores brings costs and obligations that a PWA does not have:

1. 1Developer accounts: Apple charges an annual fee for its developer program and Google Play a one-time registration fee.
2. 2Review of every release: each update goes through store review, which can take time or reject the release for reasons you have to fix before publishing.
3. 3Mandatory platform updates: iOS and Android change every year, and Google Play requires apps to target recent Android versions to keep accepting updates. An app nobody touches eventually gets left behind.
4. 4Listings, screenshots and privacy labels: you have to prepare and maintain each store listing and declare what data the app collects.
5. 5Commissions: if you sell digital content or services inside the app, the stores take a cut of each sale. Physical goods and in-person services are usually exempt, but it is worth checking for your case.
6. 6Users on old versions: not everyone updates, so the backend has to stay compatible with several app versions at once.

None of this is a drama if the app delivers real value, but it is a recurring cost you need to face squarely. Just as a website needs maintenance, an app needs it even more, because on top of the server you have to look after code installed on thousands of phones you do not control.

A PWA is usually the best option when what you want is convenience and a presence on your customer's phone, not advanced hardware features. These are the cases where I almost always recommend it:

• Bookings and appointments: hair salons, clinics, gyms or academies where customers book and get reminders. If this is your case, I cover it in more depth in the article on online bookings and appointments.
• Client portals and internal tools: checking orders, downloading documents or logging the team's work.
• Orders and catalogues: restaurant menus with ordering, catalogues for sales reps or orders from trade customers.
• Businesses that live off Google: if most of your customers find you through search, a PWA keeps the website's rankings and can also be installed.
• Tight budgets or projects that need validating: a single codebase, no stores or reviews, and changes go live instantly.

There are projects where squeezing everything into a PWA is just fooling yourself. Going to the stores is worth it when:

• You need features the web does not offer on iPhone: Bluetooth with devices, NFC, continuous background location tracking or deep system integration.
• Your business depends on reliable notifications on iPhone for users who will not add a website to their home screen.
• The app is the product itself and is used daily for long stretches: a social network, a training app or a field tool with a lot of offline work.
• You want the stores to be an acquisition channel, because your audience searches for solutions directly in the App Store or Google Play.
• There are very high graphics or performance requirements, as with games or video editing.

The decision does not have to be forever. A strategy that works very well for small businesses is to start with a well-built PWA, measure how customers use it and, only if needs appear that the web cannot cover, move to a store app. If the backend is designed from the start as a clean API, the future app reuses all that work: users, data, payments and business logic.

That way you invest first in what creates value (the service, the processes, the experience) and leave the most expensive part for when you have real data. It is the same approach I take with any web development project: build just enough, measure and grow on a solid foundation instead of rebuilding everything the following year.

Before asking for a quote, answer these questions honestly. They will save you weeks of going round in circles:

1. 1What must your customer be able to do on their phone that they cannot do with your website today?
2. 2Do any of those features need hardware that Safari does not offer, such as Bluetooth, NFC or background location?
3. 3How often will they use it? Once a month does not justify anyone downloading an app; daily, maybe it does.
4. 4Where do your customers come from: Google, social media, word of mouth or the app stores?
5. 5Do you have budget not only to build it, but to keep it updated for years?

The useful question is not “PWA or app?” but “what does my customer need to do, and where will they do it?”. For most small businesses, a well-built PWA handles bookings, orders, private areas and notifications at a much lower cost and with far less maintenance. Native and hybrid apps have their place when hardware, heavy daily use or the stores are part of the business. Knowing the iPhone limitations in advance avoids the worst possible scenario: discovering them once the project is finished.

I'm Elmar Mamedova, a full stack developer based in Málaga, and I spend a good part of my work persuading clients not to spend on what they do not need yet. I build PWAs, web applications and backends ready to grow into an app if that day ever comes. If you are torn between one and the other, tell me about your idea and I will give you an honest opinion, even if the answer is that you do not need either of them yet.