---
title: "Can an Installable Web App (PWA) Replace a Mobile App?"
url: https://phatdev.net/en/blog/pwa-or-native-app
lang: en
updated: 2026-10-21
alternate:
  vi: https://phatdev.net/vi/blog/pwa-or-native-app
markdown: https://phatdev.net/en/blog/pwa-or-native-app.md
---

# Can an Installable Web App (PWA) Replace a Mobile App?

> What a PWA can do on iPhone and Android in 2026: home screen install, push notifications, offline use, remaining limits and when to choose one.

Categories: Mobile apps | Published: 2026-10-21 | Level: Beginner | 6 min read

Tags: pwa, service-worker, web-push, ios, android, offline

A shop wants customers to order from their phones. One person says build an app, with a high quote and months of waiting. Another says just let the website be "installed to the home screen" and be done. The answer depends on the job.

The kind of website that installs to the home screen has a proper name: PWA, short for Progressive Web App. This post covers what it can and cannot do on iPhone and Android in 2026, so you can choose well. I checked sources on 21 October 2026: MDN, web.dev, the WebKit blog, Apple documentation and caniuse.

![A website lifting its icon off and landing on a phone's home screen](https://phatdev.net/uploads/blog/pwa-or-native-app/install-1920.webp)

## What a PWA is, in plain words

MDN describes a PWA as an app built with web technologies that gives an experience like a platform app: it can be installed, work offline, and integrate with the device. One codebase serves every device.

Think of it as an online shop with its own signboard right on the customer's phone. They tap, it opens directly, with no address bar, yet underneath it is still your website. When you update the site, everyone sees the new version without waiting for an app store review.

## Installing to the home screen

On Android, Chrome installs a PWA as a small real app (called a WebAPK) when the phone has Google services. Edge and Firefox usually create a shortcut badged with the browser instead.

On iPhone, MDN says that from iOS 16.4 a PWA can be installed from the Share menu in Safari, Chrome, Edge, Firefox and Orion. The in-page install button (the beforeinstallprompt event) is not supported on iOS, so you have to teach customers to tap Share, then Add to Home Screen. This is the biggest friction for less technical customers.

Newer: WebKit's post on Safari 26 (beta at the time) says that by default every website added to the Home Screen opens as a web app, and users can switch this off with an "Open as Web App" toggle. Since that comes from a beta announcement, test on a real phone before promising anything to customers.

In Europe, Apple once planned to drop this feature while complying with the DMA, then said it would keep supporting it, and it came back with iOS 17.4 in March 2024.

## Working offline

Offline support relies on a background script called a service worker. Think of a doorman: when the customer opens the app, it checks for a connection, and if there is none it hands over the copy saved on the phone. MDN names two main stores: Cache for interface files, and IndexedDB for structured data.

![A phone with cached storage, a crossed-out cloud, content still on screen and a bell nearby](https://phatdev.net/uploads/blog/pwa-or-native-app/offline-1920.webp)

This suits catalogues people revisit, tickets already opened, and to-do lists. It does not suit anything needing fresh data every second, like live stock or payments. Those need a connection whether it is an app or a website.

One limit to know: Background Sync (scheduling a send for when the connection returns, even after the app is closed) works in Chrome, but caniuse lists it as unsupported in Safari on iOS in every version up to 27.2, and Firefox lacks it too. So if you need "sync quietly after closing the app", a PWA on iPhone cannot do it yet.

## Push notifications

A push notification is a message that appears on the lock screen even when the customer has not opened the app. The WebKit blog says that from iOS and iPadOS 16.4, a web app added to the Home Screen can ask permission to send notifications. Three conditions apply: it must be on the Home Screen first, the permission request must come from a user action such as tapping an "Enable notifications" button, and you use the standard Push API, Notifications API and Service Workers. You do not need an Apple Developer membership.

So on iPhone, a customer who has not installed the PWA will not get notifications. Android is easier. If notifications are the heart of your business (reminders, order updates), think about how many customers will actually do the install step.

## When to choose a PWA

It fits when you are a shop or service that needs a phone presence quickly, the content is mostly browsing, ordering, lookup and forms, you already have a good website to build on, budget and time are limited, or you want to avoid depending on app stores. If you do not yet have a good site, start there; see [WordPress or Custom Code: Which Should You Pick for Your Website?](https://phatdev.net/en/blog/wordpress-or-custom-code) and [How a Slow Website Costs You Customers, and a 5-Minute Speed Check](https://phatdev.net/en/blog/page-speed-and-sales).

![A signpost splitting into an installable web app and a store app](https://phatdev.net/uploads/blog/pwa-or-native-app/choose-1920.webp)

## When to build a real app

Build an app when the features lean on hardware and the operating system (advanced camera, Bluetooth, long background work, sensors), when you need to be found inside the app stores, when you need in-app purchases, or when customers expect a proper app. I explain how to choose the technology in [Building a Phone App: Swift/Kotlin, Flutter or React Native?](https://phatdev.net/en/blog/app-native-or-cross-platform), and the store process in [Getting Your App on the App Store and Google Play: A 2026 Checklist](https://phatdev.net/en/blog/app-store-google-play-checklist).

One trap: do not wrap your whole website in a shell and submit it to the App Store. Apple's guideline 4.2 says an app must offer more than a repackaged website.

## For the developers

A minimal PWA needs three things: pages served over HTTPS (or localhost while testing), a manifest file, and a service worker if you want offline. According to MDN a service worker is not required for installability, but Chromium browsers require a manifest with a name, 192 px and 512 px icons, start_url, display, and `prefer_related_applications` not set to true.

The manifest I tested:

```json
{
  "name": "Cua hang demo",
  "short_name": "Demo",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0e7490",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}
```

A simple service worker: cache the page shell at install, try the network first, and fall back to the saved copy when offline.

```js
const CACHE = "shell-v1";
const SHELL = ["/", "/manifest.webmanifest"];

self.addEventListener("install", (e) => {
  e.waitUntil(caches.open(CACHE).then((c) => c.addAll(SHELL)));
  self.skipWaiting();
});

self.addEventListener("fetch", (e) => {
  if (e.request.method !== "GET") return;
  e.respondWith(fetch(e.request).catch(() => caches.match(e.request)));
});
```

I ran this in Chromium: the service worker registered and controlled the page, both files were cached, and after going offline and reloading the page still rendered. I have not tried it on a real iPhone.

## Common mistakes

The most common one is updating the site while customers still see the old version, because the service worker kept the old copy. Rename the cache (say shell-v2) on every release and delete the old one. Another is caching the cart or checkout page, so customers see stale data. Cache only what is safe to show again later.

## What to do next

Write down the three features your customers need most, then check them against the limits above, especially push and background work on iPhone. If all three work on the web, a PWA is a cheap and quick first step. If not, you now know exactly why you need a real app.

## References

- [MDN: Progressive web apps](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps)
- [MDN: Making PWAs installable](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/Making_PWAs_installable)
- [web.dev: Learn PWA](https://web.dev/learn/pwa/)
- [WebKit: Web Push for Web Apps on iOS and iPadOS](https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/)
- [WebKit: News from WWDC25, Safari 26 beta](https://webkit.org/blog/16993/news-from-wwdc25-web-technology-coming-this-fall-in-safari-26-beta/)
- [Apple: Update on apps distributed in the European Union](https://developer.apple.com/support/dma-and-apps-in-the-eu)
- [caniuse: Background Sync API](https://caniuse.com/background-sync)
- [App Review Guidelines, 4.2](https://developer.apple.com/app-store/review/guidelines/)

## Related posts

- [Building a Phone App: Swift/Kotlin, Flutter or React Native?](https://phatdev.net/en/blog/app-native-or-cross-platform.md)
- [Getting Your App on the App Store and Google Play: A 2026 Checklist](https://phatdev.net/en/blog/app-store-google-play-checklist.md)
- [WordPress or Custom Code: Which Should You Pick for Your Website?](https://phatdev.net/en/blog/wordpress-or-custom-code.md)
