Safari's PWA Sabotage Is a Feature, Not a Bug

The catalog of ways Mobile Safari kneecaps Progressive Web Apps keeps growing, and pwa.gripe now serves as the running tally. The pattern is familiar to anyone who's tried to ship a web app that feels native on iOS: missing Push API support that arrived years late and still behaves inconsistently, no background sync, no Badging API, aggressive service worker eviction after a few days of inactivity, and a WebKit engine mandate that prevents any other browser on iOS from filling the gaps.

This isn't an engineering resource problem. Apple employs world-class browser engineers. The WebKit team ships impressive work on layout, rendering performance, and standards compliance when it suits them. The gaps are surgical — they land precisely where a capable web app would reduce a user's need to visit the App Store and pay Apple's 15-30% commission.

Consider the specifics: Push notifications for PWAs didn't arrive on iOS until version 16.4 (March 2023), roughly a decade after Chrome supported them. When they did arrive, they required the user to manually add the app to their home screen first — a friction point that native apps don't face. Service workers, the backbone of offline-capable web apps, get terminated after roughly two weeks of inactivity on iOS, meaning your 'installed' PWA silently loses its offline capabilities unless the user opens it regularly. No other major browser does this.

The EU's Digital Markets Act forced Apple to allow third-party browser engines on iOS in the EU starting with iOS 17.4. Apple's initial response was to announce they'd remove PWA home screen support entirely in the EU — a move so transparently retaliatory that they reversed it after public backlash. The PWAs stayed, but the message was clear: Apple views web app capabilities as a competitive threat to be managed, not a platform feature to be championed.

For developers, the practical calculus is bleak. You can build a PWA that works beautifully on Android and desktop, then spend weeks working around Safari's limitations, or you can capitulate and build a native iOS app (and pay the toll). Many teams end up maintaining both, which is exactly the outcome that serves Apple's interests.

The deeper issue isn't any single missing API. It's the trust problem. When your platform vendor has a $85B/year services revenue line that depends partly on App Store commissions, their browser team's priorities will always be suspect. Every missing web capability is Schrödinger's bug: is it a genuine engineering tradeoff, or is it market protection? Apple's track record makes the charitable interpretation harder to sustain each year.

If you're making build-vs-web decisions for a product that needs to work on iOS, plan for Safari as a permanently degraded target. The regulatory pressure is real but slow-moving, and Apple has shown it will comply with the letter of the law while preserving the spirit of its walled garden.