If you did a search on Dribbble, you may be led to believe that most apps only care about signing up and logging in. By the principle of making a good first impression, sure, it’s an important experience to nail. But frontloading the flashiest of your designs can lead to a letdown when all the glitz and glamor wears off.

This isn’t a misguided trend. Sweating the details of user authentication creates a bit of a paradox. As an architect might avoid installing easily-broken glass near a home’s deadbolt lock, it is up to you to encourage safe practices in your apps. If you encourage lazy ones, users will be all-too-happy to take you up on it; then, it’s easy to lay blame if something goes wrong. But if you do it right all along, the user never notices.

Of course, we all dislike passwords. In tech, we’ve been stuck with them since about 1961. The rest of the world has come to know and equally dislike them ever since. From ever-larger database breaches to Google and Mozilla collaborating on web standards for more consistent authentication, thinking about how to live without passwords has come somewhat into vogue.

Some new alternative may be perfectly good all on its own, but what about everything in our lives that already have passwords? Think about every website you’ve signed on since you created nerdlover30307@hotmail.com over a decade ago, and how many others still you’ve signed into using Twitter, Google, or Facebook. How much of a pain will it be to even remember the method by which you should log in as new ones evolve?

Same As It Ever Was

On the other hand, Apple has long gone down a path that accepts the status quo of authentication — that is, a miasma of passwords and two-factor codes — with the Keychain and Password Auto-fill. These are uncharacteristically practical for them. If you’d ask me which tech giant would make an incompatible choice to force the whole industry to eventually follow suit, I’d say Apple.

Yet, in the crucial area of user security, Apple strikes a balance between convenience and safety. They meet their users where they already are (on the web) to deliver better experiences sooner than if paving their own way. In the modern Internet, where one trusted provider communicates with another — typically doing the complex work of encryption in your stead — a sufficiently strong password is still, easy to explain to a layman, readable, and surprisingly resilient to getting lost or locked in an incompatible format.

Not content with the opt-in support for password auto-fill brought to apps last year in iOS 11 and macOS High Sierra, Apple is taking a considerably more bold approach this year with iOS 12, macOS Mojave, and tvOS 12. Saving and retrieving passwords are now the default choice, both in apps and on the web, even to the exclusion of showing a keyboard when entering a password.

This isn’t confined to just the keyboard or just iCloud Keychain, either! iOS can ask for entries from third-party apps, search for one-time codes in Messages, and even share passwords to your nearby Apple TV.

How Do I Use It?

Apple’s app platforms build up their features on the basis of trust. Users can generally trust that apps are what they say they are when they go to the App Store. Likewise, to be able to store and retrieve the credentials for your service, Password Autofill needs to know it can trust you to be representing that service.

This association happens in two parts. Your app expresses that it’s operating on behalf of your service through the use of an entitlement. Set these up in the Capabilities tab for your app in Xcode.

Next, confirm the association as the site’s owner by creating an apple-app-site-association file on the server.

{
  "webcredentials": {
    "apps": [ "53A8EFRS44.com.bignerdranch.theborder" ]
  }
}

Finally, you can tag your login fields with an appropriate content type. There will be a ton of options in this list; keep them in mind as you do other work on your app to make autosuggest and autocomplete work almost like magic.

Without doing any of the above, iOS makes a guess at what fields correspond with usernames and passwords in an unmodified app to let the user paste any password from the keychain into the list. But this represents a best practice, providing the most consistency for you and your user. It also adapts to your app’s existing workflows, like having username, password, and two-factor codes all on separate screens.

(Auto-)Filling in the Gaps

A good platform provides you with a canvas on which to build a compelling experience. But it’s also the responsibility of the platform to notice when patterns arise and build better abstractions around them. This is the case for password autofill, where solid security foundations underpin a frightfully manual UI that eventually spreads its wings to full-fledged password management.

You can do your part by adopting these new patterns. Not only does this reduce the footprint of your code, but it will better match your app with the rest of the device and reduce confusion. Over the years, we’ve had many mechanisms for displaying in-app web browsers. Shipping alongside this expanded password support is the purpose-built ASWebAuthenticationSession, which enables logging in using a separate third-party service while protecting the user’s credentials.

A good implementation of a pattern also provides customization. The password auto-fill flow described above can be customized for a service that requires certain password formats. Certainly, it would be frustrating to have iOS offer a strong password, only to have it be too long or short. In code, you can provide an object of type UITextInputPasswordRules to describe to the system what kind of password you’re looking for. There’s even a tool for creating these rule sets.

In the end, very few of us are building username and password apps. Spend your time building a great experience and focus on the essentials. Strong security doesn’t start and end with password auto-fill, but balancing security and safety by default in your interface will get you a long way. Perhaps one day soon, we’ll be able to pretend passwords don’t even exist.