What is iOS Password AutoFill?

It is the system feature that suggests stored credentials for your app's sign-in fields. When a user focuses a login field, iOS can offer the credentials saved for your app or associated website, or a passkey, in the QuickType bar, so they sign in with a tap. For it to work, your text fields must declare what they are for, so iOS knows which is a username, password, or one-time code, and your app must be associated with your website so the system knows which saved credentials belong to it, via the Associated Domains entitlement and the apple-app-site-association file.

How does Password AutoFill improve security?

In two ways. First, by binding credentials to a verified domain: through the webcredentials association proven by your apple-app-site-association file, saved credentials are tied to a domain you own, so they autofill in your genuine app rather than being offered in a look-alike that could harvest them. Second, by making good practices the easy path: AutoFill encourages strong, unique, manager-stored passwords and supports passkeys, which are passwordless and phishing-resistant, plus domain-bound one-time codes, so users are nudged toward more secure credentials rather than weak, reused ones.

What are field content types for?

They tell iOS what each text field is for, so AutoFill can offer the right value in the right place. Marking a field as a username or password lets iOS suggest the saved credential there, and marking a field as a one-time code lets it fill a verification code arriving by SMS. Without these declarations, AutoFill may not recognize your fields and users fall back to typing, which tends to push them toward weaker, reused passwords. So declaring content types is both a usability and a security step, enabling correct credential and security-code filling.

Does Password AutoFill support passkeys?

Yes. Passkeys, which are passwordless and phishing-resistant, are offered through the same AutoFill flow once your associated-domains setup is in place, so adopting AutoFill positions you to offer passkeys as the strongest sign-in option. The same domain association that binds passwords to your app also underpins passkeys and domain-bound one-time codes, so configuring associated domains correctly with the webcredentials service enables the modern, phishing-resistant options rather than just password filling. Supporting passkeys through AutoFill is the recommended direction.

How do I check my AutoFill setup?

Scan the build. AutoFill configuration lives in your text fields and your entitlements, so a pre-submission scan such as PTKD.com reads the compiled IPA against OWASP MASVS and surfaces your associated-domains configuration and authentication handling, helping you confirm the webcredentials association is set and your app is bound to your domain. If the association is missing or misconfigured, the binding between your app and your website's saved credentials breaks, so the fix is to configure the Associated Domains entitlement and host the apple-app-site-association file correctly.

iOS Password AutoFill and associated domains

Password AutoFill is the feature that offers a user their saved login right above the keyboard when they tap a username or password field in your app. It is a usability win, but it is also a security feature: because the saved credentials are tied to a domain you have proven you own, they autofill only in your legitimate app, not in a look-alike, and the same plumbing enables passkey autofill and domain-bound one-time-code filling. Getting it right takes two things, telling iOS what your fields are for, and associating your app with your website. Here is what Password AutoFill is, how the pieces fit, and how to set it up securely.

Short answer

iOS Password AutoFill offers a user's saved credentials, and passkeys, in the keyboard above your login fields. Per Apple, you enable it by marking your text fields with the right content types, such as username and password, and by associating your app with your website through the Associated Domains entitlement using the webcredentials service and an apple-app-site-association file. That association is a security benefit: credentials are bound to a domain you have proven you own, so they autofill in your genuine app rather than being harvestable by a look-alike, and the same setup supports passkey autofill and domain-bound one-time-code filling. The work is to set field content types and configure associated domains correctly, which both improves sign-in and ties credentials to your verified domain.

What you should know

Password AutoFill offers saved credentials: in the keyboard above login fields.
Mark your fields with content types: tell iOS which field is which.
Associate your app with your website: via the webcredentials service.
Credentials are bound to your domain: they autofill only in your genuine app.
It supports passkeys and OTP autofill: the same setup enables both.

What is Password AutoFill?

It is the system feature that suggests stored credentials for your app's sign-in fields. When a user focuses a login field, iOS can offer the credentials saved for your app or associated website in the QuickType bar, so they sign in with a tap rather than typing, and the credentials come from the user's saved passwords or passkeys. For this to work well, two things have to be in place: your text fields must declare what they are for, so iOS knows a field is a username, a password, or a one-time code, and your app must be associated with your website so the system knows which saved credentials belong to it. The association is established the same way other domain-bound features are, through the Associated Domains entitlement, here with the webcredentials service, backed by the apple-app-site-association file on your domain. With those in place, credentials saved on your website become available in your app and vice versa, which is both convenient and a foundation for the security properties that follow.

How do the pieces fit?

Field content types plus a verified association. The table summarizes.

Piece	Role
Field content types	Tell iOS which field is username, password, or one-time code
`webcredentials` association	Links the app to your website's saved credentials
`apple-app-site-association`	The file on your domain that proves the association
Passkey autofill	Passwordless credentials offered through the same flow
Domain-bound OTP	One-time codes filled into the matching app

The two pieces you configure are the field content types and the domain association, and together they make AutoFill work correctly and securely. Declaring content types lets iOS recognize your fields, so it offers the username and password in the right places, and a one-time-code field can be filled from an incoming SMS code. The webcredentials association, proven by your apple-app-site-association file, ties the saved credentials to your verified domain. From that foundation come the security benefits: passkeys, which are passwordless and phishing-resistant, are offered through the same AutoFill flow, and one-time codes can be bound to your domain so they fill into the right app rather than being phishable into another. The association is what makes "these credentials belong to this app" trustworthy.

How do you set it up securely?

Declare your fields, configure the association, and adopt the modern options. Mark each sign-in field with its content type so iOS knows what it is, username and password for the login fields, and the one-time-code type for a verification-code field, which enables correct AutoFill and security-code filling. Configure the Associated Domains entitlement with the webcredentials service for your domain, and host the apple-app-site-association file correctly over HTTPS, so the association is verified and credentials are bound to your domain, which is what keeps them from being offered in a look-alike app. Support passkeys through AutoFill, since they are phishing-resistant and the strongest option, and where you send one-time codes by SMS, use the domain-bound format so the code is tied to your domain and app. Treat AutoFill as encouraging good user security, because it makes strong, unique, manager-stored credentials and passkeys the easy path, rather than something to work around. The principle is that declaring your fields and verifying your domain association turns sign-in into both a smoother and a more phishing-resistant experience, with credentials anchored to a domain you control.

What to watch out for

The first trap is not declaring field content types, so AutoFill does not recognize your fields and users fall back to typing, which nudges them toward weaker, reused passwords. The second is a missing or misconfigured associated-domains setup or apple-app-site-association file, which breaks the binding between your app and your website's credentials. The third is not adopting passkeys or domain-bound one-time codes, missing the phishing-resistant options the same setup enables. AutoFill configuration lives in your fields and entitlements, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled IPA against OWASP MASVS, surfaces your associated-domains configuration and authentication handling as the surface to confirm.

What to take away

iOS Password AutoFill offers saved credentials and passkeys in the keyboard above your login fields, configured through field content types and a verified domain association.
The association, using the webcredentials service and the apple-app-site-association file, binds credentials to a domain you own, so they autofill in your genuine app rather than a look-alike.
Set your field content types, configure associated domains correctly, support passkeys, and use domain-bound one-time codes, since the same setup enables the phishing-resistant options.
Use a pre-submission scan such as PTKD.com to surface your associated-domains configuration and authentication handling.