Progressive
web app development
in Baltimore

Progressive web apps work best on Android and desktop Chrome. On the iPhone, support has improved but remains different in ways that affect product decisions. Many teams discover this late, after the design assumes features that iOS handles differently or not at all.

Installation is the first difference. On Android, the browser can show an install prompt, and the app can offer its own install button. On iOS, there is no automatic prompt. Users must open the share menu in Safari and choose Add to Home Screen. Most people have never done this, so the app needs simple instructions shown at the right moment.

Push notifications arrived on iOS with version 16.4, but only for web apps added to the home screen. A user who visits in the browser cannot subscribe. Permission must be requested after a tap, not on page load. Plans that rely on push for every user need to count how many iPhone users will actually install.

Storage behaves differently too. Safari may clear stored data for sites that have not been used for a while, as part of its privacy protections. Home screen web apps are treated more generously, but storage is still limited and can be removed if the device is short of space. Offline data should always be something the app can fetch again.

Background work is limited. Background sync and periodic background sync are not supported in Safari. An app cannot quietly upload queued data while closed. It must do that the next time the user opens it, and show clearly what is still waiting.

Some device features are missing or partial. Web Bluetooth, Web NFC and some sensor APIs are not available in Safari. Camera, microphone, location and payments through Apple Pay do work. Before promising a feature, check support in the current Safari version, not a list from two years ago.

Outside the European Union, all browsers on iOS use the same engine as Safari. Installing Chrome on an iPhone does not bring Android features, and testing only in Chrome on desktop gives a false picture.

Rules have changed more than once. In early 2024 Apple announced it would remove home screen web apps in the European Union, then reversed the decision after feedback. Teams building for iPhone users should expect further changes and follow release notes.

None of this rules out a PWA. For many products, content, forms, catalogues, internal tools and booking flows, the iPhone limits do not matter. They matter for apps that depend on push to every user, on long offline periods or on hardware access.

Design with the gaps in mind. Show installation help to iPhone users. Offer email or SMS as an alternative to push. Keep offline queues short and visible. Test on real iPhones with several iOS versions.

If the core of the product needs features iOS does not offer, a small native wrapper or a native app may be the honest answer.

Analytics should separate installed users from browser users on iOS. Installation rates, push opt-ins and return visits differ a lot between the two groups. Without that split, a team can conclude that push works poorly, when in fact only a small share of iPhone users ever had the chance to subscribe.

Icons, splash screens and the status bar need specific attention on iPhone. Safari uses its own tags for the home screen icon and the look of the launched app. A web app that only provides the standard manifest may show a blurred icon or a white screen before it loads. These details are small, but they decide whether an installed app feels finished.

Payments deserve a separate check. Apple Pay works in Safari through the Payment Request API and Apple Pay on the web, but the merchant setup and domain verification take time. A checkout that works on Android with a card form should be tested on iPhone with Apple Pay before launch.

Deep links behave differently as well. On Android, a link to the web address of an installed app can open the app itself. On iPhone, links usually open in Safari, even when the web app is on the home screen. Flows that start from an email or a message, such as password resets and invitations, need testing with this in mind.

Updates reach installed iPhone web apps through the same service worker mechanism as elsewhere, but the timing can be less predictable. Clear version checks and a prompt to reload when new code is ready keep users from running an old build for weeks.

Communication with users should match the platform. Help pages and onboarding screens that mention install buttons, notification prompts or background updates can confuse iPhone users if those features look different or do not exist for them. Detecting the platform and showing the right instructions avoids support requests that start with a screenshot of a missing button.