Today marks the release of iOS and iPadOS 16.4 beta 1, and with it comes support for Web Push and other features for Home Screen web apps.
Today also brings the first beta of Safari 16.4. It’s a huge release, packed with over 135 features in WebKit — including RegExp lookbehind assertions, Import Maps, OffscreenCanvas, Media Queries Range Syntax,
font-size-adjust, Declarative Shadow DOM, and much more. We’ll write all about these new WebKit features when Safari 16.4 is released. Meanwhile, you can read a comprehensive list of new features and fixes in the Safari 16.4 release notes.
But let’s set Safari aside and talk about Home Screen web apps on iOS and iPadOS.
Since the first iPhone, users could add any website to their Home Screen — whether it’s a brochure site, a blog, a newspaper, an online store, a social media platform, a streaming video site, productivity software, an application for creating artwork, or any other type of website. For the last ten years, users of Safari on iOS and iPadOS could do this by tapping the Share button to open the Share menu, and then tapping “Add to Home Screen”. The icon for that website then appears on their Home Screen, where a quick tap gets them back to the site.
Web developers have the option to create a manifest file (with its
display member set to
fullscreen) and serve it along with their website. If they do, that site becomes a Home Screen web app. Then, when you tap on its icon, the web app opens like any other app on iOS or iPadOS instead of opening in a browser. You can see its app preview in the App Switcher, separate from Safari or any other browser.
Web Push for Web Apps added to the Home Screen
Now with iOS and iPadOS 16.4, we are adding support for Web Push to Home Screen web apps. Web Push makes it possible for web developers to send push notifications to their users through the use of Push API, Notifications API, and Service Workers all working together.
A web app that has been added to the Home Screen can request permission to receive push notifications as long as that request is in response to direct user interaction — such as tapping on a ‘subscribe’ button provided by the web app. iOS or iPadOS will then prompt the user to give the web app permission to send notifications. Once allowed, the user can manage those permissions per web app in Notifications Settings — just like any other app on iPhone and iPad.
The notifications from web apps work exactly like notifications from other apps. They show on the Lock Screen, in Notification Center, and on a paired Apple Watch.
This is the same W3C standards-based Web Push that was added in Safari 16.1 for macOS Ventura last fall. If you’ve implemented standards-based Web Push for your web app with industry best practices — such as using feature detection instead of browser detection — it will automatically work on iPhone and iPad.
Web Push on iOS and iPadOS uses the same Apple Push Notification service that powers native push on all Apple devices. You do not need to be a member of the Apple Developer Program to use it. Just be sure to allow URLs from
*.push.apple.com if you are in control of your server push endpoints.
Notifications are a powerful tool, but it’s easy for people to get into situations where they are overwhelmed by too many of them. Notifications for Home Screen web apps on iPhone and iPad integrate with Focus, allowing users to precisely configure when or where to receive them. For users who add the same web app to their Home Screen on more than one iOS or iPadOS device, Focus modes automatically apply to all of them.
Home Screen web apps on iOS and iPadOS 16.4 now support the Badging API. Just like any app on iOS and iPadOS, web apps are now able to set their badge count. Both
clearAppBadge change the count while the user has the web app open in the foreground or while the web app is handling push events in the background — even before permission to display the count has been granted.
Permission to display the badge on the app icon is granted in exactly the same way as other apps on iOS and iPadOS. Once a user gives permission to allow notifications, the icon on the Home Screen will immediately display the current badge count. Users can then configure permissions for Badging in Notifications Settings, just like any other app on iOS or iPadOS.
WebKit for iOS and iPadOS 16.4 adds support for the
id member from the Web Application Manifest standard. It’s a string (in the form of a URL) that acts as the unique identifier for the web application, intended to be used by an OS in whatever way desired. iOS and iPadOS use the Manifest ID for the purpose of syncing Focus settings across multiple devices.
iOS has supported multiple installs of the same web app since the very beginning. We believe the ability for people to install any web app more than once on their device can be useful — providing additional flexibility to support multiple accounts, separate work vs personal usage, and more.
When adding a web app to the Home Screen, users are given the opportunity to change the app’s name. iOS and iPadOS 16.4 combine this name with the Manifest ID to uniquely identify the web app. That way, a user can install multiple copies of the web app on one device and give them different identities. For example, notifications from “Shiny (personal)” can be silenced by Focus while notifications from “Shiny (work)” can be allowed. If the user gives their favorite website the same name on multiple devices, Focus settings on one device will sync and apply to the others as well.
Third-party browser support for Add to Home Screen
In iOS and iPadOS 16.4, third-party browsers can now offer their users the ability to add websites and web apps to the Home Screen from the Share menu.
Applications on iOS and iPadOS present the Share menu by creating a
UIActivityViewController with an array of
activityItems. For “Add to Home Screen” to be included in the Share menu the following must be true:
- The application has the com.apple.developer.web-browser managed entitlement
- A WKWebView is included in the array of
- The WKWebView is displaying a document with an HTTP or HTTPS URL
- If the device is an iPad, it must not be configured as a Shared iPad
As described above, after a user adds to Home Screen, any website with a Manifest file that sets the
display member to
fullscreen will open as a web app when a user taps its icon. This is true no matter which browser added the website to the Home Screen.
If there is no manifest file configured to request web app behavior (and no
meta tag marking the site as web app capable), then that website will be saved as a Home Screen bookmark. Starting in iOS and iPadOS 16.4, Home Screen bookmarks will now open in the user’s current default browser.
New Fallback Icon
Web developers usually provide icons to represent their website throughout the interface of a browser. If icons for the Home Screen are not provided, previously iOS and iPadOS would create an icon from a screenshot of the site. Now, iOS and iPadOS 16.4 will create and display a monogram icon using the first letter of the site’s name along with a color from the site instead.
To provide the icon to be used for your website or web app, list the icons in the Manifest file — a capability that’s been supported since iOS and iPadOS 15.4. Or you can use the long-supported technique of listing
apple-touch-icons in the HTML document
head. (If you do both,
apple-touch-icon will take precedence over the Manifest-declared icons.)
New Web API for Web Apps
Besides Web Push, Badging API, and Manifest ID, many of the other new features in Webkit for iOS and iPadOS 16.4 are of particular interest to web app developers focusing on Home Screen web apps. These include:
See the release notes for Safari 16.4 for the full list of features.
Are you seeing a bug? That’s to be expected in a beta. Please help us such squash bugs before iOS and iPadOS 16.4 are released to the public by providing feedback from your iPhone or iPad. Feedback Assistant will collect all the information needed to help us understand what’s happening.
Also, we love hearing from you. You can find us on Mastodon at @firstname.lastname@example.org, @email@example.com and @firstname.lastname@example.org. Or send a tweet to @webkit to share your thoughts on these new features.