What’s new in web apps

♪ ♪ Hello, I'm Rachel. I'm an engineer on the Safari team. Today, I'm excited to share what's new in web apps. We've been on a journey with web apps since the release of the very first iPhone, and they just keep getting better. In iOS and iPadOS 16.4, we added notifications to Home Screen web apps, using the Web Push standard with support for badging. We also added API for iOS and iPadOS browsers to adopt Add to Home Screen.

New in iOS and iPadOS 17, Add to Home Screen is now available in Safari View Controller. So now users can add Home Screen web apps in iOS browsers and many in-app browsers. New in macOS Sonoma, we now have web apps on Mac. Web apps on Mac let me focus on websites that I use all the time in a dedicated way that's separate from the rest of my browsing. Similar to iOS, the way I can create a web app is by adding a website to the Dock.

I'm browsing Wikipedia, and I'd like to add it to the Dock. I'm going to open the File menu and select "Add to Dock..." Now I can see the icon, name and URL of this site. I'm going to simplify the name. I could also modify the icon if wanted to, but this one looks good. I'll press “Add”, and now there's a new icon in my Dock. I'm going to close Safari for now and open the Wikipedia web app.

Now once I've launched this web app, I can use this site in a way that feels more like an app. I'm still logged into my account. That's because Safari copies website cookies when it is added to the Dock. There is a simplified toolbar with navigation buttons. and the theme color for the site blends into the toolbar. As a developer, you can control whether the navigation buttons are shown. Today, we're going to first cover how web apps on Mac work out of the box for all websites. Then I'll tell you about how you can customize the behavior of your web app to create the best experience for your users. Finally, I'll discuss notifications, including sounds and badging, giving you a way to reach your users even when they're not actively using your web app. Let's start with how web apps work out of the box. Web apps on Mac work great with no adoption required by developers. Any website can become a web app. Web apps on Mac are fully integrated with many of the features that you would expect from a native app on macOS.

Let's take a look at the web app that I already added to my Dock. This site doesn't have any web app-specific features, such as a web app manifest, and it looks great and functions as a standalone web app.

Like all Mac apps, web apps work great with Stage Manager, Mission Control, and keyboard shortcuts, such as command tab.

Web apps can be opened from the Dock, Launchpad, and Spotlight Search.

Web apps work with AutoFill credentials from iCloud Keychain and from third-party apps that have adopted the Credential Provider Extension API.

We put people in control of their privacy, so they can grant camera, microphone, and location access to your web app in the same ways as native apps, through system permission prompts and in the Privacy & Security section of System Settings. That was the default behavior, but you may want to customize the experience for people who use your website. When a webpage is added to the Dock on macOS, it is always treated as a web app. As a developer, you can control the initial behavior of the toolbar for the web app's window. The default behavior shows a toolbar with navigation controls. This is helpful for navigating around sites that don't have their own navigation controls.

You may not want to show the toolbar if your site has its own navigation controls or navigation controls aren't necessary in the context of your site. This is called the standalone display mode.

The default behavior on iOS is different from macOS. A website that has been added to the Home Screen opens in the default browser. This provides a quick way for users to access a commonly-used site right from the Home Screen. Websites that have been added to the Home Screen on iOS and iPadOS, with the standalone display mode, will become a Home Screen web app. Home Screen web apps have a standalone, app-like experience on iOS, with separate cookies and storage from the browser. There's no browser-provided UI, such as a toolbar, and all the content is from the web page. If you want your site to be able to use Web Push and badging on iOS, then you should use the standalone display mode.

To set the display mode. I'll add a web app manifest to my site. The web app manifest is a way for a website to communicate its intended behavior for web app-related features with the system. To add a web app manifest to your website, simply add a link with rel="manifest" to a JSON file in the head of your HTML. I called mine “manifest.json”.

In the corresponding manifest file, add the keys and values that apply to your website. First I'll set the name since this is what I want to be used as the web app name, not the website title, since mine is pretty long.

To change the display mode, I'll set display to “standalone”. On macOS, the web app will not have a toolbar. On iOS and iPadOS, the site will open in a Home Screen web app, instead of in the default browser. Now, let's cover where links clicked within the web app open. All web apps have an associated scope. Links within the scope open within the web app. The default scope is the host of the webpage used to create the web app. You can further refine the scope using the web app manifest to limit it to a specific path on your site. For example, when I click on this link in the Browser Pets web app to go to another page “webkittens”, you'll notice that we stay within the web app since Web Kittens is just another page on our site under example.com. Now when I click on a link to apple.com that will open in my default browser, since that is outside the scope of example.com. If I wanted links to Web Kittens to open in the default browser, like that link to apple.com, then I can adjust the scope in the web app manifest.

To adjust the scope, I'll first start by adding the "start_url". The start_url is the URL that is loaded when the web app is first opened. This will open the home page for Browser Pets. Now I'll add the scope. Suppose I want to separate Browser Pets and Web Kittens into different web apps, then I could limit the scope to just Browser Pets. The scope is a subdirectory of the manifest URL. In this case, the scope will be example.com/browserpets. Any links within the scope will stay within the web app and any links outside the scope will open in the default browser. In Home Screen web apps on iOS, links outside the scope will open in Safari View Controller.

So when I tap this link in this Home Screen web app, it opens in Safari View Controller.

We need to log in to get the most out of many of the websites that we use on a daily basis. As I mentioned earlier, to make web apps work great out of the box for most users, we copy website cookies when a web app on Mac is added to the Dock. In many cases, users stay logged in when the web app is opened for a seamless experience. From that point on, cookies are separate between Safari and the web app. If the authentication state is solely stored in cookies for your site, then your users should be automatically logged into the web app when they add it to their Dock since Safari copies the website's cookies to the web app when it is added to the Dock. Some websites split authentication state between cookies and local storage. Since local storage is not copied when a web app is created, users would have to re-authenticate to continue using your site as a web app. To create a smooth experience for your users, keep authentication state saved within cookies.

As I mentioned before, links that go beyond the scope of the web app will open in the default browser. If the user logs into your web page in their default browser, they will not be logged into the web app that has already been added to the Dock, since cookies and storage are separate after the web app is added. Authentication through OAuth on a third-party domain will still open in your web app. This is done through heuristics. If you test and find that your OAuth flow opens the authentication experience in the user's default browser, please send us feedback using apple.com/feedback. If you want to ensure your OAuth flows do not open in the user's default browser, you can use window.open. Links loaded through window.open will always open in the web app regardless of scope. Apple is engaging with standards bodies to offer developers a way to indicate that links to authentication domains should stay within the context of the web app.

Some websites use email links to automatically sign in users by opening the link. Since links from email will open in the default browser, this will not automatically sign users in to the web app that they already have. You may want to provide an alternative one-time code in the email that your user can easily enter into the sign-in flow on your site. For a more convenient and more secure authentication experience, consider adopting passkeys for authentication on your site. Check out "Meet passkeys" from WWDC22 for more information. Notifications in web apps on Mac is an exciting addition to our existing standards-based Web Push support for Safari in macOS Ventura and in Home Screen web apps in iOS 16.4. Now I'll tell you how you can integrate notifications, including badging and sounds, into your web apps. If you have already implemented Web Push according to web standards, then push notifications should work for your web page as a web app on Mac with no additional work. Notifications for web apps on Mac use the web app's application icon in the notification.

Web Push notifications originating from Safari show the Safari icon, while notifications from web apps on Mac use the web app's icon in the notification, providing context to users.

You may want a sound to play on the user's device when they receive a notification to get their attention, so now I'll tell you how that works on macOS, iOS, and iPadOS. Using the Notification API, you can specify if your notification should have sound or not. Following platform conventions, sound is on by default on iOS and iPadOS, and sound is off by default on macOS. To override the platform default, explicitly specify a silent value. If the notification should be silent, set silent to true in the options when requesting your notification. If the notification should make a sound, then set silent to false. Just like for native app notifications, users can control notification sounds using notifications settings.

Badging is useful to alert users that there is something to address in the web app.

Just like for Home Screen web apps in iOS 16.4, web apps on Mac support badging. Since badging and push notifications are so closely associated on macOS, iOS, and iPadOS, when users allow a web app to send notifications, that includes permissions for the web app to use badging. Badges can be updated when the web app is open and when push events are being handled in the background. Users can always configure badges in Settings.

For more information on adopting the Badging API, check out "Badging for Home Screen Web Apps" on webkit.org.

For more information on adopting standards-based Web Push, check out "Meet Web Push for Safari" from WWDC22.

Home Screen web apps on iOS and web apps on Mac integrate with Focus to give users control over their notifications. Users can set which notifications they want to see in different Focus modes and have their preferences applied to Focus modes across all their devices. Let's take a look back at our web app manifest. The "id" manifest key defines unique web apps within the same domain. This is used for syncing Focus modes and can be useful if you have multiple parts of your website that should be treated as distinct web apps under the same domain. If you only have one web app for a given domain, then you don't need to set the id. The fallback if there is no id provided is the start_url. One of the great parts of Focus is how Focus modes sync across all of a user's devices.

Both you and your users control how Focus mode settings are synced. You as a developer may have distinct web apps for different parts of your site. For example, you may have one web app for your shop and one web app for forums. Here, the “Name" column is the name of your web app on the user's iPhone or Mac. The id key of the web app manifest can be used to indicate that a web app created with the id "shop" is for your shop and the web app created with the id "forums" is for the forums for your community. This way, your users can set different notification preferences for your Shop and Forums web apps. Focus modes sync across a user's device when the name and id align. Users can create multiple instances of a web app for a given site on their device. This can be useful for separating work and personal accounts. The user can choose different names for each instance. In this example "Forums" and "Forums - Work". This way users can set different notification and Focus settings for each of their Forums web apps that sync across all their devices.

There are several APIs that we added to WebKit this year that may be helpful to you when creating your website.

We have support for the User Activation API, which tells the website when a transient or sticky user activation has occurred. This is helpful for you to determine if it is okay to call a function that depends on user activation, such as requesting permission to send notifications. We shipped the updated and un-prefixed Fullscreen API in Safari 16.4 for macOS and iPadOS. We also added preliminary support for the Screen Orientation API, including the type and angle properties and the onChange event handler.

For more information, check out "WebKit Features in Safari 16.4" on webkit.org. Web apps on Mac work out of the box for all websites. You can use the web app manifest to customize the behavior for when your website is added to the Dock. You can implement features that are tailored for web apps, such as Web Push and badging. For more information on developing and debugging your website in Safari, check out "Rediscover Safari developer features" and "What's new in Web Inspector" from WWDC23. Thank you for watching. Enjoy WWDC23. ♪ ♪