Password AutoFill Providers on macOS and iOS
Password AutoFill Providers on macOS and iOS
Apple's platforms handle third-party password managers in fundamentally different ways. On iOS, a password manager can register as a system-wide credential provider and appear in Settings → General → AutoFill & Passwords, filling credentials in any app or browser. On macOS, that API surface effectively does not exist for third parties: the "AutoFill from" list in System Settings shows only Apple's Passwords app, and managers like 1Password autofill exclusively through browser extensions.
Core principle
Autofill is a trust boundary. Whoever fills a password field must (a) know which app or site is asking, to prevent phishing, and (b) be authorized by the user as a credential source. Apple solved this differently on each platform:
- iOS — apps cannot inject UI into each other, so Apple built the credential-provider extension point (an
.appex, see App Extensions (appex) on macOS). The system draws the QuickType suggestion bar, asks the registered provider for matching credentials, and passes the result into the target field. The provider never touches the target app directly. - macOS — browsers already support extension ecosystems, so third-party managers inject autofill UI in-page via browser extensions. Apple's own suggestions (strong password generation, saved credentials, Hide My Email) are drawn by the OS as a native overlay above the page.
Why the two dropdowns collide in Safari
Both systems attach to the same focused field, but they render at different layers:
- Apple's suggestion dropdown is drawn out-of-process by the system. No page CSS or extension can reposition or cover it.
- A manager's extension (1Password) injects its suggestion UI into the page's DOM — always underneath the native overlay.
The result: with both enabled, Apple's dropdown wins visually and the extension's suggestions appear obscured or not at all. The fix is to pick one provider per platform:
- macOS + third-party manager: turn off System Settings → General → AutoFill & Passwords → "AutoFill Passwords and Passkeys", and uncheck Safari → Settings → AutoFill → "User names and passwords" and "Contact information" (the latter generates the email / Hide My Email dropdown). The browser extension then handles suggest, fill (⌘\ in 1Password), and save.
- iOS + third-party manager: enable the manager in Settings → General → AutoFill & Passwords and disable Apple Passwords there. Both routes use the same credential-provider API, so they coexist cleanly in one list.
The suggest-but-cannot-save trap
Safari's password features are controlled at two independent layers, and a mismatch produces confusing half-working states:
| Layer | Setting | Controls |
|---|---|---|
| System | AutoFill Passwords and Passkeys | System-drawn suggestions (strong passwords, passkeys, codes) |
| Safari | AutoFill → User names and passwords (AutoFillPasswords) | Safari's own fill and the "Save this password?" prompt |
With the system toggle on but Safari's checkbox off, Safari still suggests a generated strong password (system layer) but never offers to save it (Safari layer) — a lockout risk, since the generated password is used once and stored nowhere. This looks like a broken machine but is a settings mismatch. Either enable both layers (all-Apple) or disable both and let a browser-extension manager own the whole flow.
Verifying provider capability
A manager can only appear in the system AutoFill list if its app bundle ships a credential-provider .appex:
bashfind /Applications/1Password.app -name "*.appex" # macOS: empty pluginkit -m | grep -i 1password # Safari extension only
On iOS the equivalent extension ships in the app and registers automatically — the reason the same vendor appears in the iOS list but not the Mac one.