Good morning. I'm Chelsea Pugh and I'm an engineer on the Safari team. Welcome to session 225, What's New in Safari View Controller. Safari View Controller has a bunch of improvements on iOS 11. It also has new APIs that were inspired by feedback that we got from developers. I'm really excited to share some of Safari View Controller's new abilities with you today.

One main use case of displaying web content on iOS is to allow users to browse the web in your app. You might be displaying a list of links that could lead the user to news articles or maybe your displaying a list of links that could lead to information of different topics on the web.

It could, these links could your user anywhere on the web, and you don't expect to know where they'll end up ahead of time. How many of you are doing something like this in your app? All right, there's a few of you out there. You're in the right place.

Another main reason that you'd want to display web content on iOS is to allow your users to get authenticated with a third-party service so that it's data can be used in your app. How many of you do something like that in your app? You're also in the right place.

And for those of you that are providing those experiences to your user, how many of you are already using Safari View Controller? Great. If you're already using Safari View Controller, we have some improvements to share with you today that will make Safari View Controller an even better experience for your users. If you aren't using Safari View Controller but you're providing one of those experiences, listen up. The new APIs that we're going to talk about today were inspired by feedback from you, and we think you'll really like to hear about it.

Today I'm going to cover displaying web content on iOS. Then I'll talk about how to really match your app's style using Safari View Controller. I'll then talk about some improvements to Safari View Controller on iOS 11. Then I'll discuss the new APIs that have been added to Safari View Controller to really tailor it to fit your app's use case.

First, displaying web content. There are a couple of different ways, but today I'm going to talk about two of those, using SFSafariViewController and using WKWebView. To start off, let's talk about SFSafariViewController. If you don't know where your user will be going on the web, Safari View Controller is really a good thing for you to use. It gives you standard browsing features so you don't need to worry about implementing an in-app web browser. With just a couple lines of code, you get an in-app web browser with all of the features that your users know and love from Safari in your app.

Safari View Controller is also great for getting users authenticated to a third-party service. It has the security that users need while logging in and it has features that can help them get logged in quickly. One main example is Password AutoFill. They can quickly fill their saved passwords from Safari and log in with a tap of a button.

Now let's talk about WKWebView. If you don't know the web, or if you know the content that you'll be displaying to users ahead of time, or you even have control over the web content, WKWebView might be right for you. It allows you to manipulate the DOM using Javascript. You can also customize navigations by blocking or modifying them.

It's a view of web content, so you can add your own native UI around the web content. This is great if part of your app's UI is implemented using web technologies. The web content can blend seamlessly in with your app's native UI, so users don't even need to know that they're interacting with web content. But let's get back to Safari View Controller since I think that's why you're all here.

Safari View Controller makes in-app web browsing easy. As I mentioned before, with just a couple lines of code, you've got a fully featured web browser within your app. It provides a secure and safe browsing experience for users. Let me tell you about a few of the security features you get with Safari View Controller.

First, process separation. There's your app's content and then there's web content. Safari View Controller is in a separate process from your app. This means that anything that the user does on the web won't have an effect on your app's content. If they browse to malicious web page it won't be able to affect your app's data. You get out of the business of taking care of user security on the web because Safari View Controller will take care of that for you. It provides critical security features. Let's talk about a couple of those.

The lock icon here indicates to the user that they're browsing over a secure connection. This is a really important feature in a browser. And you don't need to worry about implementing it if you use Safari View Controller for your in-app web browser. Safari View Controller will also warn users if they might be trying to navigate to a page that's going to try to steal their information.

This page is trying to imitate example.com to get my information. And you get features from Safari. Let me just highlight a few of the features that you'll get with Safari View Controller. You get AutoFill of passwords, contact info, and credit cards. Users can quickly fill out forms on the web. Reader is an awesome feature for decluttering articles on the web. Our users of this feature love it, and they'll love getting to use it in your app.

ApplePay on the web can help users quickly make payments while shopping on the web within your app. And users get access to the Share Sheet that they get elsewhere on the system. They get access to some standard system activities that they might want to perform, as well as any third-party extensions that they have access to in Safari.

And they get content blocker extensions that they'd have in Safari. This means they won't be confused about why their ad-blocker isn't working when browsing the web in your app. And there are so many other features that you get by implementing Safari View Controller as your in-app web browser.

Now, I'd like to talk to you about how you can better match your app's style with Safari View Controller on iOS 11. There are a couple of new ways. First, it has a new look. If you've seen Safari View Controller prior to iOS 11 you might have noticed that it looked a lot like Safari. Let's take a look on iOS 11. It looks more like an in-app web browser so users don't feel like they've jumped out of your app. This is the design on iPhone. It looks great on iPad too.

Now I want to talk to you about customizing the color of Safari View Controller so that it fits with your app's color scheme. The ability to customize Safari View Controller's color was available prior to iOS 11, but we've made an improvement that I really want you to know about. First, let's recap the customizations. This is a default Safari View Controller. It has the same color scheme as Safari, blue and white. But let's say my app has a different color scheme, black and aqua.

Here I started using my app's color scheme in Safari View Controller. So, when I present Safari View Controller to my users it doesn't feel like they've left my app. And it's a really seamless experience. You can set these colors by modifying properties on SFSafariViewController. To set the color of bars surrounding web content you can use preferredBarTintColor.

And to set the color of the controls shown here, you can use preferredControlTintColor. Now let me tell you about an improvement to preferredBarTintColor on iOS 11. This is my app. I'm using my favorite shade of red for its bar color. Here's what it would look like if I set that exact same shade of red to Safari View Controller's bar color on iOS 10.

As you can see, they don't quite match up. And it doesn't feel exactly like my app. It looks great, but it's not as close as it could be. Let's take a look on iOS 11. Now, the bar colors match up. It's just as if I was setting the bar color on a standard UI navigation bar or UI toolbar. So, it looks really great and it fits well within my app. Now, I'm delighted to invite my colleague Louie Livon-Bemel to the stage to show you just how easy it is to get Safari View Controller matching your app's style. Thank you.

Thanks, Chelsea. Hi, I'm Louie, I'm an engineer on the Safari team, and I'm really excited to show you just how easy it is to customize Safari View Controller to match your app style. I'm working on an all new version of my app, Pizza Finder. It's the best app for finding great pizza near you when you're working on or even watching a demo.

Like many of your apps, this app uses a standard UI Navigation Controller. I've got a list of pizza places here, and when I tap one, a new view comes in from right to left with more details. The default presentation of Safari View Controller is a lot like this.

When I tap on the website, Safari View Controller came in from right to left just like a UI Navigation Controller. Users can even interactively edge swipe back when they're done browsing. So, this is great. I have a very standard UI here that my users are used to from Safari and any other app that's using Safari View Controller on the system.

Users even get really advanced features like in the Share Sheet all the activities they're used to from Safari and the powerful third-party extensions that they're used to using. However, this isn't perfect. It sort of feels like you're somewhere else. You might be in another app or somewhere else on the system or somewhere else in my app, it doesn't, it's not clear that you're still within Pizza Finder. So, I want to show you how to improve this.

Here's where I'm presenting Safari View Controller in my app. It's really simple. All you need to do to adopt Safari View Controller is do two things. The first one, is create a Safari View Controller using the URL that you want to lead to. The second thing you need to do is present it. And that's it, that's how you adapt Safari View Controller. But let's make a few changes.

So, I've done two different things here. The first one is setting the preferredBarTintColor to the same bar color I'm using elsewhere in my app. In this case it's that orangish red color. Second thing I'm doing is setting the preferredControlTintColor to the same control color I'm using elsewhere in my app, in this case that's white. So, I'll rebuild and I'll show you how these changes affect Pizza Finder.

Now when I look at a pizza place, and go to their website, Safari View Controller matches my app's branding and it's really obvious that I'm still within Pizza Finder. It doesn't feel like I'm somewhere else. That's just how easy it is to customize Safari View Controller to match your app style and get your app's branding. Thank you so much, and I'll now hand it back over to Chelsea.

Thanks, Louie. Louie just showed you how easy it is to get his app's branding in Safari View Controller. With just a couple lines of code, he had Safari View Controller up and running with his app's color scheme. We can't wait to see how good Safari View Controller's color schemes look on your app.

Now, I'd like to talk to you about some improvements that we've made to Safari View Controller on iOS 11. There are five key improvements that I'm going to talk about. You may have heard about the new feature on iOS 11, Drag and Drop. I'm excited to let you know that on iOS 11, Safari View Controller has Drag and Drop out of the box. Users can easily drag URLs out of Safari View Controller into other apps. Now I'd like to talk to you about some improvements to how Status Bar styling works in Safari View Controller.

When presenting Safari View Controller in some apps, the Status Bar can become difficult to read. It's hard to even notice here, but I have a dark purple bar, with a black Status Bar text on top, and it's illegible. Ideally, you'd want white Status Bar text so that the user can easily read the Status Bar, but if you just hard code a specific Status Bar style, you're not fully fixing the problem. Other views can be presented in Safari View Controller such as the Messages extension, or a full-screen video. Here the user is sharing to Messages so the white Status Bar style that's been hard coded is illegible over the white bar of the Messages view.

The bottom line is that other views can be presented in Safari View Controller. Safari View Controller has improvements to better adapt the Status Bar style when other views are presented on iOS 11. In order to allow this to work, you'll want to use UIViewController-based Status Bar appearance. This has been the recommendation for all apps since iOS 7.

To do this, you can set UIViewControllerBased StatusBarAppearance to yes in your app's Info.plist. This will ensure that the Status Bar remains legible even when other views are presented in Safari View Controller. Now I'd like to tell you about another improvement, but it requires a bit of background. So, I'd like to explain a scenario in Safari to start. A common experience on the web is checkout with a third-party service. Here I have a page that's asking me to checkout using Example Checkout.

When I tap buy now in Safari, a new tab is opened and I'm able to complete my payment. When I tap Buy Now on Example Checkout, I -- and complete my payment, the tab that was opened is closed and I'm back on the store site that I was on. And the store knows that I've completed my payment. This is an example of what happens when a webpage calls window.open and subsequently calls window.close. It previously wasn't supported in Safari View Controller because Safari View Controller doesn't have tabs. But on iOS 11 Safari View Controller supports window.open.

[applause] It's pretty great, yeah. The way that this now works is in Safari View Controller when I tap Buy Now a new, I've navigated forward instead of opening a new tab. Once I've completed my payment after tapping Buy Now, I'm navigated back to the page, the domain I was on and the page knows that I've completed my payment. So, I get a confirmation in Safari View Controller. This is new to iOS 11. Now I'd like to talk about some privacy improvements on iOS 11 in Safari View Controller.

Browsing the web in your app is different than browsing the web in other apps. It's different than browsing the web in Safari. I sometimes want to use different accounts when browsing the web in different apps. For some apps, I'll use my work account and for other apps I'll use my personal account. On iOS 11, Safari View Controller will have a separate persistent data store in each app that it's used in. This means that cookies, local storage, and other browsing data will be contained within your app and scoped to your app.

And this means that the user won't automatically be logged in to whatever accounts they were logged into in Safari. What this does is it will prevent cross-app tracking of user's browsing activity that you and your users may not have even been aware about. And ultimately, it helps keep users' browsing activity private and scoped within your app.

Now I'd like to talk about a change to Private Browsing in Safari View Controller. Now that Safari View Controller has its own separate persistent data store for each app, it's browsing mode is no longer tied to Safari's this means that I now longer get the following frustrating experience. I'm browsing the web in Safari in Private Mode.

Time passes and later that day after I've forgotten that I was even in Private Mode, I go to my favorite app that opens links using Safari View Controller. Safari View Controller is presented in Private Mode once I open a link and that's confusing to me because I didn't intentionally tell it to open in Private Browsing Mode.

So, on iOS 11 now that Safari View Controller has its own browsing mode, it's no longer tied to Safari's. That means that your apps' color scheme will be used more often. Now I'd like to tell you about three new APIs that we've added so you can really tailor Safari View Controller to fit your app's experience. First I'd like to talk to about how you can now customize the Dismiss button of Safari View Controller.

Language is very important when conveying intent to the user. The standard Dismiss button style for Safari View Controller is Done. This works really well for a standard browsing case, because the user can browse through a bunch of different web pages and then when they're finished browsing tap Done to indicate that they've ended their browsing session.

On iOS 11 we've added two new options that this Dismiss button can take on. The first of those options is Cancel. I think Cancel makes a lot of sense when I'm getting my user's authenticated to a third-party service. The user will know that if they tap that button, they're not really authenticating with my service, they're cancelling the transaction. The other new style is Close. This makes sense if I'm presenting some transient web content to the user, perhaps a Terms of Service page.

I'm giving them a page where they're probably not likely to follow other links, so they'll just Close once they've finished reading what I've presented to them. Now I'd like, or the Dismiss button style is a property on SFSafariViewController. As I mentioned it has these two new options. The default style will be Done but you can choose which ever style best fits your use case of Safari View Controller. The value can even be changed while Safari View Controller is presented, which Louie will demonstrate later. Now I'd like to talk to you about a customization you can make to the Share Sheet in Safari View Controller.

Let's say I'm presenting a login flow to the user. When the tap the share button they have all these different actions that they can take, but some of them don't really make sense in this case. They're probably not going to send the page somewhere else because it might disrupt the login flow and the login might now even work outside of the context of my app.

Here, I've filtered out, so this is what the actions that I don't want to show. On iOS 11 we're giving the ability to filter out some of these UIActivityTypes. Here, I've filtered out AirDrop, Mail, and Messages because my users don't need them in this case. You make recognize this API on UIActivityViewController. It allows you to set an array of UIActivityTypes that the user doesn't need on your UIActivityViewController. We realize that if you're implementing your own in-app web browsing experience, you'd have the ability to customize the Share Sheet in this way.

So, in iOS 11 we're exposing this same ability on SFSafariViewControllerDelegate as a method where you can return an array of UIActivityTypes that you don't want to be presented to the user in the context of your Safari View Controller. Now, I'd like to talk about Bar Collapsing in Safari View Controller.

Safari View Controller's bars collapse away while in browsing, which lets me really get immersed in my browsing experience. However, in some cases this bar collapsing behavior can be frustrating. Let's say I have a login flow. If bars are collapsed, the Dismiss button gets hidden. So, it's a bit more difficult to Dismiss Safari View Controller.

So, in something quick like a login flow, this standard bar collapsing behavior might not necessarily make sense. On iOS 11, we're allowing you to disable this standard bar collapsing behavior if it best fits your use case. This will be a new property on SFSafariViewController .Configuration which will be passed into Safari View Controller's initializer.

It's best to leave this enabled if your use case is show user's browsing, or user's content that they should really get immersed in. But, if it's important to always have the Dismiss button shown, you can disable this property. Now, I'd like to welcome Louie back to the stage to show you how easy it is to use these new APIs to tailor for his app's experience.

Thanks, Chelsea. I'm thrilled to show you how easy it is to customize Safari View Controller using these new APIs and I'm going to give you a sneak peak at the next app I'm working on. It's another pizza related app, so I hope that's not too cheesy. [laughter] This is a social app called Pizza Stories. It allows you to share all the pizza related news in your life in a visual format with your friends and family.

By default, it when you're not logged in, you get a list of pizza brands that are sharing some stories. However, to get the best experience out of this app, you'll want to log-in. I don't want users to have to create and maintain a list of their friends in my app, and I don't own a social network that already has this, so I want them to be able to use an existing list that they've already used and created all of their friends on an existing social network. I'm using Safari View Controller to let them log-in and authenticate against this social network. I tap Log In, Safari View Controller is shown and let's my users log in with SampleChat a really popular demo social network.

You may have noticed that Safari View Controller came in from right to left like a UINavigationController. My app doesn't use this paradigm, so that feels a little weird. I have already made it so that Safari View Controller takes on the colors of my app, but the transition didn't feel right for my app. Similarly, saying Done doesn't really make sense here. I want to communicate to my users that tapping this button will cancel this login session. So, it's clear what's going to happen when they tap it.

And if my users are reading the Terms of Service and they scroll down a little bit, the bars collapse. This might nice in some other web pages, but here it could just get annoying. If they want to cancel, it's two taps away instead of one. So, I'll show you how to improve Safari View Controller to fit this log in a little bit better.

Here's where I'm presenting Safari View Controller. Like before, it's pretty simple. I'm creating a URL and then passing that to Safari View Controller's initializer. Customizing the colors as I showed you before. And then presenting Safari View Controller. But let's make some changes. First, let's make sure that the bars don't collapse when they scroll down.

So, what I've done here is created a Safari View Controller configuration object and then set its barCollapsingEnabled property to false. This way when they scroll down the bars won't collapse, they'll still stay full height. I then pass this in to Safari View Controller's initializer. Let's make a couple other changes.

I've done two different things here. The first, is setting dismissButtonStyle to Cancel so that the button will say Cancel instead of Done, which is the default. Second change I've made is slightly more complicated. I'm overriding the transitioningDelegate of Safari View Controller to myself. Since I haven't implemented any of the methods of UITransitioningDelegate, I'm just going to get the standard system default behavior where a view comes in from bottom to top. I'll rebuild and show you how this works in Pizza Stories.

Now when I tap Log In, Safari View Controller came in from bottom to top. Now you may notice here, the view is blank. This is a bug on Seed 1. If you do run into this, I'll show you how to fix it. You can either pull down Notification Center or press the Home button and then go back in and the page loads. So, in addition to the new presentation, the Dismiss button says Cancel to better indicate to my users what tapping this will do.

And when I scroll down, the bars don't squish. So, we're almost there. However, there's one more change I want to make. Right now, it makes sense for the button to say Cancel. But, when my users successfully logged in, it shouldn't say Cancel. I want to indicate to them that it's okay to dismiss after that.

So, as Chelsea mentioned before, what's really cool about this property is it can be changed even after I've already presented Safari View Controller. When my user logs in with SampleChat, they redirect to a URL scheme that my app handles. That gets handled in my AppDelegate in this method. And what I'm doing here is I'm making sure that there's a log in token to indicate that the user's authenticated, then I'm sending a message to elsewhere in my app giving it that token.

I'm handling that here. And I'm doing that because I like to keep this code organized. I want everything related to Login in one place rather than having it in a few different places. Now that I know that the user has successfully logged in, I can change the dismissButtonStyle of Safari View Controller to Done instead of Cancel. So, I'll rebuild and I'll show you how this all comes together in Pizza Stories.

Now, when I tap Log In, Safari View Controller is still presented from bottom to top and the button initially does say Cancel. With just a couple taps I can use AutoFill to log in. Now, SampleChat is asking the user if they want to allow this app, in this case Pizza Stories, to use their account for their friends list and their email. I'll allow that. And now that I'm logged in, the Done button, the Dismiss button has changed to say Done to better indicate to my users it's okay to dismiss now.

Thanks. So, when I dismiss, now I get all of my friends showing up in my, and I can see all their stories. This might make me crave some pizza later on though. Thanks, and this is how easy it is to customize Safari View Controller using the new APIs in iOS 11 to tailor it to your app and make a great log in experience. Thank you so much and I'll hand it back over to Chelsea.

Thanks, Louie. I think Louie is going to making a lot of dough off that one. [laughter] Louie just showed you how with a few key improvements, he made, he took his log in flow with Safari View Controller to the next level. He did this by using a custom presentation style that it felt more like the presentation style in his app. He changed the Dismiss button to say Cancel so that users know that if they tap that button they'll be cancelling log in with the third-party service he's asking them to log in with.

He turned off bar collapsing. This way if the user reads the Terms of Service and decides that they don't want to use that service, they can quickly tap cancel to exit Safari View Controller. And he changed the button to say Done once the user had allowed access to that third-party service. This way they know that they've finished logging in.

One of the main things that we want you to get out of this presentation is that we hear you. The new APIs that we've talked about today were inspired by feedback from you. We really encourage you to keep giving us feature requests and filing bug reports. And also letting us know if there are any other customizations you'd like to see in Safari View Controller. So, keep talking to us.

In summary, Safari View Controller gives you an easy in-app web browsing experience. With just a couple lines of code, you can get Safari View Controller up and running in your app. Safari View Controller is perfect for authenticating with third-party services because it provides a security that users need and the features that they love while getting logged in.

There are many improvements to Safari View Controller on iOS 11. Safari View Controller's new look and the new APIs that we've introduced can help Safari View Controller feel at home in your app. If you've taken a look at Safari View Controller in the past but maybe it didn't quite fit your use case, we encourage you to take another look. These improvements on iOS 11 and the APIs that have been added were inspired by you. So, we really hope there's something in there for you.

For more information on this session you can view the page listed here. I'd like to tell you about some related sessions that you might be interested in. These are all available on the WWDC website and app. We've talked a lot about getting your user authenticated with a third-party service using Safari View Controller.

But if you want to make authenticating with your own service a better experience for your users you can watch Introducing Password AutoFill for Apps. If you want to learn about new APIs in WKWebView, you can watch Customize Loading in WKWebView. And to see more background on Safari View Controller you can watch Introducing Safari View Controller from WWDC 2015. Thank you so much. I hope you have a great WWDC 2017.