On March 27, Apple announced the features that will be in the GA of Safari 16.4, after two beta releases. This is a significant release bringing a number of changes. In particular, Apple has increased its investment in Safari, presumably to address concerns about fair competition.

A tweet from Guillermo Rauch of a bar graph of word counts from the release notes of Safari from 12 through 16.4 beta. All the counts are under 900 words until the 16.4 beta, which has over 4300 words, including details about web push. Words above the bar graph read, "Probably nothing."

Apple Hinted At Push Last Year

Apple had released support for web push in Safari’s 15.4 beta back near the beginning of 2022. It wasn’t documented and was hidden under the “Experimental WebKit Features” flag. Experts weren’t able to make it work in the 15.4 beta, but fans of web push hoped that it meant Apple would be joining the rest of the world in supporting the feature with its Safari 16 release alongside the iOS 16/iPadOS 16 release.

That didn’t happen. Instead, Apple announced at WWDC 2022 that web push would be coming to iOS/iPadOS in a future release scheduled for 2023. Apple delivered working beta push code to installed progressive web apps (PWAs) on February 16, and on March 27, just a few days shy of eight years after websites were able to send push notifications to Android devices, Apple announced push availability for GA iOS and iPadOS users.

Now We Have Web Push … Sort Of

Apple’s version of web push is not the web push that Chrome and Firefox developers know. Apple won’t let web apps request permission to send pushes unless the user has already installed them as home page apps. This means not only will you need the usual PWA code, but you’ll also need additional Apple-specific code to walk the user through the process of installing.

Installing A Web App Is Harder On Safari

PWA installation is more difficult for users on Safari than it is on Mozilla or Chrome. A recent informal Mozilla study showed that only four of the 10 Safari users asked knew how to do it. Safari requires the user to click the Share icon, scroll down below the fold to select “Add to Home Screen,” and then click the “Add” button. When iOS web developers want to encourage installation, they usually supply an on-screen guide on their website that walks users through the process. In contrast, Android Chrome includes an “Install app” menu item for installable web apps in the browser and even lets developers implement their own custom install prompt by intercepting the before-install-prompt event.

Users Must Act To Receive Pushes

The differences don’t end there. Once the user has installed a web app on the iOS or iPadOS home screen, the app still can’t ask for permission to push. Apple requires that the user make a gesture (typically an onclick event) before asking for push permissions. Although this behavior is unique to Apple, it’s probably a good pattern for all websites to adopt. Many users simply refuse when asked for notification permission upon first visit to a site — after that, the chance to obtain permission is gone.

Web Apps Are Still Not Peers

On iOS/iPadOS, even web apps that users have installed to the home screen are still not peers of native apps. A lot of capability that’s available on Android has never made it to Apple’s mobile devices. Nothing tells a user that a home screen app has more functions than a web page. Further, Apple said in 2020 that it would not implement certain APIs that could be used for fingerprinting users: Web Bluetooth, Web MIDI API, Magnetometer API, Web NFC API, Device Memory API, Network Information API, Battery Status API, Web Bluetooth Scanning, Ambient Light Sensor, HDCP Policy Check extension for EME, Proximity Sensor, WebHID, Serial API, Web USB, Geolocation Sensor (background geolocation), and User Idle Detection. A web app on iOS can’t have a compass, report when memory is getting low, or show nearby Bluetooth devices. It also can’t rely on local storage in the same way that a native app can.

What It Means For Developers

Just as they do today, web developers will need to implement different code to account for how Safari and iOS/iPadOS differ. Websites won’t be able to send messages unless they’ve been installed as a PWA on the home screen. If web developers want to send notifications, they’ll need to walk the user through the install process, then they’ll need to entice the user to take an action so they can ask for notification permission.

Mobile developers can’t rely on PWAs for a true cross-platform solution. Although the browser now includes one more useful feature, enough is still missing that apps will need to install native code. The day when PWAs can replace native apps is not today, and Apple will work hard to satisfy any upcoming legislative requirements for competition while keeping as much control over user experience, customer information, and app store profits as it can.