Hello and welcome to WWDC! Hello everyone. Welcome to Discover WKWebView Enhancements.
My name is Brady Eidson and I'm an engineer on the WebKit architecture team.
I'm genuinely excited to talk to you today about new features of the WKWebView API. At Apple, we love the Web. We pay great attention to detail, making sure that the WebKit framework is fast, responsive, secure, and efficient so that our favorite browser, Safari can be all of those things. But we don't only love exploring the web in a browser. We love seeing web technology used everywhere. And our platforms enable amazing integration of web content with native experiences. If you primarily need an in-app web browser and don't need deep customization of that experience SFSafariViewController is the best choice for you and your users. It handles all of the things you'd need to worry about while implementing a basic browser and beyond.
Your users get reader, content blockers, autofill, and more, and you get a browser in a box. Add it to your app and give it a URL to load. SafariViewController is easy to use but powerful, because it is built on top of WKWebView. When you need a higher degree of configurability or are using web content in ways unrelated to browsing, you can also build on WKWebView directly.
WKWebView automatically protects your application's code and data from the complexities of the web platform. By isolating web content in a separate process this enables fast execution of web content while also providing protection against malicious actors. SafariViewController uses WKWebView because of those benefits, and they are also why for years we've strongly recommended WKWebView over other alternatives. Speaking of those other alternatives, WebView and UIWebView were our original APIs for embedding web content.
They've served us well, but for all the benefits WKWebView has, they tend to have the parallel drawbacks, which is why they've been deprecated for a few years now and why we're striving to drive their usage down to zero.
The deprecated web use work so differently from WKWebView, it wasn't desirable or even possible to make WKWebView APIs work exactly the same.
With that change, scrolling works as expected. Now that I can scroll through the newsfeed at will, I want to make sure viewing the comments on the post works.
Let's take a closer look at that.
The Web page expects the symbol comment details to be a function, but it isn't.
Let's see what using it does to that code.
I was able to apply a few more new APIs that we have to allow for more flexible rendering. This is relatively old web content from before when the phrase responsive design had even been coined. The original Web Kitten's app looked pretty good on early iPhones, because the authors had tweaked it for that specific purpose. This is how viewing a comment on the original iPhone looks. This is how viewing a Web kitten's comment looks on a modern iPhone, much larger than when the Web Kitten's app was originally written.
You can see the beginnings of a native UI I'm adding to Browser Pets to allow returning from a post to the newsfeed. The Web content itself looks passable, but there's also lots of negative space. It looks more like a 2005 era Web site in a browser. I think I can adapt the site as is to make better use of the space to make better use of the screen and to fit in better with native UI. I decided to see if I could throw some CSS at the problem, to fill my user screens. The CSS zoomin property has been with WebKit for a dozen years, and I think it might work here applied to the entire body element.
As long as the zoom value is big enough it caps to take up the entire viewport width, which is perfect in effect, but the way I'm doing it here is a bit clunky.
Now I remember Beth made this hilarious joke in those comments. But scrolling through to find it seems cumbersome. I'd rather have a find in page feature.
But WKWebView now has an easy to use find functionality that behaves like others on the platform. And that's just what I'm looking for. I have a few things I can configure about the find, like any find an AppKit and UIKit APIs.
The direction, case sensitivity, wrapping or without any configuration it will just use sensible defaults. If a result is found it is selected and scrolled into view. Voila. That joke is just not quite as funny as I remembered it.
Now another thing a proper app needs to do is share content, and I can think of no content more worth sharing than the cutest web kittens and the most adorable pups on Safari. For a few years WKWebView has supported the ability to take a bitmap snapshot of its contents. This is useful in so many situations, but it is limited to the screen content no matter how much content is actually there. So we had a feature to zoom in on the full resolution version of this photo. For example we could only capture what's visible.
And this is not to mention depending on your goal, bitmap[ed images might be a poor fit. I think another great way of sharing this content would be as a pdf. And this year WKWebView will support just that. You can configure a few things about how you want to capture the pdf, or if you just want to pdf of all the content in the view, including content not currently visible on the screen, call createPDF with the default configuration.
This code will share this entire post, including all the comments in a searchable text form in one pdf document that would look like this.
I told you it's a popular post. Another type of content snapshot that I often find useful when working with WebKit is the Web archive. A Web archive is an actual rich snapshot of the current dom of the Web content and the sub resources it would need to render. In addition to being a file format supported since the first public release of the WebKit framework, it is also the native pasteboard format for web content on all of our platforms.
When I was first debugging issues with the combined newsfeed and browser pets, I wanted to leverage Web archives to help me while WKWebView has been able to load a web archive of files since its first release. It hasn't been able to save them, until now. With createWebArchiveData, I can now take that snapshot of web content for later debugging and testing. Like taking a bitmap snapshot or creating a pdf, it's a simple method of requesting the Web archive data and getting the result in a completion handler.
I can save this data off the disk for later use, put it on the pasteboard, or even loaded into another WKWebView right now. As I mentioned, WKWebView has always been able to load Web archive files. I've heard from a few developers that they thought that was not the case. So I just wanted to share the code I use to load a web archive, which is load data, with the appropriate mimetype. With bitmap snapshots, pdfs, and Web archives we have a growing number of ways to get stuff out of a WKWebView. There is one more important one. As I mentioned before, web kittens and pups in safari are mission critical tools. And some team members even rely on the ability to print out their favorite pets on actual paper for proper motivation throughout the day. Since browser pets is brand new, I am of course using SwiftUI and have been able to build a Mac version of the app. But I know printing is important to these team members. Printing WKWebViews has been possible on iOS for a while, but Mac developers have not been so lucky.
Until macOS Big Sur. If this interests you, go looking for it in your SDK and give it a whirl. Before we get to a few more an APIs that help you in the app side of things. I know many of you are also focused on the web content itself. We're always working on new web facing features that can shine on our platforms, and this year is no exception. Once we're done here I encourage you to take a look at the What's New for Web Developer session.
Finally I'm happy to share with you exciting announcements regarding user privacy and how they affect developers using WKWebView. You might have heard Apple say this before but just in case I'll repeat it now. We firmly believe the privacy is a fundamental human right and that belief is legitimately one of our core values. We've designed iOS and the App Store with this in mind. We strive to prevent any native app from using private information without user consent. Not only at the policy level, but also at a technical level.
And we get better at this every year. The web is different, when users browse the wild web. They are often being watched by at least one party. There is no curator and some web technologies seem to have evolved to encourage tracking users instead of preventing it. We realized that with WebKit, we could do something about this. So we started working on intelligent tracking prevention or ITP. ITP uses various client side heuristics and machine learning to identify, classify, and thwart trackers. We've improved it continuously since we added it to Safari in 2017, and we won't stop.
Since we added ITP to Safari, many WKWebView developers have been asking us to use it in their apps.
And we're happy to announce that in iOS 14 and macOS Big Sur, ITP is enabled by default an all WKWebView apps. Users have the control here.
For example if you have a general purpose web browser, your users might need to disable ITP for compatibility with the web site you don't control.
Most people will not fall into this situation, but there is API for you to point users towards disabling it, just like we've seen with Safari.
Intelligent tracking prevention has proven to be a powerful way to protect user privacy in the web. But we didn't stop there. While trying to think of other ways to protect users on the web. We identified three common ways web content is used in an app. The easiest to understand perhaps, is the general purpose web browser, like Safari. The primary purpose of these apps is to show web content from any source and to help the user manage the things important to them, related to the task of web browsing. On the opposite end of the spectrum, from a general web browser, is an app that stays in the confines of only one or a few sites. No matter their balance of native UI and displaying Web content. The Web content itself is part of the core implementation of the app. And then there's the in-app browser. Often starting from a domain specific to the app, they aggregate content from a lot of different sources, usually allowing users to start browsing for any of them.
A prime example is a social media newsfeed much like browser pets. For these last two types of app, WKWebView has a new feature called App-bound domains.
The idea is simple, you specify which domains are the core part of the implementation of your app. This empowers you to design a secure app, by implementing the principle of least privilege. Deep interaction with the web content not core to your app is disabled. For both the code you write and any other code you might bring in from frameworks or libraries. This affects me with browser pets. Comments on a post can have links to other domains to learn more about cats and dogs. I want to allow these links and I can do so safely as long as I limit my outbound domains to web kittens and pups on safari.
It would become impossible for user data to be accidentally compromised on these other domains where I don't have a deep understanding of the structure or function or intentionally compromised if my users run across a bad actor in the Web. I don't necessarily know what nefarious plans the developers of this site might have. Adopting it is easy. You just need to add an entry for WKAppBoundDomains to your apps info P list and point it to an array of domains.
Here's how I adopted it in browser pets. Loading any other domain still works, but deep interaction with other domains is prevented at a technological level.
It's even possible to disable deep interaction with all domains in your app, by simply adding the key to your info list with an empty set of values.
All of these features were driven directly by developer feedback. We know we haven't got to everyone's requests, but remember we are not done. We can't wait for you to try out these new APIs and we genuinely want to keep hearing what else you need in WKWebView. In addition to feedback with Apple, WebKit.org has multiple ways to reach out, including a link to our Slack and to our many mailing lists. WebKit is very open source, so this is also where you can learn to check out and build, as well as file bugs.
We're also on Twitter. If you want to stay on top of new web facing features, web Inspector enhancements, and other goodies you might see in future releases, we usually update Safari technology preview every two weeks. Purple Safari deserves a home in your dock.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.