What is a PWA and why it is often cheaper than a native app

A PWA (Progressive Web App) is a web application that can be installed on a device, works offline and sends notifications - combining the convenience of a mobile app with the simplicity of a website. Under the hood it is still a "website", but it behaves like an app: it has an icon on the home screen, opens in full screen and does not require a network connection to work.

How it differs from a website and a native app

• Website: opened in a browser, does not install, requires a connection.
• PWA: installed from the browser, works offline, notifications - one codebase for all devices.
• Native app: downloaded from a store, full access to hardware, but separate code for Android and iOS plus an approval process.

Advantages of a PWA

• One codebase instead of separate apps = lower cost of building and maintenance. → How much does a custom app cost
• No store - installation from a link, updates immediately.
• Works offline - useful in the field. → Booth sales system
• Good for SEO/GEO - it is still a website, so search engines can see it.

Limitations

A PWA has more limited access to some hardware features than a native app and is not the best choice for tasks that require maximum performance (heavy 3D graphics, intensive processing). For most business tools these limitations do not matter.

When to choose a PWA

When you care about a fast, cheap deployment that works on every device, and the app does not need advanced access to hardware. Practical use cases for companies: PWA for a small business. What we build PWAs with: Why Next.js + Supabase.

How a PWA works technically

What distinguishes a PWA from an ordinary website comes down to three elements that work together in the browser.

• The app manifest is a file with metadata (name, icon, colors, display mode). Based on it, the browser proposes installation and knows how to show the icon on the home screen and launch the app in full-screen mode, without the address bar.
• The service worker is a script that runs in the background, regardless of whether the page is open. It acts as an intermediary between the app and the network: it intercepts requests and decides what to serve from the cache and what to fetch from the server. It is responsible for offline operation and receiving push notifications.
• The cache stores the app's files and data on the device. Thanks to this, a PWA loads instantly on subsequent visits and can display content even without the internet.

An important technical condition: a PWA works only over HTTPS. An encrypted connection is required, because the service worker has a lot of control over network traffic and without this safeguard it would be a gateway to abuse. The same connection protects user data - more on this in the article Data security in an application.

In practice, the caching strategy is a design decision. You can serve from the cache first (speed at the cost of data freshness) or fetch from the network and keep the cache as a backup in case the connection is lost. The choice depends on whether the app shows data that changes every minute or content that stays stable for weeks.

PWA, native app and ordinary website - a comparison

The simplest way to think about these three approaches is as steps on a single scale, rather than completely different worlds.

An ordinary website is the cheapest and simplest, but it lives only in the browser - it has no icon, does not work offline, and every visit requires a network. It works well for informational content and business cards.

A PWA adds an "app" layer to the website: installation, offline operation, notifications and full screen. It is still a single codebase for all devices and search engines can still see it, because under the hood it is still a website. The cost of building is closer to a website than to a native app.

A native app is a separate program written for a specific system (different code for Android, different for iOS), downloaded from a store. It provides the deepest access to hardware and the highest performance, but it costs more - because it is two projects instead of one - and requires going through the store approval process and publishing updates from scratch every time. You will find a broader comparison of these paths in the article Custom app - a guide.

For many business tools - dashboards, order-handling systems, apps for employees in the field - a PWA hits the sweet spot: it provides what is actually needed, without the cost of two native apps.

Limitations of PWAs on iOS and Android

The "one codebase for everything" promise is true, but the two platforms treat PWAs differently and it is worth knowing this before deciding.

On Android support is mature. The browser itself proposes installation, push notifications work, the cache is large, and a PWA can be wrapped and listed in Google Play via the so-called Trusted Web Activity. For most use cases a PWA on Android behaves almost like a native app.

On iOS Apple is more restrictive. A PWA is installed via Safari (the "Add to Home Screen" option), but historically some features were unavailable. Push notifications only work from iOS 16.4 onwards and require the user to first install the PWA on the home screen. Cache limits tend to be smaller, and access to some hardware features is narrower than on Android.

In practice this means one thing: if push notifications to iPhone users are crucial to your idea, you need to verify this at the planning stage and not after deployment. For internal tools, where the company controls which devices employees use the app on, these differences often fade into the background.

When a PWA is a good choice, and when it is not

A PWA is not the answer to everything - it is the answer to a specific class of problems.

Choose a PWA when:

• you need a single solution that works on a computer, phone and tablet without building separate apps,
• the app is meant to be found in search engines and at the same time be installable,
• a fast and cheaper deployment matters, and the budget should go into features, not into two native versions,
• offline operation or working in poor coverage is a real need (work in the field, a warehouse, a booth).

Consider a native app when:

• the app makes intensive use of hardware (advanced 3D graphics, continuous image processing, specific sensors),
• presence in the App Store and Google Play is in itself a business or marketing goal,
• push notifications and deep system integration on iOS are critical and tolerate no limitations.

If you are hesitating between these paths, a good starting point is an MVP in 6 weeks - a lightweight version that lets you test the idea before you decide on the full scope. It is also worth consulting any doubts about the direction: write to us via contact.

FAQ

What is a PWA in one sentence? A PWA (Progressive Web App) is a web application that can be installed on a device, works offline and sends notifications - combining the features of a website and a mobile app.

How does a PWA differ from a native app? A native app is downloaded from a store and written separately for each platform. A PWA runs from the browser on a single codebase for all devices, without being published in a store.

What are the limitations of a PWA? A PWA has more limited access to some hardware features than a native app and is not suitable for tasks that require maximum performance, e.g. heavy 3D graphics.

What is a service worker in a PWA? A service worker is a script that runs in the background of the browser, independently of the open page. It intercepts network requests, serves files from the cache and enables offline operation as well as receiving push notifications.

Does a PWA work on an iPhone? Yes, a PWA can be installed on iOS via Safari, but Apple limits some features - push notifications require iOS 16.4 or newer, and the cache limit is smaller than on Android.

Can a PWA be placed in the App Store and Google Play? A PWA can be wrapped and published in stores (e.g. via Trusted Web Activity on Android), but this is not necessary - a PWA installs directly from the browser via a link.

---