Progressive Web Apps (PWAs) promise the best of both worlds: the reach of web applications combined with the performance and features of native apps.
However, when it comes to iOS, these apps face a series of frustrating limitations that can dampen the user experience and challenge developers. From push notifications to offline capabilities, each restriction shapes how PWAs operate on Apple devices.
If you’re a developer or just curious about the tech behind your favorite apps, understanding these constraints is crucial.
Let’s take a look at the limitations of PWAs on iOS and uncover the specific hurdles they face.
Contents
1. Issues with Push Notifications
Developing a PWA and keeping users engaged with push notifications on iOS is tricky.
Your app needs to be added to the home screen; otherwise, no notifications. Even then, no background sync means notifications only arrive when the app is open.
iOS doesn’t support silent notifications for PWAs, so every alert is disruptive. Features are limited too—no rich media, just text and icons.
Users must manually enable push notifications in Safari settings, which is a hassle.
Additionally, there are rate limits on notifications, and users may need to renew their subscription token often. Plus, with iOS 17.4, PWAs in the EU can’t use push notifications at all due to regulatory changes.
Workarounds like service workers or Apple’s Push Notification Service exist, but they aren’t perfect solutions. Overall, push notifications on iOS PWAs come with significant limitations.
2. Browser Dependency
Safari is the only browser that fully supports PWAs on iOS, meaning users must use it to install and run these apps effectively.
Other browsers, like Chrome and Firefox, can display PWAs, but they lack essential features like push notifications and background sync because they are required to use Apple’s WebKit engine.
Even though Apple has started allowing other browsers to opt-in for PWA support as of iOS 16.4, this change hasn’t fully taken off. No other browsers have implemented the feature comprehensively, leaving Safari as the de facto choice.
For developers, this Safari dependency means extra work. They need to ensure compatibility with Safari and navigate its limitations, such as restricted access to device features and sensors.
3. Installation Hassle
Unlike Android, where browsers like Chrome can automatically prompt users to install a PWA, iOS makes you jump through hoops. You have to manually initiate the installation process through Safari’s share menu.
Many users aren’t even aware that they can install PWAs, so developers have to provide step-by-step instructions or in-app prompts to guide them. This adds an extra layer of complexity and effort that can deter users from going through with the installation.
If you open a PWA link from an embedded browser within another app, such as Reddit or Facebook, the “Add to Home Screen” option may not be available, causing confusion and frustration.
This convoluted process impacts user engagement. The extra steps required can deter users from adding PWAs to their home screens, which in turn can reduce user retention compared to native apps that are easily installed from the App Store.
4. Limited Access to Device Features
For starters, PWAs can’t integrate with Face ID or Touch ID, so forget about offering secure, seamless biometric authentication like many native apps do. This limits the user experience, especially when secure authentication is crucial.
Access to device sensors is another stumbling block. While PWAs can tap into basic sensor data, they can’t fully utilize the accelerometer, gyroscope, or ambient light sensor.
The same goes for Bluetooth and USB connectivity. PWAs can’t interact with external devices and peripherals as native apps can, which is a big limitation for hardware-integrated applications.
Geolocation is supported, but don’t expect it to be as robust as in native apps. The precision and frequency of location updates might leave you wanting more.
Plus, PWAs can’t use NFC for tasks like mobile payments or data exchange, which are routine for native apps.
Integration with Siri? Not happening.
Users can’t interact with PWAs using voice commands through Siri, missing out on the hands-free convenience. Orientation lock is another missing feature, so PWAs can’t lock the display orientation to portrait or landscape mode, unlike native apps.
And if you were hoping to create home screen widgets for quick access to app functionalities, PWAs won’t help you there either. Finally, direct printing without user interaction is off the table, meaning PWAs can’t offer the smooth, integrated printing experience that native apps can.
5. Storage Limitations
Safari imposes a 50MB limit on cache storage for PWAs. This means your app can only store up to 50MB of data before hitting a hard stop, at which point you’ll be prompted to free up space.
While local storage and IndexedDB might seem like alternatives, they come with their own quirks. Some sources suggest that IndexedDB might allow for more storage—up to 500MB or more, depending on the device’s available free disk space.
However, this isn’t consistent, so developers need to test and verify the limits for their specific use cases.
Safari’s eviction policies add another layer of complexity. If a PWA isn’t used for a few weeks, Safari may delete the stored data, including cache and possibly IndexedDB data, unless the PWA is added to the home screen.
Furthermore, starting with iOS and iPadOS 13.4, there is a seven-day cap on all script-writable storage, meaning if a PWA isn’t accessed within seven days, its stored data might be cleared.
Adding to the frustration, storage isn’t shared between Safari and standalone PWAs. Data stored while using the PWA in Safari won’t be accessible when the PWA is launched from the home screen, and vice versa.
Safari allocates up to about 20% of total disk space for each origin, which can increase to 60% if the PWA is saved as a web app on the home screen. However, these quotas can vary to avoid fingerprinting, making storage management a moving target.
6. Performance Variability
When it comes to performance, PWAs on iOS can be a bit of a mixed bag. The hardware capabilities of the device play a significant role.
Factors like processor speed, RAM, and graphics processing power can drastically affect how smoothly animations, scrolling, and other resource-intensive tasks are rendered. On older devices with less available memory, you might notice slower performance or more frequent reloads compared to newer models.
Safari is the only browser that fully supports PWAs on iOS, and its optimization varies across different iOS device models. This means complex PWAs that rely heavily on JavaScript and rendering might perform differently depending on the device.
Memory management strategies also differ among iOS devices, affecting how PWAs are loaded and cached.
Network conditions add another layer of variability. Since PWAs rely on network connectivity for initial loading and updates, differences in network speeds and conditions can impact performance.
Similarly, iOS devices might throttle performance or limit background processes to conserve battery life, which can affect PWA responsiveness, especially during extended usage sessions.
Software updates can also introduce performance variations. New iOS updates may bring optimizations or changes that impact PWA performance, leading to inconsistencies until all devices are updated.
7. Offline Capabilities
When it comes to offline capabilities, PWAs on iOS face an uphill battle. A key technology enabling offline functionality in PWAs is service workers, which cache resources for use without an internet connection.
However, on iOS, service worker implementation is often problematic. They may not always cache resources correctly, leading to issues when trying to access the PWA offline.
Safari imposes a stringent 50MB limit on cache storage for PWAs. This restriction can prevent PWAs from caching all the necessary resources, which are crucial for offline functionality.
When the cache limit is reached, the PWA might fail to load offline, leaving users staring at a blank screen instead of the app they expected.
Moreover, the offline capabilities of PWAs can be inconsistent across different iOS versions. Some users report that PWAs that used to work offline in earlier iOS versions no longer do so after updates, causing frustration and reliability issues.
Service worker registration can also be hit or miss. There are instances where service workers fail to register correctly, preventing the PWA from caching resources as expected.
This can result in the PWA displaying an error message or a blank screen when accessed offline.
8. App Store Integration
Getting a PWA into the Apple App Store isn’t a walk in the park. Apple has strict guidelines, requiring PWAs to offer more than just a repackaged website.
They need to provide unique, useful, and “app-like” features to meet Apple’s standards.
The approval process itself is a multi-step marathon. It involves creating a native wrapper using tools like PWABuilder, generating an Xcode project, and submitting it through Apple’s developer portal.
This process can be both complex and time-consuming, demanding a significant investment of time and effort.
Even if a PWA makes it through these hoops and gets accepted into the App Store, it might still face functionality limitations compared to native apps.
For instance, PWAs have restricted access to certain APIs and features like in-app purchases, push notifications, and background sync. These limitations can significantly impact the app’s usability and user experience.
9. Safari’s Slower Adoption of Web Standards
While browsers like Chrome, Firefox, and Edge rapidly implement the latest features, Safari tends to lag behind. This delay can range from several months to even years, depending on the specific web standard or API in question.
One reason for this sluggishness is Apple’s prioritization criteria. The company seems to implement web standards based on its own set of priorities, which may not always align with the needs of other browser vendors or web developers.
Safari’s stricter review process for new web standards and APIs also contributes to the delay. Apple puts potential features through a rigorous evaluation to ensure compatibility, security, and privacy, but this thoroughness can slow down the adoption rate.
Apple’s decisions are heavily influenced by their desire to maintain a consistent user experience across all their devices and operating systems, including iOS, iPadOS, and macOS. Concerns about performance impacts or battery life implications on mobile devices further delay the adoption of new standards.
Privacy and security are paramount for Apple, leading to a more cautious approach when evaluating new web standards. This emphasis, while beneficial for user safety, can slow down the pace at which Safari supports new features.
Critics have noted that Apple’s engagement with web standards bodies like the W3C and WHATWG is less active compared to other tech giants. This lack of engagement can result in slower adoption rates, as Safari might not be aligned with the latest industry developments.
10. Background Execution
There is no mechanism for running code continuously in the background for PWAs on iOS. This means they cannot perform tasks or processes indefinitely when they are not actively in use.
Essentially, once a PWA is moved to the background, iOS suspends it shortly thereafter, preventing it from running any code.
This limitation is particularly evident with background sync capabilities. While iOS does support background sync through service workers, it falls short compared to native apps.
The Background Fetch API, which allows PWAs to download large files while not running, also faces restrictions. iOS may terminate these tasks prematurely to save battery life, and there are rate limits on how frequently these tasks can be initiated.
Moreover, background fetch tasks rely heavily on network connectivity and may fail or be delayed if the device is offline for extended periods.
11. Technical Limitations
When it comes to PWAs on iOS, technical limitations abound, especially with the Web App Manifest—a JSON file that provides metadata about the app, including its name, icons, and behavior when installed. On iOS, this manifest’s capabilities are significantly restricted.
First, the support for icons and splash screens is lacking. iOS does not fully recognize the app icons specified in the manifest.
Developers often need to use additional code to create custom splash screens and ensure the app performs well in standalone mode.
The manifest can also specify display modes like “standalone” or “fullscreen.” However, iOS doesn’t support all these display options.
Modes such as “minimal-ui” and “fullscreen” often default to “standalone,” limiting how developers can present their apps.
Another significant limitation is the lack of support for screen orientation lock through the manifest. Developers have no control over locking the screen orientation, which can be crucial for certain types of apps, such as games or media players, to provide a consistent user experience.
These technical constraints force developers to implement workarounds, adding complexity to the development process and often leading to a less polished user experience compared to what’s possible on other platforms.
Conclusion
PWAs have the potential to revolutionize how we use apps by blending the best features of web and native applications. However, on iOS, they face significant limitations that can hinder their effectiveness and adoption.
Despite these hurdles, the landscape is gradually improving, with updates and workarounds offering some hope for the future. Developers need to stay informed and adaptable, leveraging the strengths of PWAs while creatively addressing their weaknesses.
As the technology evolves and Apple potentially loosens its restrictions, the dream of fully functional PWAs on iOS may become a reality. Until then, understanding and navigating these limitations is key to delivering the best possible user experience.
