PWA Games on iOS: Limits and Workarounds

The WebKit Requirement

Apple mandates that all browsers on iOS use the WebKit rendering engine. Chrome, Firefox, Edge, Brave, and every other browser on an iPhone or iPad are essentially Safari with different UI. This means the PWA capabilities available on iOS are determined entirely by Apple's WebKit team, not by the browser vendor the player chooses.

For game developers, this constraint simplifies and frustrates simultaneously. You only need to test against one engine (WebKit), but you are also locked into whatever features and bugs that engine ships. If WebKit does not support a web API that your game needs, no browser on iOS will support it. And if WebKit has a rendering bug, it affects every iOS user regardless of their browser choice.

Regulatory pressure from the EU's Digital Markets Act led to fines against Apple in 2025, and the UK's Competition and Markets Authority has also taken action. The direction of regulation suggests Apple may eventually allow alternative browser engines on iOS, which would dramatically improve PWA capabilities. However, as of mid-2026, the WebKit mandate remains in practical effect for the vast majority of iOS users, and game developers should design around current WebKit limitations rather than anticipated future changes.

Storage Quotas and Eviction

iOS imposes stricter storage limits on web content than Android or desktop browsers. For non-installed web apps (regular Safari tabs), the storage quota per origin is approximately 50MB across Cache Storage and IndexedDB combined. This is often insufficient for games with large spritesheets, multiple audio tracks, and level data files.

Installing the PWA to the home screen improves the situation. Installed PWAs on iOS receive a more generous storage quota, though Apple has not published exact numbers. Anecdotal testing suggests installed PWAs can use several hundred megabytes before encountering quota errors. However, even installed PWAs can have their storage evicted if the device runs low on space, and Apple does not provide a mechanism to prevent this (the navigator.storage.persist() API is not fully supported on Safari).

The workaround is to keep your total cached asset size as small as practical. Compress sprites with tools like TinyPNG or use WebP format (supported in Safari since iOS 14). Use MP3 at 128kbps for audio rather than uncompressed WAV. Minify and bundle JavaScript. For games with large content libraries (many levels, expansion packs), cache only the content the player has accessed recently and implement a loading screen for uncached content rather than trying to pre-cache everything.

Safari also had a notorious policy of evicting service worker caches after 7 days of inactivity for non-installed web apps. While this policy has been relaxed in recent iOS versions, the safest approach is to strongly encourage iOS players to install the PWA to their home screen, which grants more stable storage persistence.

Installation Without beforeinstallprompt

iOS Safari does not support the beforeinstallprompt event. There is no programmatic way to trigger an install dialog. The player must manually add the game to their home screen through a multi-step process: tap the Share button (the square with an upward arrow in Safari's toolbar), scroll through the share sheet options, and tap "Add to Home Screen." This typically requires 4 or more taps, and many users have never used this feature.

The practical impact is that iOS installation rates for PWA games are significantly lower than on Android, where the browser handles the prompt automatically. To mitigate this, show a custom instruction overlay for iOS users that visually guides them through the manual steps. Use simple illustrations or screenshots annotated with arrows pointing to the Share button and the "Add to Home Screen" option. Time this overlay for a moment when the player is engaged but not mid-gameplay, such as after completing a level or on the main menu screen.

Detect iOS reliably by checking for the combination of navigator.platform (or navigator.userAgentData) and the absence of the beforeinstallprompt event. Do not rely on user agent string parsing alone, as it is increasingly unreliable. Once you confirm the player is on iOS and the game is not already running as an installed PWA (check window.navigator.standalone), show the instruction overlay.

Despite the installation friction, iOS players who do install tend to be highly engaged. The manual effort acts as a natural filter, only players who genuinely want to keep the game will go through the steps. This means your installed iOS user base, while smaller, often has higher retention and session length than your Android installed base.

Missing and Limited APIs

Several web APIs that game developers rely on work differently or not at all on iOS Safari compared to Chrome on Android.

Push notifications were added to iOS PWAs in version 16.4 (2023), but they behave differently from Android. The PWA must be installed to the home screen for push to work. Notifications may not be delivered reliably after device restarts, and service worker push event listeners can be unreliable. For games that use push to remind players of daily challenges or turn-based game events, treat iOS push as a "nice to have" rather than a core feature, and always provide in-game fallbacks for important notifications.

Background Sync is not supported on Safari. The Background Sync API, which lets service workers retry failed network requests when connectivity returns, does not work on iOS. Games that queue offline actions (like score submissions or save syncs) need to handle the sync manually when the game is reopened rather than relying on background sync events.

Screen Wake Lock (keeping the screen on during gameplay) has been supported on Safari since iOS 16.4, which is important for games that have idle periods where the player might be reading or thinking without touching the screen. Use navigator.wakeLock.request('screen') during active gameplay and release it when the game is paused or backgrounded.

Fullscreen API support on iOS is limited. While the manifest's display: "fullscreen" works for installed PWAs, the JavaScript Fullscreen API (element.requestFullscreen()) does not work reliably on iOS Safari for non-installed web apps. This means games played in a Safari tab cannot programmatically go fullscreen. The workaround is to encourage installation, where the manifest's display mode takes effect.

Gamepad API support on iOS is present but with caveats. MFi (Made for iPhone) controllers and recent console controllers (PS5 DualSense, Xbox Wireless) are supported. However, detection and connection handling can be less reliable than on Chrome for Android, so test with your target controllers on real iOS devices.

Performance Considerations on iOS

WebKit's JavaScript engine (JavaScriptCore) is performant but handles some patterns differently than Chrome's V8 engine. Games that are heavily optimized for V8 may see different performance characteristics on iOS. Profile your game on a real iPhone (not just the iOS Simulator, which runs on desktop hardware) to identify bottlenecks specific to WebKit.

WebGL support on iOS is solid for most 2D and moderate 3D games. However, iOS has historically had lower WebGL texture size limits and more conservative memory management than Android. If your game uses very large textures (4096x4096 or larger), test on older iPhones where GPU memory is more constrained. WebGL2 is supported since iOS 15, so you can rely on it for modern iOS targets.

Audio playback on iOS requires a user interaction to start. The Web Audio API and HTML5 Audio both require the player to tap, click, or press a key before any sound plays. This is a deliberate Safari policy to prevent autoplay. Handle this by starting audio playback in response to the player's first tap on a "Play" or "Start" button. Once audio context is unlocked by that first interaction, subsequent sounds play normally.

Memory pressure handling differs on iOS. Safari aggressively reclaims memory from background tabs and even foreground tabs under pressure. If your game uses significant memory, implement periodic cleanup of unused resources, release textures and audio buffers when levels unload, and handle the pagehide and pageshow events to detect when the player switches away from and back to the game.

Practical Recommendations for iOS PWA Games

Design for iOS constraints from the start rather than treating iOS as an afterthought. Keep your total cache size under 50MB for the pre-cache, encourage installation with clear visual instructions, implement manual sync for offline actions instead of relying on Background Sync, unlock audio on the first user interaction, and test on real iPhones at every stage of development.

Prioritize the features that work well on iOS: service workers for caching and offline play, IndexedDB for save data, Canvas and WebGL for rendering, Web Audio for sound (after unlock), and push notifications for installed PWAs (with fallbacks). Accept the limitations gracefully, an iOS PWA game that handles constraints well is far more effective than one that fights them and breaks.