Introduction

In iOS 11, Password AutoFill is primarily a system feature, not a UI control your app can fully own. That means there is no supported public API that says "this is a password field, but never show the Password AutoFill accessory suggestion." What you can control is how your text fields describe themselves to the system through traits such as textContentType and secure text entry.

Why The Password Accessory Appears

iOS decides whether a field looks like a login credential field by inspecting several hints, including whether the field is secure, whether nearby fields look like username and password inputs, and whether you explicitly set credential-related content types.

A typical login form does this:

usernameField.textContentType = .username
passwordField.textContentType = .password
passwordField.isSecureTextEntry = true

That is the correct setup when you want Keychain integration and system credential suggestions. Once you ask for that behavior, iOS is expected to show login-oriented assistance.

What You Can Actually Control

If the field is not truly a login password field, do not describe it as one. That is the main supported lever.

For a secure field that should not strongly advertise itself as a saved credential field, use more neutral traits:

1secretField.textContentType = .none
2secretField.isSecureTextEntry = true
3secretField.autocorrectionType = .no
4secretField.spellCheckingType = .no

This reduces the semantic hints you give the system, which may reduce or eliminate password-specific suggestions depending on the rest of the form.

The important limitation is that this is not a guaranteed "disable Password AutoFill" switch. It is only a way to avoid telling iOS that the field is a standard login credential.

Use The Right Content Type For The Workflow

Field semantics matter. If the user is creating a password rather than logging in, mark the field accordingly.

newPasswordField.textContentType = .newPassword
newPasswordField.isSecureTextEntry = true

If the field is for a one-time code, use the appropriate content type instead of pretending it is a password field.

codeField.textContentType = .oneTimeCode

Choosing the correct content type is often the real answer. Many requests to "disable AutoFill" come from a field being labeled incorrectly in the first place.

What You Cannot Reliably Do

There is no supported public iOS 11 API that removes the Password AutoFill accessory view while still keeping the field semantically marked as a real password field. If you label a field as .password, the platform is allowed to assist with passwords.

Trying to fight that with unsupported hacks is a poor trade. It tends to create brittle behavior across iOS releases and can also hurt accessibility or confuse users who expect standard platform credential features.

Test On Real Devices

Password AutoFill depends on the state of the device as much as on your code. Saved Keychain credentials, associated domains, and the overall shape of the form can influence what the user sees.

That means simulator behavior may not tell the full story. If this accessory view matters to your product, test on a real device with representative credentials stored in Keychain.

Common Pitfalls

The biggest pitfall is expecting a public switch that disables the password accessory UI for a true login field. iOS 11 does not expose that as a supported API.

Another common mistake is marking a non-login secret field as .password and then trying to suppress the system behavior that follows. Usually the better fix is to correct the field semantics.

Developers also sometimes treat Password AutoFill as a bug when it is really the intended result of the chosen text traits.

Finally, avoid unsupported UI hacks that try to outsmart the system keyboard behavior. They are fragile and tend to age badly across iOS versions.

Summary

• In iOS 11, Password AutoFill is mainly controlled by the system.
• There is no supported public API to fully disable the accessory suggestion for genuine password fields.
• Your main control is choosing the correct textContentType and related text input traits.
• Use .none only when the field is not actually a standard login credential field.
• Test on real devices because Keychain state and form context affect what appears.