iOS Password AutoFill — how and why?

iOS Password Autofill magic tricks

Password AutoFill overview

Password autofill feature introduced with iOS 11 is supposed to ease the process of account creation and login for iOS apps. It received a major update with iOS 12 that brought new tag fields, security code autofill, strong password recommendations, and many other significant changes. It even provides credentials from third-party password managers when enabled.

However, this feature, as revolutionary as it may seem, brings users not only a great credential management experience, but a bit of disappointment as well. Often users use a suggested strong password (not even trying to memorise it), then change or reset it in the app, and cannot log in the next time, as the password wasn’t updated in the keychain. Who’s there to blame — password autofill workflow or a bunch of app developers? Well, both. But mostly the autofill heuristics. Here we’ll take a look at how to implement this feature in your app and trick Password AutoFill into doing what you expect.

Enabling Password AutoFill

To provide the best user experience and enable the Password AutoFill support, the following steps should be performed, according to Apple documentation:

1. Set up the app’s associated domains.
2. Set the correct content type on relevant text fields. If the field type is not specified, the system uses heuristics to identify it (unfortunately, not always in a best way).

Although these steps cover the general approach, they may not be helpful enough for some specific cases. That is why there are some additional steps to cover:

1. Ensure that all the needed fields are present on the screen. As the Autofill feature has its own algorithm to determine the type of the journey user is approaching (e.g. registration), and it is impossible to interfere, the behaviour may be unpredictable, unless all the expected fields are present.
2. Ensure that the fields are in the correct order, as it also impacts the behaviour of an Autofill feature. Sometimes the “correct” order is not the one that you’d expect from the particular journey. More on this later.

App’s associated domains

To set up the Associated Domains in your app, open the projects Capabilities tab and enable Associated Domains. This step adds the associated domains entitlement to your app as well as the associated domains feature to your app ID.

Placeholder domain with the webcredentials:prefix should be added. To match all sub-domains of an associated domain, specify a wildcard with the prefix * before the beginning of a specific domain. Each domain should be in the the following format:

<service>:<fully qualified domain>[:port number]

Configuring an associated domain

Then create a file named apple-app-site-association. Update the file to contain a dictionary listing the app identifiers associated with your domain for the webcredentials service.

Use the following format for the app identifiers:
<Team Identifier>.<Bundle Identifier>

The apple-app-site-association file needs to be accessible via HTTPS with a valid certificate, without any redirects, at https://{domain}/apple-app-site-association.

To validate your apple-app-site-association file you can use Apple App Search API Validation Tool or any other accessible tool you prefer.

After performing all the initial setups, you can dive straight into implementing Password Autofill feature and making it work.

Password AutoFill workflow

Password AutoFill recommends credentials only for your app’s associated domain, and the user must authenticate using Face ID or Touch ID before accessing these credentials.

The QuickType bar only appears if the user has at least one password saved for the particular app and the Keychain AutoFill setting is enabled. If the feature detects the registration flow, it also may suggest to users their emails used to register before.

This is the complete iOS Password AutoFill workflow:

1. The user selects a supported input field.
2. Autofill feature infers that there is a specific scenario that requires credential autofill.
3. Autofill checks the eligibility of the app: an association between the app and a specific domain on the web.
4. Autofill finds the required fields so that it knows which data to suggest/update/save.
5. Then it detects that the specific action has occurred. This happens when the credential input views are removed from the hierarchy.
6. Prompts the user to save or update the credentials. Or saves/updates them automatically, in case the suggested strong password was selected.

Password AutoFill scenarios

By default, Password AutoFill saves the user’s credentials and updates them if needed. For different scenarios, there may be different suggestions, so the feature should be able to identify the current scenario from the field order and properties.

To enable password autofill on a UITextField the textContentTypeproperty should be set.

Login

// username
usernameTextField.textContentType = .username
usernameTextField.keyboardType = .emailAddress
//password
passwordTextField.textContentType = .password

Signup

// username
usernameTextField.textContentType = .username
usernameTextField.keyboardType = .emailAddress
//password
passwordTextField.textContentType = .newPassword

Change Password

The above scenarios are pretty clear and straightforward — it is difficult to imagine the other appearance of those screens. However, the password change scenario is tricky.

In order to make Password Autofill work, there should be only specific fields on the screen: username, new password, new password confirmation.
The username field can be pre-filled and read-only, but it can not be hidden or covered with some other view, as it should be visible and present on the screen.

//username
usernameTextField.textContentType = .username
usernameTextField.keyboardType = .emailAddress
usernameTextField.text = UserDefaults.standard.username // pre-fill
usernameTextField.isEnabled = false // read-only
//new password
newPasswordTextField.textContentType = .newPassword
// confirm new password
confirmNewPasswordTextField.textContentType = .newPassword

But what if the change password flow is different or requires different data from the user? This leads developers to some struggling. Often the change password flow requests an old password from the user, which is why there is a need to integrate this field into the screen.

This may seem surprising, but the Password Autofill feature does not recognise the basic and commonly used password change screens as the correct ones: username, old password, new password or even username, old password, new password, confirm new password.

So what are the correct fields then? old password, username, new password, confirm new password. 🤯

Password change screen

Fortunately, the username field still can be pre-filled and read-only. There is one more workaround that can help with the user experience: although the username field should be present and “visible” on the screen, it can be minimised by size and thus invisible for the end user. It still should be located between the old and the new password fields!

//password
passwordTextField.textContentType = .newPassword
//username
usernameTextField.textContentType = .username
usernameTextField.keyboardType = .emailAddress
usernameTextField.text = UserDefaults.standard.username // pre-fill
usernameTextField.isEnabled = false // read-only
//new password
newPasswordTextField.textContentType = .newPassword
// confirm new password
confirmNewPasswordTextField.textContentType = .newPassword

Security code (OTP)

If the system can parse a security code from an SMS message, the QuickType bar shows the code for up to three minutes after it has been received. If a security code arrives while the text input view is selected, the system pushes the incoming code to the QuickType bar.

In order to enable the one-time passwords and security codes autofill, the correct content type should be set as well.

// security code
otpTextField.textContentType = .oneTimeCode

Save, update and suggest passwords

iOS will automatically show an alert to save the password if all the needed steps are completed. This happens when the system detects that the corresponding views were removed from the view hierarchy.

The following list covers all the basic steps to cover:

• Fields are tagged with the correct content type as described above.
• All the fields are filled with the correct data that needs to be saved.
• Views are removed from the view hierarchy.
• Fields are cleared only after removing from the hierarchy!

Save password alert

Note: Developers have no access to the credentials saved in the keychain via this feature.

If there already are some credentials saved with the specific username and the new password is entered, iOS will automatically show an alert to update the password when the fields are removed from the view hierarchy.

Update password alert

If the password is considered easy to guess, the system detects it and shows an alert suggesting changing the password on the associated website.

Change password alert

Strong Passwords

If UITextField is tagged with .newPassword content type Autofill feature suggests a strong, unique password to use.

Strong password suggestion alert

Note: When the user uses the suggested strong password, system saves and updates the saved credentials automatically without prompting.

The password generated by default contains uppercase, digits, hyphens, lowercase characters, and is 20 characters long. If your application has a different password policy, you can customise password generation rules.

You can define valid password formats by setting the text view’s passwordRules property. This property takes an UITextInputPasswordRules object, which contains a rules descriptor string.

Apple provides an interactive online Password Rules Validation Tool to create and validate custom password rules.

Password Rules Validation Tool

User interaction with Autofill feature

When users select an item from the QuickType bar, the system asks them to authenticate using Face ID or Touch ID in order to use the selected credentials. The app becomes inactive, triggering app delegate’s applicationWillResignActive(_:) and applicationDidBecomeActive(_:) methods. The fields should not be removed on this action. Otherwise, the system will not be able to autocomplete them.

When the text is changed in the field the textDidChangeNotification notification is sent. It can be used to validate the text or modify the UI if needed. However, if the fields are auto-filled with the strong password, and the user selects to use their own, no notification is received on clearing the fields.

This case may be useful for changing the user interface as well — for example, enabling the login/signup button once the user name and password fields are filled, and disabling it when they become empty once again.
It is possible to “catch” the change in viewDidLayoutSubviews() method.

override func viewDidLayoutSubviews() {
    super.viewDidLayoutSubviews()
    // Do all needed updates, e.g. disable the button
    loginButton.isEnabled = !(usernameTextField.text.isEmpty || passwordTextField.text.isEmpty)
}

What’s next?

In this article, we’ve covered the implementation of the iOS Password Autofill feature and most of the issues a developer can encounter while doing it.

If you want to discover more, you can review the following links:

• Setting Up an App’s Associated Domains
• Password AutoFill
• Password AutoFill workflow
• Enabling Password AutoFill on a Text Input View.
• Password Rules Validation Tool