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.

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.

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.