What’s New for Web Developers 

Session 518 WWDC 2019

WebKit provides a rich set of classes designed to load, display, and manage web content in your app. Discover how to integrate your web content into powerful platform features including Dark Mode, new presentation features in Share Sheet, JavaScript payment APIs for Apple Pay, and more.

[ Music ]

[ Applause ]

Good morning, everyone.

My name is Devin.

I’m thrilled to be here today with all of you to tell you about what’s new in WebKit.

There’s a lot we have to talk about today, so we’re going to dive right in.

There are a lot of things that are new and exciting for the web platform and for web developers this year.

Today’s talk is going to cover a variety of different topics ranging from web specific APIs to new ways that you can provide a more native experience from within your web content.

We have a lot to discuss, so we’re going to dive right in starting with Dark Mode.

The system Dark Mode was first introduced in MacOS Mojave.

But this year, it also comes to iOS as part of iOS 13.

This means that the desktop experience and the mobile experience can now both adapt to Dark Mode.

But don’t worry.

It, it’s not that complicated.

It’s very easy to have your web content also adapt to Dark Mode.

Let’s take a look at it.

First, adding a color scheme CSS property to any root CSS rule with a value that includes dark will tell WebKit that the entire page supports Dark Mode.

And when in Dark Mode, the default text and background colors, as well as any form controls, will automatically update to match the rest of the darker theme.

But as you can see, this won’t do anything for custom styles.

So, you’ll still need to update them yourself.

The way you can do that is using a prefers color scheme dark CSS media query.

It behaves just like any other CSS media query, meaning that the contained styles only apply when the system is in Dark Mode.

You can use this to change any other custom styles like CSS images or other colors to match the rest of the darker theme on the page.

But for images that are not in CSS, you can always use the picture element through HTML.

And using the exact same media query it will cause the two images to automatically switch between when the user enables Dark Mode.

It’s that simple.

And obviously, for any other content, you can always use the JavaScript matchMedia API, again, with the exact same media query to handle any other dynamic content.

All of these techniques make it really easy for you to adapt Dark Mode to support the rest of your web content.

And we can’t wait to see your super cool dark websites.

For more information about this, there’s a great post on the WebKit blog and a great video in the WWDC App that talks all about supporting Dark Mode in web content.

Be sure to check it out.

And that’s a very quick look at how to support Dark Mode in your web content.

It’s very easy.

Next, let’s talk about a very simple API that you can use called Web Share which allows you to invoke the native share sheet from within web content.

It’s standardized and it works anywhere, whether that be in Safari or in WK web view in an app.

It’s especially great on iOS this year with all of the improvements to the native share sheet.

Using it is as simple as calling navigator.share with the relevant data.

It returns a promise which resolves if a share action is completed or rejects if the share sheet is dismissed.

But keep in mind this API expects to be called in response to a user gesture like a tap.

So, if that’s not the case, it will immediately reject.

One of the cool things is that you can already see the Web Share API in action as it’s been adopted by some pretty major websites.

A great example of this is Twitter which also has some phenomenal support for Dark Mode.

Tapping any of the Share icons on the page will open the native share sheet with the title and link of that tweet.

And you can try this out for yourself in iOS 12.2 or later.

And that’s the Web Share API.

A really simple way to invoke native functionality from within your web content.

Now, let’s move a little bit on to some new media features.

If you’re developing a website that strives to display the content that is best suited for the user’s device.

You can now use the new Media Capabilities API to determine whether any video codec is supported as well as if that video codec will be fast enough to knock off any frames or will be power efficient during playback.

This empowers you to make a more informed decision about the type of content you want to present.

And speaking of video content, macOS Catalina and iOS 13 also bring support for alpha channel video.

Alpha channel video allows for any HEVC encoded video content to contain transparent pixels.

A very compelling use case of this is that it allows your video to seamlessly integrate with the surrounding content when the user enables Dark Mode.

Instead of making two separate videos, one for use in Light Mode and one for use in Dark Mode, a single video with a transparent background would likely work for both.

And alpha channel videos can be used anywhere that videos can be used today.

There’s no special syntax, there’s no special MIME type.

It just works.

But before you use it, you’ll want to make sure that alpha channel video is available, such as on older iOS or older macOS, which you can do by adding an alpha channel key to the, to your capabilities object when using the Media Capabilities API.

If you’d like to know a little bit more about alpha channel video, including how to create those videos on macOS Catalina, be sure to check out the video about creating HEVC videos with alpha.

But if instead, you’re a web developer who builds a website that includes peer-to-peer chat functionality and you also want to provide screen capture, you can now use the getDisplayMedia API in Safari 13.

Calling it will gain return a promise and immediately prompt the user for permission to capture their screen.

If that permission is granted, the promise will return with a standard media stream of the space that contains the Safari window.

The returned media stream behaves just like any other standard media stream, meaning that it can be used with WebRTC to share your screen with another person.

And those are some of the new media features coming to macOS Catalina, iOS 13, and Safari 13.

Now, we’re going to talk a little bit about a few new tools that you can use to make your web content more responsive and performant on all platforms.

As web developers, part of our job is to make sure that we provide an experience that doesn’t consume too much battery or unnecessarily perform actions.

To help you better understand why those things might be happening, the Web Inspector has added a new CPU Timeline.

This interface is packed with actionable information.

And we really want you to be able to use it effectively.

So, we’ve created a post on the WebKit blog and a video in the WWDC App all about understanding CPU usage with Web Inspector.

Definitely check it out.

It’ll do wonders for your website.

And WebDriver is coming to iOS.

The standardized test format from the W3C for automation and regression testing is available on all iOS devices running iOS 13.

You can use WebDriver to automate regression testing of your web content and make sure that your, all the platforms you support, whether that be desktop or mobile, keep working exactly as you would expect.

WebDriver on iOS works much the same as on macOS.

And we have phenomenal documentation for that on developer.apple.com.

And we have some blog posts coming soon to talk more about it.

Now, let’s change it a little bit and talk about how to store structured data from within your web content.

There have been two main ways of doing this in the past; IndexedDB and WebSQL.

In Safari 13, WebSQL has been completely removed.

All modern web browsers, including Safari, support IndexedDB.

And over the past year, we’ve been hard at work making it more standards compliant.

So, if you haven’t already, be sure to transition to using IndexedDB as soon as possible.

And finally, let’s talk about Apple Pay, the easiest way to accept payments on the web.

We have two main things to talk about.

The first, Apple Pay, is now fully supported with all of its capabilities using the Payment Request API.

Bringing the entirety of Apple Pay JS’s private, secure, and streamlined experience to your web content in a more standardized way.

We strongly encourage you to switch to the Payment Request API as it supports everything that Apple Pay JS can do and it’s continuing to evolve.

For a deeper dive into how to use the Payment Request API for Apple Pay, there’s going to be a great post on the WebKit blog later today that’ll do a deep dive into these new improvements.

And second, in iOS 13, you can now use Apple Pay inside a WKWebView.


[ Applause ]

This means that Apple Pay is now available in even more apps.

But there are a few things to consider.

When a user attempts to make a purchase through Apple Pay, there’s an expectation that they’re communicating with the page, not the containing web browser or app.

Nothing should get in between the user and the webpage during the transaction or before it’s even started.

So, this means there are fewer restrictions about when you can use Apple Pay inside the WKWebView as well as when you can inject script into a WKWebView.

Here’s how it works.

If any script has ever been injected to the current page of the WKWebView, we will not allow Apple Pay.

If the current page has already called canMakePayments with an Apple Pay payment method, we will not allow any future script injections.

They will be blocked with an error.

But both of these restrictions are only limited to the current page.

So, any top-level navigation will cause them to reset.

So, what does all of this mean?

If you’re a web developer, it’s really important that you call canMakePayments before you attempt to show an Apple Pay button or even start anything with Apple Pay.

This way, your users will never encounter a situation where an Apple Pay button is shown and tapping on it doesn’t do anything because it’s been disabled.

And if instead, you’re an app developer, really think about whether you actually need to inject script such as through the WKUserScript API or the evaluateJavaScript with completionHandler call.

We’ve seen some examples in the past of apps injecting script when there’s a WebKit API that does the exact same thing.

There’s no reason for that.

By injecting script, you could be preventing the loaded web content from providing its best experience.

And that’s what’s new with Apple Pay.

This was a quick look at some of the great features available that are new for web developers this year.

You’ll also definitely want to check out Introducing Desktop-class Browsing on iPad, which covers how to use some other new web platform features like pointer events to really make your desktop website feel right at home on iPad.

I really hope you’ve enjoyed learning about what’s new for web developers.

We can’t wait to see what beautiful designs and incredible experiences you craft with these new features and tools that are available to you.

Have a great day.

[ Applause ]

Apple, Inc. AAPL
1 Infinite Loop Cupertino CA 95014 US