The new SFSafariViewController class enables you to deliver interactive web content in your app just like Safari, including the key Safari UI elements already familiar to your users. See how to easily bring Safari features like Reader and AutoFill into your app, and provide a great web viewing experience with fewer lines of code.
RICKY MONDELLO: Good afternoon everyone.
Welcome. Before we get started I just want
to get a little feel for the crowd.
Little show of hands.
Please raise your hand
if you have an app that's currently being distributed
on one of the App Stores.
That's a lot of you.
Welcome, you're at the right place, it's WWDC.
And how many of you are just learning how to write iOS, Mac,
or Watch apps now and just getting started?
A few of you.
Welcome to you as well.
And of all of those apps that you've built or you're thinking
about building, how many of them are a dedicated web browser?
Okay. A few of you.
Not that many.
But how many of you have a miniature web browser that's
within your application that you show whenever a user taps on --
oh my God, all the hands are up.
Yes, my name is Ricky Mondello, I'm an engineer on the Safari
and WebKit team, and my goal for the next half hour is to get all
of you out of the business
of writing those miniature web browsers.
[ Cheers and applause ]
RICKY MONDELLO: I'm going
to show you how you can use either Safari
or the new Safari View Controller to give you more time
to focus on the parts of your app
that are special to your app.
And to give your users features
that they already love from Safari.
So if you're ready, let's get started.
At the center of this topic is web content.
And web content comes in all sorts of different shapes
and sizes, but for today's discussion I'm going to lump it
into two different buckets.
The first bucket is content within your app
It's content that you own or content
that you're giving a special presentation to.
The important part, is that it's not content that looks
like a traditional web browser.
It's not when a user is browsing on a website.
Which brings us to the second case.
When a user taps a link in your app and you want
to show them a view that's kind of like Safari,
so they can do some short-term browsing.
This session is primarily focused on the second use case.
We're going to see how both Safari
and Safari View Controller can add years of features
and polish to your applications.
But before we do that I want to touch
on that other use case real quick.
If you're using web content within your app but in a way
that doesn't look
like a traditional web browser you might be using WKWebView
or UIWebView, but WKWebView is the preferred tool
to do this; it's your friend.
It was introduced in iOS 8 and OS X Yosemite,
and basically it's just a rectangle around web content.
against the current page.
You can modify navigations or outright block them.
And it's up to you to add your own user interface.
Back, forward buttons, communicate progress, et cetera.
And new on iOS 9 and OS X El Capitan we've heard your
feedback and we've incorporated some of the pieces
of WKWebView that were missing.
First and foremost, you can securely loadFileURLs now.
RICKY MONDELLO: You can also loadData,
say literal HTML string that you wanted this way.
No need to spin up a server.
And if you like, you can set your own customUserAgent
We've also added a new API to manage the data that is stored
by websites like cookies and caches and other stuff.
And it's called WKWebsiteDataStore.
It's a read/write property
on your web view's WKWebViewConfiguration.
And with the data store you can remove data by its type
or you can do something like remove all data that was added
in the last hour, which is pretty cool.
And because the property,
the store on your configuration is writable you can replace it
with a configuration that's non-persistent
which is exactly how you'd go
about implementing private browsing.
So for web content that's in your app that you own,
you control, or you're customizing,
WKWebView is the right tool for the job.
And in iOS 9 and OS X El Capitan we've given you more flexibility
than ever before.
But if you've have been sitting here thinking: I don't need
that flexibility, I don't want
I don't need to modify navigations.
I don't want to wire up my own back and forward buttons,
then the rest of this talk is for you.
We're going to talk about how you can use either Safari
or Safari View Controller to get a better experience
for your users and to give you less code to write.
And your first option is
to simply delegate the responsibility
of showing web content to Safari itself.
And this is super easy to do.
You just call UIApplications, openURL method
and iOS will switch away from your app and over to Safari.
And new to iOS 9, the system affordance
that you saw yesterday for going back to the last app,
makes this a better option than ever.
It's more lightweight than iOS 8 was.
RICKY MONDELLO: And delegating the responsibility
of showing web content to Safari ensures
that users get a first class experience
with that web content.
That's what Safari is all about.
But if you'd like to maintain your app's current experience,
where users never even leave your app, then you're going
to be interested in Safari View Controller.
Let's take a look.
This is Safari View Controller with the page from apple.com
with the web contents slightly grayed out.
The first thing you'll probably notice is
that Safari View Controller looks a lot like Safari
with a few intentional differences.
Safari View Controller's job is to make it fast,
easy and enjoyable for users to tap on a link within your app,
view a web page and press done to go right back to your app.
Safari View Controller eliminates distractions.
The URL field that you see up there, it's read only.
You can't change it.
And there's just this one page.
No other tabs to distract the user.
And with Safari in the name,
Safari View Controller brings features
that your users already love from Safari,
but now they're in your app.
Let's start off, first
and foremost Safari View Controller shares cookies
with Safari and other website data.
So what this means is if one of your users is already logged
into a website in Safari, if they tap a link in your app
and Safari View Controller comes
up they might still be logged in.
But if they're not logged in already,
we've got that covered too,
because Safari View Controller allows you
to use Password Autofill to fill any of the passwords synced
across all of the user's devices with iCloud Keychain.
But before we go further it's really important to point
out this is completely safe for your users.
And the reason that this is safe is
because we're giving your users access to their credentials,
their user names and passwords, but we're not giving access
to the host app to this data.
In fact, Safari View Controller runs in a separate process
from your application.
Which categorically frees you from the responsibility
of thinking about this important sensitive user data.
That's on us.
All right, let's go back to features.
When a user wants to have something shipped to their home
or to their work they'll be able to use Contact Card Autofill
to fill that information just like they could in Safari.
And when it comes time to make a purchase they'll be able
to fill their credit cards as well.
And if one of your users comes
across an article that's interesting, compelling,
but difficult to read, she will be able
to use the Safari Reader button in order
to show a simplified cleaned up version of that content.
And new to iOS 9 in both Safari and, of course,
in Safari View Controller, Reader is customizable,
offering a bunch of themes and some fonts to choose from.
So it's never been easier to read articles
on the web exactly the way you want to and your users want to.
From the share button you'll find exactly what you expect.
You'll find the system wide options for sharing
to social networks and you'll also find the ability to add
to one's reading list, but that's not all
that you'll find here.
Because alongside these activities are activities
that your app provides to Safari View Controller.
So if your app is a social network,
you can have a dedicated button in the share sheet
to share the current web page to the social network.
And while we're on the topic of customization,
Safari View Controller will respect a custom tint color
that your app sets on it.
So in this case up on the slide the tint color has been changed
from Safari's default blue to orange.
This is a great way to let users know which app they're
in when using Safari View Controller.
This next feature is really awesome and it's new to iOS 9.
It's called Content Blocking -- go ahead [chuckles]!
RICKY MONDELLO: So the big idea behind Content Blocking,
is that it's possible to add something to the experience
of viewing a web page by taking something away.
In iOS 9, any app can write a description of web content
that Safari and Safari View Controller should block
as the user browses the Web.
So lets take a look at an example.
Here's a web page that has some pretty cool content,
but in my case I really don't like all
of the clickbait headlines that are in that side bar.
So if you install the right content blocker you won't
believe what happens next [chuckles].
Oh, well, you will.
The content disappears.
RICKY MONDELLO: But that's not all
that Content Blocking is capable of.
Content Blocking can do a lot more
than hiding elements on a page.
You can out right block loads from happening.
You can block all images or all scripts
from a third-party domain that you're not really fond of.
And all of the content blockers that a user turns
on in settings will apply in both Safari
and in Safari View Controller.
So what this means for you is
after you've switched your miniature web browser
implementation over to using Safari View Controller you won't
get any complaints that your users' ad blocker is
So that's a bunch of features.
Let's talk about safety.
I mentioned a moment ago that Safari View Controller runs
in a separate process from your app which frees you from a lot
of responsibilities of thinking about important user data.
But when it comes to browsing web content,
it's just as important to have an expressive interface
that communicates security to a user,
and Safari View Controller does the same exact job
that Safari does in this regard.
First and foremost secure pages.
Safari View Controller communicates the validity of SSL
to your users just like Safari does.
But if the user is having a bad day and they come
across a phishing page,
Safari View Controller will also warn them about that
and ask them to turn around,
exactly the same way that Safari would.
So to recap, Safari View Controller has all the great
features of Safari itself.
The features that your users already love.
Like the ability to fill their passwords, have shared cookies,
clean up articles with Safari Reader
and in iOS 9, Content Blocking.
There are also a few other minor things
like correctly communicating progress while progress is
loading with a nice progress bar.
And showing informative error pages
when something goes wrong during a load.
Your miniature web browsers may or may not be doing all
of these things, but with Safari View Controller it doesn't have
to, because adopting it will add years of Safari features
and polish to your apps and future years
of polish in the future.
I'm happy to say that adopting Safari View Controller is
Let's take a quick walk through the API.
In code, Safari View Controller is known
It's part of the Safari Services Framework.
And as you might have guessed it's a subclass
It has a delegate which I'll get to in a moment,
and initializer which takes a URL.
This is the URL of the web page that your user tapped on,
the web page that you want to show.
Let's look at that delegate real quick.
The first method in the delegate is how you can provide your own
custom activities to the share sheet
when the user taps on the share button.
And the second delegate method is called when the user taps
on the done button, when they're done browsing.
You're going to want to implement this in order
to dismiss the View Controller.
Taken all together it's a pretty simple API.
And to show you just how powerful this simple API can be
and how many lines of code it will remove from your apps,
I'm delighted to invite my colleague Yongjun
to the stage for a demo.
YONGJUN ZHANG: Thank you, Ricky.
My name is Yongjun.
I'm a Safari and WebKit engineer.
I don't know about you, but I really want
to have some pizza today.
So I'm writing an app to find pizza stores around me.
Here it is.
I call it pizza finder.
I got a list of pizza stores.
If I select the first store, I got the phone number, address,
I also get a link to the website of the store.
My task now is to make my app show the website
so I can know more about a store.
As Rick mentioned we got three options.
Option one, use openURL and let Safari open the website for us.
Option two, you establish a web view
and make our own browsing app.
And option three, use Safari View Controller.
I am going to try option one first.
So I go to my Xcode project.
And here in my store view controller I got a function
I just need to drag one line of code UIApplication, openURL.
This will let Safari open the URL.
Let's test it.
I run the app and select the first store, left click.
Now, Safari opens the website for me
and I can see this page has a Reader.
And if I try to order pizza, I got my user name
and password autofilled.
So I must have been to this site before
and maybe I ordered a pizza before.
Now I'm in Safari.
What I really want is my users to always stay in my app.
I don't want them to switch to Safari just
for visiting one or two websites.
Because they can get distracted
and might not come back to my app later.
So I really need a browser in my app.
I'm going to try option 2 now to make my own browser.
So first thing I want to do, I want to go back to my app.
So as we know, if we have some web content in the app
and if the web content happens to be my UI or part of my UI,
WKWebView is the best tool for that job.
In my case I wanted to use WKWebView
to load web pages certainly, but I also want
to have some UI around that.
For example, I want to have a URL bar
on the top to show the URL.
I also would like to have a toolbar in the bottom
to do back and forth navigation.
WKWebView is a very rich API, it provides a number
of delegates I can use to listen
to page load events or navigation events.
I can use this delegate to drive my UI.
So to save us some time for this demo,
I already have a single browser.
Let's take a look.
So in the Xcode project I switched to another tab.
I wrapped my simple browser into one view controller.
And in the middle I got WKWebView.
On the top I got the navigation bar.
I use the navigation bar's title to show the URL.
In the bottom I have a back and forth button to do back
and forward navigation.
Now this is a simple class.
It has about eighty lines of code.
It took me about one hour.
I believe we can do better.
But anyway, let's test this browser.
So I go back to my store view controller,
remove this line we just added and drag a couple lines here.
What I am doing now is I load my view controller
from the story board assigned a URL to it and presented it.
Now let's take a look.
I run my app.
Select the first store and tap the link.
This is my browser.
It runs in my app.
I don't have to switch to Safari to visit this site anymore.
The URL bar is actually grayed out.
So it won't be distracting.
But also notice when I drag the page I don't have the dynamics
of Safari's UI.
And this page doesn't have a Reader.
It will be harder for me to read now.
And if I try to order pizza, I don't have my user name
and password autofilled.
So it will be harder for me to order pizza now especially
when I'm hungry, and impatient,
and I don't have my password [laughter].
YONGJUN ZHANG: So, what I really need is some simple
and easy way to show a website from my app.
I don't want to spend my time
to implement missing features like progress bar.
Even though I want to spend time there are some features I will
never get to.
For example, Password Autofill.
I would never get users' passwords for this website.
Luckily in iOS 9 we have a Safari View Controller.
Let's take a look.
So to take Safari View Controller into use,
first thing I need to do is import Safari Services Framework
and then I need to make my view controller conform
In the code, let's go back to showStoreWebsite.
I don't need my browser anymore, so I remove that.
And just drag a couple of lines here.
What I'm doing now is I instantiate my
SafariViewControler object, gives delegate and present it.
Before we test it I also need
to implement safariViewControllerDidFinish,
when the user taps the done button,
and we can dismiss the view controller.
Since we are here we don't need our browser anymore,
so we can delete the whole thing, move to Trash, yes.
Eighty lines of code down and one hour saved.
Let's run again.
Select the first store.
Look! I have Safari in my app.
So I got Reader back.
The same dynamics as Safari, and if I try
to order pizza now I have my user name and password back.
As you see, with a couple lines of code I have Safari in my app.
You can do that for your app, too.
And the user would be really happy about it.
YONGJUN ZHANG: Back to you, Ricky.
RICKY MONDELLO: Thank you, Yongjun.
That is awesome.
So Yongjun just showed you that although it's easy
to write your in-app web browser in WKWebView, it's kinda hard
to get all of the details right.
He also showed you by changing about seven lines
of code he was able to replace the whole thing
with Safari View Controller.
You got to see how Safari View Controller has features
like Password Autofill and Reader and little touches
like the dynamics when you scroll down on a web page.
When we started a few moments ago I divided the world
of web content into two buckets.
The kind of stuff that is custom within your app
that you're going to use WKWebView for,
or actual websites when a user taps on a link in your app
which you'll use Safari or Safari View Controller for.
But for a number of you
in the audience there's actually a third use case for web content
that I would like to talk about real quick.
That's doing Web-based authentication using
So you've all probably seen this before.
You're in an app and the app wants
to use some third-party website's accounts.
The app pulls up a web view.
You type in your user name and password.
Log in. Then you accept or deny the app's request
for the resource from the third-party service.
You've all probably done this before.
But one flow that does this is OAuth.
I would like to walk through at a high level exactly how
So in this flow there are three different actors.
The first actor is an app.
Let's say that it's your app.
The second actor is a user.
Let's say it's one of your users.
And of course, there is the third-party web service
that your app would like to authenticate against.
So what will happen is in this flow while the user is using the
app, presumably they'll tap
on a button somewhere that says log in.
The app is going to package the user
up with a token representing what it wants
to request from the website.
And then, the app is going to present, somehow,
a web page to log in against.
And the user will enter their credentials,
log in and accept or deny the request.
And then be sent back over to the app.
At that point the website is going to remember that token
and know whether it was approved or denied for use.
And when the app wants to connect
to that third-party service
in the future it will do it using that token.
The major goal of a scheme like this is
to protect a user's credentials
so that an app doesn't have to remember them.
Instead the app gets a token.
That token can be used at a later date to request resources
or the user could revoke the token without having
to change their password.
This is great for users.
If you are implementing this today,
you are probably using UIWebView or WKWebView to do it.
But I'm happy to tell you
that Safari View Controller is great for this purpose.
It's awesome for web-based authentication.
One of the reasons it is awesome
for web-based authentication is the security story.
It's just as secure as Safari itself.
Because it runs out of process, and Apple will never get
to see a user's user name
and password while they're logging in.
And when it comes to protecting a user's data,
one of the best ways to do that is never to have access
to it in the first place.
That's our approach whenever possible at Apple.
But it is also an awesome user story.
Because since Safari View Controller has access
to a user's credentials, synced across all of their devices
with iCloud Keychain, logging in is going to be a breeze.
They may not need to use Autofill.
They might already be logged
into that third-party web service.
Simply put, users will be much more likely to authenticate
against that third-party web service,
if you are using Safari View Controller compared to something
that you rolled yourself.
And I'm happy to say this is also super easy to adopt.
It takes two steps.
The first is where you would've used your own in-app browser,
just present an instance of SFSafariViewController.
And once the user is finished logging in
and the third-party web service redirects back to your app
with the custom URL scheme that you fed it, you can accept
that in your AppDelegate's handleOpenURL method.
From there you can inspect the response
and dismiss the instance of SFSafariViewController
because you know that the authentication is done.
And you've replaced your in-app browser with one that has all
of the user's user names
and passwords available for Autofill.
Users are going to be delighted by this and you are going
to have more users log into that third-party web service.
Okay, let's cover everything we talked about today.
Web content is everywhere and it comes
in all sorts of shapes and sizes.
But if you are using it within your app in a custom way
where you own the experience or you're customizing it,
WKWebView is the right tool for the job.
You might still be using the older UIWebView,
but WKWebView is modern
that Safari itself uses, it's much faster.
And now in iOS 9 and OS X El Capitan,
it has much more flexibility for you.
If you'd like to learn more about adopting WKWebView,
you can see last year's session,
Introducing the Modern WebKit API.
But if your task with web content is different,
if your task is to show a website when a user taps
on a link, your use case and needs are completely different.
In the past, you may have built your own in-app web browser
with UIWebView or WKWebView, but that's always had downsides,
it didn't have any of the features
or state that Safari has.
And more likely than not through no fault
of your own your app's implementation was different
than that of other apps that the user has installed,
which leads to a confusing experience sometimes.
Your first option forgetting
out of the scenario is delegating the responsibility
of showing web content to Safari itself.
And the system wide ability to go back
to the last app makes this much better
than it has ever been before.
But if you would like to maintain your current user
experience where users never leave your app,
Safari View Controller will add years of features and polish
and features and polish in the future.
For you, it'll mean having more time to work on the parts
of your app that are special about your app,
the parts that you want to work on.
For your users, it will mean having new features
like Safari Autofill, Safari Reader and Content Blocking.
And while I still have your attention I have a quick favor
to ask of you.
Please keep filing bugs and feature requests,
when there is a gap between what is and what you think should be
on the platforms that you are developing on.
One of the reasons that Safari View Controller exists is
because so many of you told us that you wanted it.
And now that it does exist as you're trying it
out over the next few months,
please let us know how we can make it more useful to you.
We really do appreciate your feedback.
Okay. You can get more information
about anything we covered today at the usual places.
Or you can hit up John Davis, the Safari
and WebKit Evangelist.
And we have some related sessions
that you might be interested in.
To call out two in particular, in Seamless Linking
to Your App you'll learn about Apple's solution to the problem
of inner app linking
which involves taking your website's URLs
and making them universal, allowing them to open your app
on your users' iOS devices.
It's really cool.
In Safari Extensibility, you'll learn to write one
of those content blockers that I mentioned earlier,
that will apply to all pages that are loaded in either Safari
or in Safari View Controller.
If you want help with anything I covered today, the Safari
and WebKit Labs are the right place to go.
And the first one is happening
in about a half an hour in Media Lab A.
Alright, thank you so much everybody.
I hope you have a fantastic WWDC.
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.