Progressive web apps in 2026: what installable web apps can really do

A progressive web app (PWA) is a website that installs like an app: it gets its own icon and window, keeps working offline, and can send push notifications. In 2026 that promise holds up well on Android, Windows and macOS, and it holds up on iOS with real limits you need to plan around. For portals, internal tools and content-heavy products, a PWA is often the fastest way to put something app-like in people's hands — for hardware-heavy consumer apps, native is still the better call.

What exactly is a progressive web app?

A PWA is an ordinary web application with two extra pieces: a manifest file that describes the app (name, icon, colours, display mode) and a service worker, a background script that intercepts network requests so the app can cache what it needs and keep running without a connection. When both are in place, browsers offer to install the app. On Android, Chrome packages it so it appears in the launcher and app switcher like anything from the Play Store. On Windows and macOS, Chrome and Edge install it as a windowed desktop app. On iOS, the user adds it to the home screen from Safari's share menu.

The result is one codebase that reaches phones, tablets and desktops, updates the moment you deploy, and never waits on a store review. That last point matters more than it sounds: shipping a fix in the afternoon and knowing that every user picks it up on their next load changes how a team operates.

What can a PWA actually do in 2026?

The honest answer is: far more than most people assume, and less than a native app on the platforms where it counts. On Chromium browsers (Chrome, Edge and their relatives), an installed PWA can, at the time of writing:

• Work fully offline, with the service worker deciding what to cache and how to sync changes when the connection returns.
• Send push notifications, including when the app is closed.
• Use the camera, microphone and geolocation, with the same permission prompts a native app shows.
• Register as a share target, handle file types, and add app shortcuts to its icon.
• Talk to Bluetooth, NFC, USB and serial devices through Chromium-only APIs — useful for kiosks, warehouse scanners and point-of-sale gear on Android.

The caveats sit at the edges. Many of the hardware APIs are Chromium-only: Safari and Firefox have declined to implement Web Bluetooth and Web NFC, citing privacy concerns, so any feature that depends on them is effectively Android-and-desktop-Chrome only. Background processing is constrained everywhere — a PWA cannot run an arbitrary task while closed the way a native app with background entitlements can. And graphics-heavy work is improving through WebGPU but still trails what native toolkits deliver on the same phone.

Where does iOS really stand on PWAs?

iOS is where every PWA conversation gets careful, so here is the plain version. Safari has supported service workers and offline caching since 2018. The larger shift came in 2023: iOS 16.4 added web push and app badging, but only for web apps the user has added to their home screen. That distinction shapes the whole experience. There is no install prompt on iOS — the user must find "Add to Home Screen" in the share menu themselves — so an iOS PWA needs clear in-app guidance if notifications matter to it.

Two more iOS realities worth planning for. First, storage: Safari applies eviction policies to website data, and while an installed web app's data is treated more durably, you should architect as if local data can disappear — sync anything important to the server. Second, hardware: there is no Web Bluetooth, Web NFC or background sync on iOS, and no sign of that changing at the time of writing. Early 2024 also brought a reminder of platform risk, when Apple moved to remove home-screen web apps for users in the EU and then reversed the decision. The capability survived, but the episode is a fair warning: on iOS, a PWA lives on terms Apple sets.

Treat iOS as the floor. If your product works well as a home-screen web app on an iPhone, everywhere else is a bonus.

How do PWAs compare with cross-platform and fully native apps?

The choice is rarely PWA versus native in the abstract; it is a question of what your product needs from the device and where your users expect to find you. Here is how the three approaches compare in qualitative terms.

Notice what the table does not say: that one column wins. A booking product with a large web audience reads that table very differently than a fitness app that pairs with a heart-rate strap.

Where do PWAs make the most sense?

The pattern across the projects we see is consistent. PWAs earn their keep where reach and low friction beat device integration:

• Customer and member portals. People log in occasionally to check a claim, an invoice or a schedule. Asking them to install a store app for that is a losing battle; a link they can pin to their home screen is not. This is the core of our portals and intranets work.
• Internal tools. Field staff, warehouse teams and franchise operators need the same tool on a counter PC, a personal Android phone and a manager's iPhone. One PWA covers all of it, and IT never chases store deployments or mobile-device-management installs for updates.
• Booking, ordering and account management. High-intent, form-driven flows where every extra step costs completions. The web's zero-install reach is the advantage.
• Dashboards and content products. Offline caching makes reading and reference material genuinely usable on a commute or a job site with no signal.

In each of these, the PWA is not a compromise; it is the better product decision. The engineering work — caching strategy, sync logic, install guidance, notification design — is where the difference between a demo and a dependable tool lives, and it is the bulk of what a serious web app development engagement covers.

When should you still build native?

Go native, or cross-platform native, when the product depends on things the web platform does not offer or offers unevenly:

1. Hardware beyond the basics. Bluetooth accessories on iOS, NFC payments, ultra-wideband, sensors sampled in the background — none of that is reachable from a web app on an iPhone.
2. Continuous background work. Turn-by-turn navigation, always-on tracking, and audio that must survive the app being closed all need native background entitlements.
3. Heavy graphics and AR. Games and 3D-first experiences still get more from Metal and Vulkan than from the browser.
4. Watches, widgets and deep OS integration. Wearable companions, home-screen widgets, Siri and system share sheets are native territory.
5. Store presence as a business requirement. Some audiences simply expect to find you in the App Store, and some categories effectively require it.

The two roads also combine well: plenty of products ship a PWA for the web audience and a focused native iOS app for the subset of users who need the hardware, sharing one API underneath.

How OlDevs can help you make the call

We have been building for the web and for app stores since 2014, so we have no stake in steering you to either answer — one accountable team scopes the product, recommends PWA, native or both, and builds it with a working demo in your hands every week. Everything we ship meets WCAG 2.2 AA accessibility, works in English and French where you need it to, and belongs to you outright: code, designs, accounts and IP. If you are weighing an installable web app against a native build, or you have a portal or internal tool that should feel like an app without the app store, tell us what you are trying to do and request a quote. We reply to every enquiry within one business day.