The issue below affects every partner app embedding our SDK, so we'd appreciate DTS taking a deeper look. We're happy to open a code-level support request and provide screen recordings and a sysdiagnose. Details are in FB25326312. We ship an SMS filtering SDK (a Message Filter app extension) that partner apps embed. Password AutoFill is treating the SDK's messagefilter: associated domain as a credential domain for the host app, so unrelated saved logins appear on the partner app's sign-in screen. Configuration Apple validates Message Filter network deferral against the containing app (an unauthorized containing app gets ILMessageFilterError.Code.networkURLUnauthorized), so the entitlement must be declared on each host app, not the extension: messagefilter:messagefilter.example.comThe AASA file at messagefilter.example.com lists the host app IDs under messagefilter only. It has no webcredentials key. Network deferral works as expected. (The real domain is in FB25326312.) Observed behavior On the host app's sign-in screen, saved logins for the SDK provider's domain (example.com) are suggested in the QuickType bar and the QuickType suggestions list: No webcredentials: domain: only example.com logins are suggested. App's own webcredentials: domain added (valid AASA entry): the app's logins appear, but example.com logins are still suggested alongside them. Password managers Reproduces with Apple Passwords and third-party password managers (tested with 1Password, Dashlane, and Norton Password Manager): Credential providers appear to receive the messagefilter domain in the serviceIdentifiers array passed to prepareCredentialList(for:). Some use only the first identifier, others use all of them. QuickType suggestions come from iOS itself, so the unrelated credentials appear regardless of which password manager is used. Seen on iOS 26 and iOS 27 in a production partner app. Questions Is it intended that a messagefilter: domain contributes to Password AutoFill credential matching? Is there a supported way to exclude it from AutoFill without breaking Message Filter network deferral?

Since iOS 27.0, domain-bound SMS one-time codes are no longer offered above the keyboard in our app, where the code is entered on a web page in a WKWebView, although the app is associated with the domain through webcredentials. The same SMS is offered in Safari on the same device, and it is offered in our app on iOS 26.6 and iOS 18. SMS format (last line per the domain-bound code format): Your verification code is: 123456 @app.example.com #123456Setup Several builds of the same app with different bundle IDs (App Store, internal, development), all under one team Entitlement com.apple.developer.associated-domains: webcredentials:app.example.com (plus two more environments of the same domain) AASA at https://app.example.com/.well-known/apple-app-site-association: 200, application/json, no redirect, same content on app-site-association.cdn-apple.com: {"webcredentials":{"apps":["TEAMID.com.example.app","TEAMID.com.example.app.internal","TEAMID.com.example.app.dev"]}} The code field is an <input type="tel" autocomplete="one-time-code"> in a WKWebView showing a page on that domain. We also tested a native field with the one-time-code content type (the app is built with Flutter; the field is a Flutter TextField with the one-time-code autofill hint). Steps Open the verification page in the app and focus the code field. Receive the SMS above. Expected: the code is offered in the QuickType bar, as it is in Safari on the same domain and as it is in our app on iOS 26.6 and iOS 18. Actual: nothing is offered. The keyboard log: kbd Received verification code from Messages kbd One Time Code field has been entered. kbd Retrieving Current One-Time Codes for App kbd Current verification code is domain-bound to <mask.hash: '…'>. kbd Domain-bound verification code is NOT valid for app <mask.hash: 'X'>. E kbd Could not fetch application record for application identifier: <mask.hash: 'X'>. kbd Returning 0 available one-time codesWhat we checked swcd downloads the AASA for all domains without errors after a reinstall. The installed app's entitlements (read from the device) contain the expected application-identifier and associated domains; the profile is validated. The failure is the same in the WKWebView field and in a native one-time-code field, in the App Store build, a distribution-signed internal build and a development build, and in an older app version that used to work. The masked application identifier in the log (X above) is the same for two builds with different bundle IDs, so the lookup does not seem to use the app's bundle ID. All our builds share CFBundleExecutable = Runner (the Flutter default) and the same CFBundleName. The same app build and the same SMS work on iOS 26.6 and iOS 18.x, so the change happened between iOS 26.6 and 27.0. An SMS without the @domain #code line is offered in the app on iOS 27 (Returning 1 available one-time code), although Could not fetch application record is still logged. Questions Is this a known iOS 27 regression, or is there a new requirement for apps to receive domain-bound codes? What application identifier does the keyboard use for this lookup, and can anything in the app's configuration (for example the executable name) affect it? Device: iPhone 17 Pro Max, iOS 27.0

Background: We are loading a web login page inside ASWebAuthenticationSession. For login page, username and password have autofill password options enabled. On click of the username textfield when we tap the system "Passwords" suggestion in the QuickType bar above the keyboard causes the app to become completely unresponsive. No crash occurs and nothing is logged to the console. The only option to get back to the app is we must force-quit to recover. This issue is observed only on OS 26.6.1 and 26.7.1 other variant of the OS-26.x seems to be working fine. We have tested the gmail app having the ASWebAuthenticationSession for login scenario, the similar issue is observed in that too. Does anyone else also have faced similar issue ? Any help/pointers much appreciated.

If a username field has .autocorrectionDisabled() or .textInputAutocapitalization(.never), tapping the saved login above the keyboard stops working once the user has typed part of their email. Nothing gets filled in. Seen on iPhone 16, iOS 27.0 (24A437). I've also reported this to Apple through Feedback Assistant (FB24825410). Steps to reproduce You need an app with Password AutoFill set up (a webcredentials associated domain) and a saved login for that domain. Tap the email field. The saved login appears above the keyboard. Type a few letters of the email. Tap the saved login. Expected: the email and password fields fill in, replacing what was typed. Actual: nothing happens. What works A username field with only .textContentType(.username) and .keyboardType(.emailAddress). Tapping the saved login fills both fields, no matter how much the user has typed. What breaks With .autocorrectionDisabled(), the tap works after 1 typed character, but does nothing after 2 or more. With .textInputAutocapitalization(.never), the tap does nothing after even 1 typed character. UIKit has the same problem: a UITextField with autocorrectionType = .no behaves like .autocorrectionDisabled(). In all of these cases, choosing the login from the key icon's Passwords sheet still fills both fields. Only the tap on the suggestion above the keyboard fails. Sample struct LoginView: View { @State private var email = "" @State private var password = "" var body: some View { VStack { TextField("Email", text: $email) .textContentType(.username) .keyboardType(.emailAddress) // Either of these breaks AutoFill once the user types: .autocorrectionDisabled() // fails after 2+ typed characters .textInputAutocapitalization(.never) // fails after 1 typed character SecureField("Password", text: $password) .textContentType(.password) } } } Workaround I removed both modifiers from our username field and it works. Typed emails still didn't get autocorrected in my testing. Has anyone found a way to keep these modifiers on a username field without breaking AutoFill? Possibly related: https://developer.apple.com/forums/thread/702970

According to this autofill credit card documentation we should be able to autofill credit card fields using the QuickType Bar for credit card fields, but it does not work. The QuickType Bar does not display for credit card fields (see screenshots) I have tested this on a physical device running iOS 27 (iPhone 16e), have added a card to the Autofill setting in the Wallet app, and have made sure my text fields have the correct textContentType values. I am able to autofill using the backup autofill menu, but it is less than ideal. It takes a minimum of 5 taps to autofill one field. It would be far less painful to just pull out the credit card and manually enter the information (see screenshot). Here is a link to my test project demonstrating the issue: https://drive.google.com/file/d/1wMGOUNhVnmt3rBAD0TSMf9NV39-JS9ij/view?usp=sharing

Our app signs users up through ASWebAuthenticationSession (not ephemeral). The sign-up page is a normal HTML form that posts to our server. When sign-up succeeds, the server redirects to our custom-scheme redirect_uri, which closes the session, as expected. When the user types a password and submits, iOS shows the "Save Password?" modal inside the session. From there, iOS 26 and iOS 27 behave differently: iOS 26.5: iOS waits. The form isn't sent until the user answers the modal. Then the request goes out, the redirect closes the session, and the password has been saved. iOS 27.0 and 27.2 beta 2: iOS doesn't wait. The form is sent right away, the redirect closes the session in under a second, and the modal disappears with it. The user never gets to tap Save. Things we checked: Same server, same page, same device, same app build. Only the iOS version changes the result. prefersEphemeralWebBrowserSession is off. Safari itself never waited on neither versions. The waiting only happened inside ASWebAuthenticationSession. Saving passwords still works on the device otherwise, and every test used a new account and password. Questions: Is the iOS 27 behaviour intended? If so, is there any supported way to let the user answer the sheet before the redirect closes the session? If it's a bug, is it tracked somewhere? The only fix we've found is to show an extra page after sign-up and only redirect from there, which adds a step for every user. We'd rather not ship that if the iOS 26 behaviour is coming back.

Anyone else notice that Autofill is providing passwords and credit cards without requiring any type of security. On my MacBook Air, it requires Touch ID or password. On my Mac mini it does not require anything. That seems like a major security hole?

Since release of 18.4. prepareInterfaceToProvideCredential .oneTimeCode case is not called and instead prepareInterfaceForUserChoosingTextToInsert() is called. That is the wrong delegate for this case and it causes confusion for the users. Also, some TOTP fields are recognised however, the key icon button is not presented above the keyboard next to TOTP suggestions. I've also tested 18.5 and it has the same issue. provideOneTimeCodeWithoutUserInteraction works just fine.

We ship a credential provider extension (ASCredentialProviderViewController, ProvidesPasskeys = true) backed by a USB CCID smart card token. It works on iOS 26.6. On iOS 27.0, TKSmartCard.beginSession() inside the extension never returns during a passkey request. The CryptoTokenKit log shows why. When a passkey request starts, AuthenticationServicesAgent takes an exclusive session on the reader to check whether it is a hardware security key. The check takes about 7 ms and comes back negative — our token has no FIDO applet. The agent then keeps the session for the rest of the request anyway. Our extension asks for the card 0.2 s later and gets queued behind it: 14:24:13.687776 usbsmartcardreaderd session requested by pid 2116 (1 now queued) 14:24:13.687793 usbsmartcardreaderd session busy (held by pid 2095); notifying holder 14:24:13.687849 AuthenticationServicesAgent got request for used session, setting flag to release it ASAP 14:24:34.884294 AuthenticationServicesAgent got request for used session, setting flag to release it ASAP 14:25:19.851779 AuthenticationServicesAgent got request for used session, setting flag to release it ASAP 14:26:12.501296 AuthenticationServicesAgent endSession 14:26:12.502320 usbsmartcardreaderd session granted to pid 2116 pid 2095 is the agent, pid 2116 is our extension. The system tells the holder three times that someone is waiting; it is released 118.8 s later, when the passkey request itself times out — by which point the card is useless to us. So it deadlocks: the agent holds the card until the request finishes, and the request cannot finish until we get the card to sign the assertion. One detail suggests this is not deliberate. The agent takes the session twice in a row and runs the identical check both times. The first one it releases after a second; the second one is the one that sticks. We saw the same pattern on two different days. We have not found any point in the request where the card is free. Things that do not work: grabbing it as early as viewDidLoad; grabbing it in provideCredentialWithoutUserInteraction before any UI appears; holding it in the containing app and handing it over once the extension starts (the queue is FIFO and the agent is ahead of us); and simply waiting, since the block lasts exactly as long as the request does. Has anyone else hit this? Has anyone shipped a smart-card-backed credential provider on iOS 27 and found a way around it? Is there any way to stop the system from claiming an attached reader while a passkey request is in flight — a setting, an Info.plist key, something on the relying party side, anything at all? We would happily take an ugly workaround at this point. And if you hit this and got nowhere either, that is useful to hear too — it would tell us this is not specific to our token. Questions Once the check has come back negative, the reader is known not to be a security key. Is there a supported way to make the agent release it at that point, or for an extension to declare that it needs exclusive access? Can this be turned off from Safari or from the relying party side? For an assertion (navigator.credentials.get): does hints: ["client-device"], or leaving usb out of transports in allowCredentials, stop the agent from claiming the reader? If so, that is a real mitigation for anyone who controls their own relying party. (authenticatorSelection.authenticatorAttachment only exists on registration options, so it is not available here.) Is TKSmartCard.beginSession() meant to block indefinitely, with no timeout and no cancellation? It bridges beginSessionWithReply:, so Swift concurrency cancellation does not reach it either. Failing with an error after a bounded wait would at least make this diagnosable instead of presenting as a hang. Filed as FB24171032 with a minimal sample project and full logs. Hardware, in case it matters: Aktiv Rutoken ECP, USB CCID. Any CCID reader without a FIDO applet should behave the same. iPhone 15 Pro on iOS 27.0 fails; iPhone 17 Pro on iOS 26.6 works, same binary and same token.

I can't seem to find information on this but this is causing a critical bug where the Strong Password suggestion sheet presents on any secure field (UIKit) and clears the others when closing it. This means the user cannot enter a password when there is a secure confirm password field because switching fields clears the other. This looks to be a recent issue but I can't tell when this was introduced or if this is SDK / OS version related. I am finding it in both Xcode 26.2 and 16.4 when running on device (iOS 26.2.1 and XC 26 simulators). Code to reproduce: class ViewController: UIViewController { override func loadView() { let v = UIStackView() v.axis = .vertical v.layoutMargins = .init(top: 16, left: 16, bottom: 16, right: 16) v.isLayoutMarginsRelativeArrangement = true view = v let t1 = UITextField() t1.textContentType = .username t1.placeholder = "Username" v.addArrangedSubview(t1) let t2 = UITextField() t2.isSecureTextEntry = true t2.textContentType = .newPassword t2.placeholder = "Password" t2.clearsOnInsertion = false t2.clearsOnBeginEditing = false t2.passwordRules = nil t2.clearButtonMode = .always v.addArrangedSubview(t2) let t3 = UITextField() t3.isSecureTextEntry = true t3.textContentType = .newPassword t3.placeholder = "Confirm Password" t3.clearsOnInsertion = false t3.clearsOnBeginEditing = false t3.passwordRules = nil t3.clearButtonMode = .always v.addArrangedSubview(t3) v.addArrangedSubview(UIView()) } } No matter what textContentType is used the strong password still forcefully breaks the flow and blocks the user.

I'm trying to diagnose some issues with my AutoFill credential provider not loading on macOS. As far as I can tell I have all the entitlements and provisioning profiles correct, and ASSettingsHelper.requestToTurnOnCredentialProviderExtension() returns true with the Credential Provider showing up enabled in System Settings. However all other attempts to call into AuthenticationServices fail, and ASCredentialIdentityStore.shared.getState() always returns false for state.isEnabled Looking at the logs I don't see anything that stands out but I am not sure I've got the correct filter on the logs. I see discovery taking place 2026-05-29 08:43:09.389967-0700 0xd7d00 Default 0x83c0b1 26490 0 CredentialProviderExtensionHelper: (PlugInKit) [com.apple.PlugInKit:discovery] [d 88616305-672E-4143-81A6-832522BCD790] <PKHost:0x7e6c24900> Beginning discovery for flags: 0, point: com.apple.authentication-services-credential-provider-ui 2026-05-29 08:43:09.390070-0700 0xd7d00 Info 0x83c0b1 26490 0 CredentialProviderExtensionHelper: (PlugInKit) [com.apple.PlugInKit:discovery] [d 88616305-672E-4143-81A6-832522BCD790] <PKHost:0x7e6c24900> Query: { "LS:ExtensionPlatforms" = ( 1, 6, 2 ); NSExtensionPointName = "com.apple.authentication-services-credential-provider-ui"; NSUserElection = 1; } 2026-05-29 08:43:09.392893-0700 0xd79ee Debug 0x83c0b1 487 0 pkd: (PlugInKit) [com.apple.PlugInKit:sandbox] issued file extension for [/Applications/test.app/Contents/PlugIns/testIDCredentialProvider.appex] 2026-05-29 08:43:09.392936-0700 0xd79ee Debug 0x83c0b1 487 0 pkd: (PlugInKit) [com.apple.PlugInKit:ls] [u C85BFC1E-25E1-4917-A1D8-0123013482EE] [com.myapp.test.App.testid-credential-provider(7.35)] info [CFBundleIdentifier] => [com.myapp.test.App.testid-credential-provider] 2026-05-29 08:43:09.392947-0700 0xd79ee Debug 0x83c0b1 487 0 pkd: (PlugInKit) [com.apple.PlugInKit:sandbox] issued mach extension for [com.myapp.test.App.testid-credential-provider] And I see it being discovered correctly: 2026-05-29 08:43:09.394535-0700 0xd7d00 Default 0x83c0b2 26490 0 CredentialProviderExtensionHelper: (ExtensionFoundation) [com.apple.extensionkit:NSExtension] discovered extensions: attributes { "LS:ExtensionPlatforms" = ( 1, 6, 2 ); NSExtensionPointName = "com.apple.authentication-services-credential-provider-ui"; NSUserElection = 1; }, extensionSet {( <EXConcreteExtension: 0x7e71b41c0> {id = com.myapp.test.App.testid-credential-provider} )} I don't see any errors related to security or provisioning that I can tell. Any tricks I can use to see why I can't use my Credential Provider?

I am using SwiftUI's native SecureField. When a user types their password manually, the dots render correctly in both light and dark mode. However, when iOS suggests and autofills a strong generated password, the dots become invisible in dark mode. Switching to light mode shows that they are there. Is there a supported way to force SecureField to re-render its secure entry dots correctly after iOS fills in a strong generated password in dark mode? import SwiftUI let warmMustard = Color(red: 0.780, green: 0.659, blue: 0.290) let lightText = Color(red: 0.973, green: 0.961, blue: 0.933) let darkText = Color(red: 0.118, green: 0.118, blue: 0.118) struct SecureFieldTestView: View { @Environment(\.colorScheme) var colorScheme @State private var username = "" @State private var password = "" @State private var confirmPassword = "" var body: some View { ZStack { Color(colorScheme == .dark ? UIColor.black : UIColor.white) .ignoresSafeArea() VStack(spacing: 20) { Text("Dark mode dot reproduction") .foregroundColor(colorScheme == .dark ? .white : .black) TextField("Username", text: $username) .textContentType(.username) .autocorrectionDisabled() .textInputAutocapitalization(.never) .padding() .background(colorScheme == .dark ? Color.black : Color.white) .cornerRadius(8) .foregroundColor(colorScheme == .dark ? .white : .black) .overlay(RoundedRectangle(cornerRadius: 8).stroke(warmMustard, lineWidth: 2)) SecureField("Password", text: $password) .textContentType(.newPassword) .padding() .background(colorScheme == .dark ? Color.black : Color.white) .cornerRadius(8) .foregroundColor(colorScheme == .dark ? .white : .black) .overlay(RoundedRectangle(cornerRadius: 8).stroke(warmMustard, lineWidth: 2)) SecureField("Confirm Password", text: $confirmPassword) .textContentType(.newPassword) .padding() .background(colorScheme == .dark ? Color.black : Color.white) .cornerRadius(8) .foregroundColor(colorScheme == .dark ? .white : .black) .overlay(RoundedRectangle(cornerRadius: 8).stroke(warmMustard, lineWidth: 2)) } .padding(.horizontal, 32) } } } #Preview { SecureFieldTestView() }

Hi Apple Developer Community, Quick question — is there currently a way to disable the “Save Password” prompt in iOS while keeping AutoFill enabled? From what I can see, the only available setting under Settings → Passwords → Password Options controls AutoFill as a whole, with no option to turn off just the save prompt. I’m using a third-party password manager and would prefer to keep AutoFill but avoid the repeated prompts to save credentials. Has anyone found a workaround for this, or is this simply not configurable at the moment? Thanks!

Hi Apple Developer Community, Quick question — is there currently a way to disable the “Save Password” prompt in iOS while keeping AutoFill enabled? From what I can see, the only available setting under General → AutoFill & Passwords controls AutoFill as a whole, with no option to turn off just the save prompt. I’m using a third-party password manager and would prefer to keep AutoFill but avoid the repeated prompts to save credentials. Has anyone found a workaround for this, or is this simply not configurable at the moment? Thanks!

I’m seeing a weird iOS Password AutoFill behavior in React Native and I’m trying to figure out whether this is: expected iOS behavior, a known React Native TextInput issue, or something I can work around. Setup: React Native 0.81.5 iOS app with Associated Domains configured and working Password AutoFill generally works fine two fields on a login screen: username/email: autoComplete="username" password: autoComplete="current-password" What happens: when the login screen opens, the iOS autofill bar above the keyboard shows the saved credential suggestion as expected as soon as I type a single character into the username field, the autofill bar goes blank instead of continuing to show a suggestion if I press delete while the field is already empty, the autofill suggestion flickers Important detail: autofill itself is not completely broken Associated Domains are set up and credential suggestions do appear the issue is specifically the unstable behavior of the autofill bar while editing Question: has anyone seen this with React Native TextInput on iOS? is this just how iOS reevaluates credential suggestions once the username starts changing? or is there a known RN-side trigger here, for example controlled inputs, secureTextEntry, rerenders, focus changes, or textContentType / autoComplete combinations?

Hello, I'm currently investigating an issue related to iOS credit card autofill (Payments & Card Details) in our mobile application. Our app is built using React Native, and we are implementing card input fields using TextInput with the required autofill configuration: autoComplete="cc-number" textContentType="creditCardNumber" Despite correctly configuring these properties, credit card autofill is not being triggered on iOS devices. I would appreciate clarification on: Is credit card autofill officially supported for React Native TextInput fields using autoComplete="cc-number" and textContentType="creditCardNumber"? Are there any additional requirements (entitlements, associated domains, specific configurations, etc.) needed for payment autofill to work? Is autofill expected to work inside WKWebView contexts? Are there any known limitations or restrictions for third-party frameworks such as React Native? I would appreciate any guidance or documentation you can share regarding the expected behavior and official support for this scenario

Hello there, Credit card autofill works in Safari when accessing the checkout on my website, but does NOT work when the same page is loaded in a WKWebView within the my iOS mobile app. is there any way I can make it work?

When using the Password AutoFill feature, after entering a password and navigating to another page, a system prompt appears asking whether to save the password to the keychain (as shown in the figure). If this prompt is not dismissed and the app is moved to the background, then brought back to the foreground, the prompt automatically disappears. However, after this occurs, all input fields within the app become unresponsive to keyboard input—no keyboard will appear when tapping any text field. The only way to restore keyboard functionality is to force-quit the app and relaunch it. How can this issue be resolved?

We have a native iOS app built with UIKit, and we are experiencing issues with credit card autofill when using the keyboard Quick Type bar. We have reviewed the documentation on Associated Domains, but we haven’t found anything that specifically addresses our issue. Our goal is to autofill all credit card details-including the CVV-in a single step, rather than one field at a time

After registe Passkey with webauthn library, i create a passkeyRegistration with follow, let passkeyRegistration = ASPasskeyRegistrationCredential(relyingParty: serviceIdentifier, clientDataHash: clientDataHashSign, credentialID: credentialId, attestationObject: attestationObject) and then completeRegistrationRequest like that, extensionContext.completeRegistrationRequest(using: passkeyRegistration) But a bad outcome occurred from user agent. NotAllowedError:The request is not allowed by the user agent or the platform in the current context. And the return data rawID & credentialPublicKey is empty,