Transcript
[ Applause ]
>> Good morning everyone.
Welcome to session 206,
Introducing Password Autofill
for Apps.
My name is Ricky Mondello.
And I am thrilled to be able to
tell you about Password
Autofill, a new feature in iOS
11 that puts passwords that your
users have already saved in
Safari and in iCloud Keychain
directly on the keyboard within
your apps to make logging in
super simple.
We made Password Autofill
because logging into apps is
hard.
It's a source of friction.
Personally, when I've downloaded
a new app from the Store and
I've seen the login screen,
sometimes I've just switched
back to Safari where I knew I
was already logged into the
app's website.
But beyond an inconvenience for
me, for so many people any
experience dealing with
passwords is a source of real
frustration or even panic.
So the truth is, although having
to log into your apps is really
important, it is a source of
friction that can lead to users
abandoning your app.
And none of us want that to
happen.
You make awesome apps.
We want users to use them.
Fortunately, in iOS 11 Password
Autofill can help.
Let me explain.
iOS and MacOS have a password
manager that's built in,
integrated into Safari.
And you've probably seen it
before.
When you're logging into a
website, it offers to save your
passwords.
And the next time that you come
back to that website, it fills
them automatically for you to
make logging in really easy.
And I want you to know that
Safari takes the security of
users' passwords extremely
seriously.
If the user has saved a password
for your website, Safari will
only ever fill that password on
your website.
Passwords for your website won't
be offered on any other
websites.
And of course, if the user wants
to look up one of their
passwords on a device, viewing
the passwords requires them to
authenticate, either with Touch
ID or with their passcode.
The point is, iOS keeps these
passwords secure on device.
And of course, iOS synchs all of
these passwords across a user's
devices using iCloud Keychain.
And this makes it super easy to
log in across multiple devices.
And this, too, is secure.
We actually have a really
approachable white paper on
Apple.com that describes the
security model of iCloud
Keychain.
And it goes into a great amount
of detail about how and why
Apple cannot see a user's
synched passwords, but it still
makes them available on all the
devices.
Safari AutoFill and iCloud
Keychain are built directly into
iOS and MacOS.
Safari AutoFill is enabled by
default for all users.
And every user is prompted to
turn on iCloud Keychain when
they set up a new device.
These features are extremely
popular.
Lots of your users have
passwords saved in iCloud
Keychain and Safari AutoFill.
And what iOS 11 does is it takes
these passwords that already
saved in the Keychain and makes
them available on the keyboard
within your apps.
And I think the best way to
understand this is to see it.
So let's start off with a demo.
So, what I have right here is
Shiny, which is a demo app.
And it's personally my favorite
demo app for logging in and
seeing a picture of something
that's pleasant every single
day.
So I'm going to open up this
app.
And it has a very standard login
screen, like many of your apps
do, with a username and a
password field.
So like any user would, I'm
going to tap into the username
field.
And one of the first things
you'll probably notice is that
directly above the keyboard
there's the QuickType bar.
And the QuickType bar is
offering my password from the
website for Shiny.
And with one tap, that
information is filled.
And with another tap, I'm logged
in.
That's an adorable puppy, 13 out
of 10.
So let's do that one more time.
It went by pretty quickly.
This time I'll just happen to
touch into the password field.
And I'm offered the same thing.
I can tap and tap.
And I'm logged in.
Another good dog.
So one thing I want to point out
while I'm showing you this is I
mentioned a moment ago that iOS
takes password security very
seriously.
And so the big thing to notice
here is iOS isn't guessing that
shiny.example.com is the website
for the Shiny app.
There is a strong two-way secure
association between that app and
that website that allows iOS to
put the exact right credential
that the user's looking for
right on the QuickType bar.
All right.
Let's go back to some slides.
You just saw that iOS 11 put the
password that I needed to log
into Shiny directly on the
QuickType bar above the
keyboard, which made logging in
as simple as two taps.
Now, I have no reason to abandon
the app and go back to Safari
where I was already logged in.
It's just as easy to log into
the app.
Quick show of hands.
How many of you have a screen in
your app that looks like this
one with a username and a
password field?
All right.
That's a lot of you.
And you're all in the right
place.
So, one more show of hands.
How many of those apps are you
logging into your own backend
that you manage yourself instead
of a third party service?
All right.
That's a lot of you.
For everyone who kept their hand
up, who raised it a second time,
I'm going to be talking to you
throughout most of this
presentation.
But if you're logging into a
third party service like a
social network, I'll have a
little something for you toward
the end.
We want Password AutoFill to
work for as many of your apps as
possible.
So we built heuristics into iOS
that make some parts of Password
AutoFill work automatically in
many apps without you
necessarily having to change
anything.
However, for your users to get
the best experience where the
exact right credential shows up
on the QuickType bar, we're
going to need a little bit of
your help.
So what we're going to focus on
for the rest of this session is
guaranteeing that your apps get
the experience that you just saw
in the Shiny app.
And we'll do that by walking
through these topics.
The first topic is about making
the QuickType bar appear in your
username and password fields in
your app.
The second is about making sure
that the passwords are filled
properly into the app.
And that your app works properly
after a user taps on one of the
suggestions.
Then, we'll talk about making
sure that the exact right
credential that your user is
looking for, the credential from
your website, shows up on the
left-hand side of the QuickType
bar.
And then at the end, we'll
circle back around and talk
about authenticating against a
third party service, a service
that's not the same as your app.
So let's get started by talking
about making the QuickType bar
appear.
The first thing to know about
the QuickType bar appearing is
that it will only appear if you
have at least one saved password
on an iOS device.
There's no need for us to offer
Password AutoFill if there are
no passwords to fill.
The next thing to know is that
UITextView and UITextField are
automatically eligible for
consideration or Password
AutoFill.
So, if you're using these
standard controls out of UIKit,
you're already in a really good
place.
However, if you're rolling your
own text fields, no need to
worry.
If your text field conforms to
UITextInput, it's also eligible
for Password Autofill.
And I mentioned this earlier,
but iOS is going to use
heuristics to determine where to
show the QuickType bar in your
username and your password
fields.
And iOS's heuristics are pretty
good.
But what we're here to do is to
guarantee that your app has
Password AutoFill.
And we can guarantee that by
having you tell iOS which of
your fields is the username
field and which is the password
field.
And the way that we'll do this
is through UITextContentType.
By setting a content type on the
text fields.
UITextContentType was introduced
as an optional property on the
UITextInputTraits protocol in
iOS 10.
iOS uses it to have a better
understanding of what
information is in your text
fields.
So you could imagine that iOS
would offer a different and
better keyboard or auto
corrections if it knew that your
users was typing an email
address versus, say, their last
name.
Here are the text content types
that are present in iOS 10, just
to give you a refresher.
And as you've probably guessed,
in iOS 11 there are two new text
content types, username and
password, that you can tag your
fields with.
So to guarantee that Password
AutoFill is working in your
apps, we're going to deploy
UITextContentType.
That's going to be our guarantee
that Password AutoFill is
available in your app.
You can set text content types
from within code.
Or, with an interface filter.
And we'll show you how to do
that in a little bit.
The username text content type
is particularly useful if your
app has a two-screen login
experience where your username
field is on a different view or
screen than your password.
In this case, if you tag your
username field with the username
text content type, we'll be able
to offer the QuickType bar on
both of the screens.
If you're already using the
email address text content type,
there's no need to worry.
You can combine the username
text content type and the email
keyboard to give your users the
best of both worlds, where they
get an email address keyboard
and QuickType Autofill.
The password text content type
is particularly useful if you
have a feature in your app that
reveals the password that the
user is typing in plain text to
help them out.
When your field is in plain text
iOS won't be able to tell that
it's a password field unless you
tag the field as a password.
So if you do that, the QuickType
bar will still work in that
field, even when it's not a
secure entry.
And at this point, once you've
done this, you might see a
Password AutoFill QuickType bar
in your app with its key icon on
the right, but without any
specific credentials showing up
on the left.
This is actually expected.
And it's a really good first
step.
In a little bit we'll talk about
making your website's passwords
show up on the left.
But what seeing this bar means
is that iOS is ready to offer
Password AutoFill.
And if users tap on that key on
the right-hand side, they'll be
able to authenticate using Touch
ID and see a list of their
passwords that they can search
through or scroll through in
order to fill one of those
passwords within your app.
And once they've found the right
password, and they tap it, iOS
will fill that information into
your fields.
Which brings us to our next
topic, which is ensuring the
information that's filled into
your text fields is understood
by your app and that users able
to log in successfully
afterward.
iOS is going to do its best to
put information into your
username and password fields in
a very similar way to how users
would type that information
themselves.
But it's still a good idea to
test that your app behaves
properly after information has
been autofilled.
What we want to see is that
users are able to just tap your
sign-in button and log directly
in.
So let's talk about what you
need to know about how Password
AutoFill fills into your app.
The first thing is something
you've already seen, which is
that iOS will fill both the
username and the password fields
in a single gesture.
iOS will change your app's first
responder in order to do this.
iOS is going to do this even if
your app prevents changing the
first responder at that time.
So if you're doing something
like this, it's worth knowing.
A moment ago I showed you the
flow where a user taps on the
key icon and Touch ID comes up.
And when Touch ID appears, your
app will become inactive.
And that's worth knowing because
it leads directly into our first
best practice.
Which is that when Touch ID
appears, there's no need for you
to tear down your login UI or
hide it when your app becomes
inactive.
Because if you do this, all a
user is going to see is tapping
on the key, finding the right
password and tapping it.
And then iOS isn't going to be
able to fill anything because
the text fields will have
disappeared.
So, it might be a good idea to
hide sensitive information in
your app when your app becomes
inactive.
But if a user actually hasn't
finished logging in yet, that's
probably not necessary.
You might have buttons in your
app, like a login button or a
sign-in button, that only lights
up and enables itself once
there's actually information
filled into the username and
password field.
And the best practice here is to
us did change notifications or
delegate methods to revalidate
those buttons whenever the text
changes.
If you're using UITextField,
there's a notification that you
can use.
If you're using UITextView,
there's a notification and a
delegate method.
And if you're rolling your own
custom text input, if you can
form the UITextInputDelegate,
there's a delegate method that
you can listen to again to
revalidate your buttons.
And when you're doing that
validation, you should read
information directly from your
text field's text property.
UIKit makes it incredibly cheap
to read information out of a
text field.
And it's always accurate.
If you do this, you'll eliminate
categorically an entire class of
bugs that you can have with
cash-in validation based on what
information is entered into your
text fields.
And that's it.
That's just a few best practices
for ensuring that after a user
has used AutoFill, that your app
is able to login successfully.
And users can go about their
business.
Which brings us to our third
topic, which is making sure that
the QuickType bar is showing the
exact right credentials for your
website.
So at this point in your testing
you might still have what we saw
earlier, which is a bar with a
key on it, but without any
specific credentials on the
left.
But as you know, in order to
give users the best experience,
the one that is most going to
reduce the odds that they
abandon your app, we'll want the
exact correct credentials
showing up on the QuickType bar.
And I touched on this briefly
during the demo earlier, but
Password AutoFill will only put
credentials on the QuickType bar
when it is safe to do so.
When it's secure.
iOS is not guessing what
websites are affiliated with
your app to find out which
passwords are correct for your
app.
iOS knows.
So if you've adopted universal
links, that feature that can
open up links when a user taps
on them inside of your app,
rather than opening them up in
Safari, if you've done that, you
might actually already see that
iOS understands that your app
and your website are associated.
And it'll put the right
credentials on the QuickType
bar.
But if you haven't adopted
universal links, or it doesn't
really make sense for you to do
so, there's no need to worry.
We have a dedicated technology
to linking your app and your
website together strongly.
And I'm going to walk you
through it.
In this diagram it's your app on
the left.
And on the right is your web
server or your backend.
So the ideas is that your app,
through its signed entitlements,
says what website or websites it
is affiliated with.
And whenever your app is
installed or iOS installs an
update, iOS is going to check
with that domain at a particular
file path to see, to look for
some information.
If you don't know the well-known
directory, it's just a standard
place to put files for
information discovery, like the
file I'm about to tell you
about:
Apple-app-site-association.
iOS will only ever attempt to
fetch this file over HTTPS, over
a secure connection.
In response to that request,
your website can return a JSON
response.
And if that JSON response is
formatted properly, what it can
say is: Here is the list of apps
that I'm associated with.
And if the app points to the
website, and the website points
right back to the app, boom!
We have a secure two-way link.
So to put what I've told you
about so far into practice,
particularly with establishing
this secure connection between
your app and your website, I am
delighted to invite my colleague
Maureen Daum to the stage to
give you a demo.
Maureen.
[ Applause ]
>> Thanks Ricky.
So, here I have the Shiny app
before we've done any work to
make Password AutoFill work with
it.
So when I tap in the username
field, iOS automatically
detected that this is in fact
the username field.
And it gives us the Password
AutoFill QuickType bar -- thank
you -- for free.
So now users, if they don't
remember their credentials, can
tap on the Key icon,
authenticate with Touch ID and
find the right credential.
So here it is.
So this is a great experience
for my users that might not
remember their credentials.
But what I really want to make
it even easier for them to log
in is to have those credentials
show up right on the QuickType
bar.
So I'm going to do two things in
this demo.
The first is to guarantee that
we get this password QuickType
bar instead of just relying on
the heuristics.
And the second thing is to get
the right credentials on the
QuickType bar.
So let's do that first step,
guaranteeing that we get the
credentials.
To do this, I'm going to tag my
username and password fields
with the right content type.
So here's my username field.
And I've already set its content
type to email address, because
some of my usernames might be
email addresses.
But if I switch this to
username, down here at the
bottom, I can set the keyboard
type to email address.
So go down here the keyboard
type and set that one to email.
So now if the user has to type
in their username, they'll still
get the right keyboard.
And now I'll go to password and
set that content type to
password, all the way at the
bottom.
So, I'm going to rerun this just
to verify that we still get the
QuickType bar showing up.
We don't expect anything to have
changed because iOS was already
detecting it.
But it's good to make sure.
So now, once the login screen
comes up, we can tap in and we
still get the QuickType bar,
which is great.
So now, to get the credentials
showing up, we need to tell iOS
that our app and our website are
associated.
And to do this, we'll adopt the
web credentials associated
domain service.
So, to do this, the first step,
is to make our app tell iOS what
websites it's associated with.
So we'll go here to the
Capabilities tab in our app and
turn on Associated Domains.
So now I have the ability to add
domains that my app is
associated with.
So click the Plus button and
Xcode as a placeholder domain
for me.
So it has the web credentials
:prefix, because we're using the
web credential service.
And then you will replace
example.com with the domain your
app is associated with.
So my app is associated with
Shiny.example.com.
And when you add a domain, Xcode
will do two things.
The first is it adds an
entitlement to your entitlements
file so that when your app is
installed iOS will look at this
list of domains and go to each
one of them to find the
Apple-App-Site-Association file.
The second thing it does is it
makes sure that your app has
associated domains enabled.
So if your app ID does not have
this enabled, you won't see a
checkmark next to this second
thing.
It will have an error.
So, if you see an error there,
it's really easy to fix.
You just need to go to the
Developer Portal, select your
app ID, and turn on Associated
Domains.
And then it will be fixed.
So that is all we had to do to
tell iOS that our app is
associated with our website.
But now we need to make our
website agree and point back to
our app so that iOS can
establish the two-way link.
So to do this, I'll create an
Apple App Site association file.
So, here's some JSON that
specifies we're using the web
credential service, which
matches what we saw in Xcode.
Then within this dictionary is a
list of all the app IDs of the
apps our website is associated
with.
And my website only knows about
the Shiny app.
So its app ID consists of the
Team Identifier, which you can
find on the Developer Portal,
followed by a period, and then
your bundle identifier.
So let's save that.
And now I need to get it onto my
server.
And this step might look
different for you depending on
how your website is set up.
But I'm just going to use SCP to
copy it up there, to the
.well-known subdirectory.
Great. So it's up there.
And then just to double check,
I'm going to go into Safari and
visit the site that iOS is going
to look at.
So it's HTTPS
Shiny.example.com/.well-known/
apple-app-site-association.
And when I go there, it's great.
I see the JSON recreated.
And I don't see any smart
quotes, which could cause the
JSON to be malformed and
therefore it wouldn't work.
So, it looks like we're all set.
We've set up our app to point to
our website.
Our website to point to our app.
So let's rerun this and see that
we get the credentials we want
showing up on the QuickType bar.
And when you're testing this on
your apps, make sure to test it
on a device, because Associated
Domains is a device-only
feature.
So here we are back in our app.
I tap in the username field.
Great! We have the credentials
right there on the QuickType
bar.
So my users can tap, fill them
in, one more tap, and then they
get to see a really adorable
puppy.
So that's how easy it is to
guarantee that Password AutoFill
will work in your app.
And that the credentials your
users need will show up on the
QuickType bar to get them logged
in really quickly.
So now I'll hand it back over to
Ricky to tell you more.
[ Applause ]
>> Thank you, Maureen.
That was really cool.
Maureen just showed you just how
easy it is to set text content
types from within Xcode.
She also showed you how to add
the web credentials associated
domain capability in your app's
Capabilities tab.
And she told you that that
capability gets signed into your
app's binary.
And if you need to enable the
associated domains feature on
the Developer Portal, it's
really easy to find.
I'll show you how to do it.
First, you navigate to the
Developer Portal.
And from there you can click on
Certificates, Identifiers and
Profiles, either in the side bar
or in the main content area.
And from there you can select
App IDs and look at a list of
app IDs that are associated with
your developer account.
And from there, if you select
the app ID that you'd like to
modify, you'll see a list of
services that can be enabled for
your app.
And from there you can click the
Edit button and check the
Associated Domains checkbox.
And that's it.
You also saw just how easy it is
to construct an
Apple-App-Site-Association that
points back to your app from
your website.
It's just a few lines of JSON.
Maureen then uploaded that JSON
file to be served from the
.well-known standard directory
at the root of her web server.
You could also serve this file
from the root of the web server,
but the well-known directory is
preferred.
And if this linkage doesn't work
the first time that you try it,
if you build and run your app
and you're not seeing
credentials showing up on the
QuickType bar, we have a few
steps for you to help the bug.
The SWCD daemon will log
information about making
requests for setting up
associations between your app
and website on your device every
time that you build and run your
app.
So if something's not working,
plug your device in, open up
Console, and select the device
in the side bar and look for
logging from SWCD.
On the slide right now you can
see what happens when I
accidentally put
wrong.example.com as my
associated domain inside of
Xcode.
It wasn't able to find an
Apple-App-Site-Association file.
But as soon as I corrected that
to Shiny.example.com iOS was
able to find the
Apple-App-Site-Association file,
verify the two-way link, and
from there iOS can offer the
exact right credentials that
your users are looking for
directly on the QuickType bar.
And at this point you pretty
much have all of the information
that you need to know to make
Password AutoFill work really
well in your app.
I'm hoping that this is one of
the easiest to adopt features
that you've ever wanted to
adopt.
But before we wrap things up, I
just want to quickly touch on a
few related topics to
authentication and passwords,
because since you're here,
you're probably interested in
them.
And the first is about viewing,
saving, and adding new passwords
on iOS.
So besides Password AutoFill, we
made another change related to
iCloud Keychain this year.
And that was to move the list of
passwords that you could find in
Settings up to a more prominent
location at the top level called
Accounts and Passwords.
Inside of that section, users
will be able to authenticate
with Touch ID, of course, to
view a list of their safe
passwords, and add new
passwords.
Now, after all of you have
adopted Password AutoFill in
your apps, users aren't going to
have a ton of reasons to come in
here to copy and paste passwords
anymore.
But it can still be useful to
look up a password if you need
to enter it on a friend's device
where you don't have your iCloud
Keychain.
Okay, this whole time we've been
talking about a specific type of
authentication, where your app
and your website, they're the
same entity.
You're logging into a service
that you or your company owns.
But I know that there's a
different type of authentication
that a bunch of you need, which
is to log into a third party
service like a popular social
network.
iOS's solution for
authenticating against a social
network using a technique like
o-Off is Safari View Controller.
And the reason for that is that
Safari View controller has
Safari's AutoFill feature, which
makes it really easy to get
logged in.
And also, Safari View Controller
is sandboxed away from the third
party app, which gives the
service that's being
authenticated to a sort of
guarantee about the security of
the passwords.
In iOS 11 Safari View Controller
has been revamped.
It has a new look that you can
customize to make it feel more
like part of your application.
So here you're seeing a demo app
presenting a Safari View
Controller tinted blue and
white.
It doesn't look very much like
Safari.
It looks like the app itself.
And what this app has also done
is change the top left corner
button of the Safari View
Controller to say Cancel instead
of Done.
Because when Safari View
Controller is being used for
authentication, dismissing the
Safari View Controller is
cancelling the action of logging
in.
It's not actually successfully
finishing anything.
So Done doesn't make sense.
To learn about even more
customizations to Safari View
Controller, and how to implement
what I just showed you, you
should definitely check out the
session tomorrow at 10 a.m.
What's New in Safari View
Controller.
And if you want to learn more
information about implementing
an o-OFF flow yourself using
Safari View Controller, you can
go back to the 2015 session
Introducing Safari View
Controller.
You might not even be
implementing a Safari View
Controller yourself to do o-Off,
it might actually come for free
as part of an SDK you're using
for authentication.
So that's worth knowing.
All right.
Let's talk about everything that
we've covered so far.
Friction when logging in can
lead users to abandoning your
app.
And we don't want that.
Your apps are awesome.
We want users to use them.
But fortunately in iOS 11,
Password AutoFill is there to
help.
And Password AutoFill uses
heuristics to work automatically
in many of your apps without you
having to make any changes.
But to give your users the best
experience, and to guarantee
that it works now and in the
future, you can take a few
simple steps.
The first is to install one of
the betas on your phone and run
your app and see what your
starting place is.
From there, you can adopt the
username and password text
content types.
That will guarantee that even if
iOS or your view hierarchy
changes a few years from now
Password AutoFill will still be
offered.
So if you take three minutes to
do this now, you might save
yourself a bug a few years from
now.
And then finally, by adopting
the webcredentials Associated
Domain service you can set up a
tight two-way link between your
app and your website.
And that will enable iOS to
offer the exact right
credentials that your users are
looking for, that they've
already saved in Safari and
iCloud Keychain directly on the
keyboard in your apps.
And if you run into any issues
adopting Password AutoFill this
summer, and you can't fix them
by taking one of the steps that
I just outlined, please send us
feedback.
Please file bugs.
We need your help to make sure
that users are getting the best
experience in your app and in
the apps of everyone in this
room.
Your feedback really helps us
prioritize our work.
For more information about
Password AutoFill, you can check
out this web page on the
Developer website.
And we have some awesome related
sessions this year.
I already talked about the
Safari View Controller sessions.
But on Friday morning there is a
session that's about making the
keyboard entry experience in
your app magical.
I encourage you to check it out.
All right.
Thank you so much everybody.
I hope you have an amazing WWDC.
[ Applause ]