Hello, I'm implementing the wallet extension but I found a problem in the passEntries function. This following part is giving nil ando I don't know why if let entry = PKIssuerProvisioningExtensionPaymentPassEntry( identifier: element.id, title: element.cardType ?? "Card", art: self.testImage()!, addRequestConfiguration: config! ) { entries.append(entry) } I debug and all the arguments have information but it doesn't create the entry

iCloud KeySyc is a privacy-focused feature that securely syncs a user’s personalized keyboard learning across all Apple devices through iCloud. Today, when users upgrade to a new iPhone or begin using a new iPad or Mac, the keyboard often loses much of the personalization it has developed over time. Users must re-teach autocorrect, rebuild custom vocabulary, and wait for the keyboard to relearn their typing habits. iCloud KeySync would allow users to move seamlessly between devices while keeping the keyboard experience familiar from day one. Problem Statement Apple’s keyboard becomes more useful over time as it learns: Frequently used words and phrases Personal slang and abbreviations Emoji preferences Autocorrect adjustments Writing patterns and typing habits When users switch devices, much of this personalization is lost or takes time to rebuild. This creates friction during device upgrades and reduces the feeling of continuity within the Apple ecosystem. Proposed Solution iCloud KeySync securely synchronizes keyboard personalization data across Apple devices. The feature would: Learn and store personalized keyboard behavior on-device. Encrypt and sync personalization data through iCloud. Restore keyboard preferences automatically when signing into a new device. Keep keyboard learning consistent across iPhone, iPad, and Mac. Key Features Personalized Vocabulary Sync Synchronizes user-added words, nicknames, slang, and frequently used phrases. Emoji Preference Sync Maintains commonly used emoji patterns across devices. Autocorrect Learning Sync Preserves learned corrections and accepted custom spellings. Typing Behavior Continuity Allows devices to share keyboard learning so users receive familiar suggestions regardless of which Apple device they use. User Controls Enable or disable iCloud KeySync. Reset keyboard learning at any time. View privacy information and storage usage. Privacy and Security Privacy should remain the foundation of the feature. All keyboard learning occurs on-device. Personalization data is end-to-end encrypted. Raw message content is never uploaded. Users retain full control over synchronization settings. Security protections match the standards used by iCloud Keychain. User Benefits New devices feel familiar immediately. Less time correcting autocorrect mistakes. Faster onboarding after device upgrades. Consistent typing experience across the Apple ecosystem. Improved customer satisfaction and retention. Example User Scenario A user upgrades from an older iPhone to a new iPhone. After signing into iCloud and restoring their device, the keyboard immediately recognizes their commonly used phrases, preferred emoji, custom words, and learned typing patterns. The new device feels personalized from the first message typed, without requiring weeks of retraining Business Value Improves the upgrade experience. Strengthens ecosystem continuity. Reinforces Apple’s privacy-first approach to AI and machine learning. Creates a subtle but meaningful quality-of-life improvement for millions of users. Switch phones. Keep your vibe.

Hey there, I'm trying to building an iOS credential provider (ASCredentialProviderExtension, iOS 17+) that manages passkeys backed by keys generated in the Secure Enclave, attested via App Attest. My question is about the cross-device (FIDO2 hybrid / "passkey on a nearby device") flow, where a phone authenticates a sign-in initiated on a separate client device (e.g. a laptop browser). Specifically, Can a third-party credential provider serve as the authenticator in this flow, signing with its own key — or is the cross-device role reserved for iCloud Keychain? If it can, does the OS handle the BLE advertisement and tunnel/handshake on the provider's behalf? I ask because it seems like CBPeripheralManager.startAdvertising(_:) will not emit raw bytes, so an app can't emit a CTAP hybrid advert itself. If neither is supported, is there any supported API — including MDM-managed/supervised-device capabilities — for an app to act as a cross-device FIDO2 authenticator with a non-iCloud-Keychain key? Thanks!

We have a macOS app (io.formhealth.SideCore) that acts as a browser-style wrapper, embedding multiple web applications in WKWebView panes. We need the com.apple.developer.web-browser.public-key-credential entitlement so that WebAuthn/passkey flows (e.g. Google OAuth) work within the embedded webviews. The capability doesn't appear on macOS App IDs in the developer portal, and the entitlement request form at developer.apple.com/contact/request/system-extension returns "Your account can't access this page." What's the correct process to request this entitlement for a non-App-Store macOS app?

I’m trying to build and run a brand-new Xcode project created from the Audio Unit Extension App template for local macOS development on a brand-new Mac, and I’m blocked by a signing/keychain issue. Environment: macOS on a brand-new Mac Xcode 26.4.1 Build version 17E202 Personal Team Targeting My Mac Project type: Audio Unit Extension App Main symptom: During build/run, Xcode repeatedly shows this prompt: codesign wants to access key "Apple Development: Sam Magnant (...)" in your keychain It asks for the login keychain password. Important detail My current Mac password successfully unlocks the login keychain manually in Keychain Access every time. So the issue seems specific to Xcode / codesign using the Apple Development private key, not a general inability to unlock the keychain. What I’ve already tried Reset the default keychain Logged out and back in after reset Changed my Mac account password to a new password Confirmed the login keychain unlocks manually with the current Mac password Deleted and recreated local Apple Development certificate/private key where possible Removed and re-added my Apple account in Xcode Checked the private key in Keychain Access Confirmed the private key exists under the Apple Development certificate Confirmed Allow all applications to access this item is already checked on the private key Removed App Groups and other extra capabilities to simplify the project Tried security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k '' ~/Library/Keychains/login.keychain-db Tried switching the project to simpler signing configurations, then switched back to standard Apple Development signing What’s confusing Xcode appears to know about an Apple Development certificate/private key Keychain Access shows the identity under login > My Certificates The login keychain unlocks fine manually But codesign still prompts, and the machine reports 0 valid identities found Questions What would cause Keychain Access to show the Apple Development identity, but security find-identity -v -p codesigning to report 0 valid identities found? Is this most likely a broken certificate/private key pairing, trust chain issue, or something specific to Personal Team signing? Is there a recommended way to fully repair the local Apple Development signing identity on the current macOS user account without creating a new macOS user? Are there known issues with the Audio Unit Extension App template and Personal Team local development on macOS?

Steps to reproduce: register a passkey on device A authenticate on device A, using the prf extension and a constant salt. Note the prf output go to device B. wait for iCloud sync authenticate on device B using the prf extension and the same constant salt. Note the prf output The prf outputs are different. Note: Repeat the authentication on each device. The prf output is identical for a given device, which seems to point towards the inclusion of a device specific component in the prf derivation. In my scenario, I need the prf output to be the same regardless of the device since I use it as the recovery key for my app data. Could you confirm that this is the expected behavior or not? Thanks,

Hello, I am using the prf extension for passkeys that is available since ios 18 and macos15. I am using a fixed, hardcoded prf input when creating or geting the credentials. After creating a passkey, i try to get the credentials and retrieve the prf output, which works great, but i am getting different prf outputs for the same credential and same prf input used in the following scenarios: Logging in directly (platform authenticator) on my macbook/iphone/ipad i get "prf output X" consistently for the 3 devices When i use my iphone/ipad to scan the qr code on my macbook (cross-platform authenticator) i get "prf output Y" consistently with both my ipad and iphone. Is this intended? Is there a way to get deterministic prf output for both platform and cross-platform auth attachements while using the same credential and prf input?

There does not appear to be any way to use or create iCloud passkeys with a Safari Web Extension, either using the navigator.credentials API in an extension origin webpage such as the popover, or using the AuthenticationServices framework in the SafariWebExtensionHandler. I've setup an associated domain for my plugin, and I know it works for the host application. But I get errors trying to do so in the web extension target. createCredentialRegistrationRequests results in the following error: Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Application with identifier <ID> is not associated with domain <RPID> The other problem, assuming the entitlement works correctly for the web extension, is that there is no NSWindow to use as the presentation target from the SafariWebExtensionHandler. Trying to use the navigator.credentials.create JS API (which is the preferred method, frankly, in a web extension) results in the following error: NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. Chrome has a great solution for this that I believe should be adopted by Safari. If an extension has host permissions for a relying party it wants to claim, or if it has an associated domain entitlement for it, webauthn operations should be allowed.

Summary When an app is associated with a domain via applinks in the Apple App Site Association (AASA) file, the app's icon is displayed next to passkey entries in the iOS passkey selection UI (e.g., in Safari's sign-in dialog). This occurs even when: The AASA file does not contain a webcredentials section The passkey's relying party ID (rp.id) matches the domain, but the app has no webcredentials association The URL path of the passkey login page does not match any paths specified in the applinks configuration Environment iOS 18.6.2 iPhone 16 Pro Safari / Passkey UI via WebAuthn Steps to Reproduce Create an iOS app and register it in App Store Connect (or distribute via TestFlight) Configure the AASA file on the domain with only applinks — no webcredentials section: json{ "applinks": { "apps": [], "details": [ { "appIDs": ["TEAMID.com.example.myapp"], "components": [ { "/": "/specific-path/*" } ] } ] } } Implement WebAuthn/passkey registration on the same domain with the domain as rp.id Install the app on the device (via TestFlight or App Store) Register a passkey on the website via Safari Navigate to the login page and trigger the passkey selection UI Expected Behavior Since webcredentials is not configured in the AASA file, the passkey selection UI should NOT display the app icon next to the passkey entry. The passkey icon should be the default website favicon or a generic icon. Actual Behavior The app icon (from App Store Connect / TestFlight) is displayed next to the passkey entry in the selection UI, even though: Only applinks is configured (no webcredentials) The current page URL does not match any paths in the applinks configuration Impact In our production environment, we have a single domain serving multiple partner bank apps. The AASA file contains applinks entries for many different apps (20+ partner apps). When a user accesses the passkey login page, the passkey UI may display an app icon from one of these partner apps, which can be confusing for users — especially if the displayed icon belongs to a different partner's app than the one the user intends to use. Questions Is this the intended behavior — that applinks associations influence the passkey UI icon display? Is there a way to prevent applinks associations from affecting the passkey selection UI without removing the applinks entries? Would adding a proper webcredentials section with the correct app ID override the icon source from applinks to webcredentials? Is there a recommended approach for domains that serve multiple apps via applinks but want to control which icon appears in the passkey UI?

Could you tell me about account security and passkeys? Our service is considering implementing passkeys, and these questions are to understand how Apple protects accounts from third parties. ① Apple website states that two-factor authentication is mandatory for newly created Apple Accounts. When did this requirement come into effect? What are the conditions for users who do not have two-factor authentication enabled? ② Apple website mentions that a verification code may be required when signing into an Apple Account from a new device or browser. Is my understanding of the situations where a verification code is requested accurate, as listed below? Are there any other situations? Completely signing out of the Apple Account on that device. Erasing the device. Needing to change the password for security reasons. ③ If a user is already using a passkey on an Apple device, and then upgrades to a new device, will additional authentication, such as entering a PIN code, be required to use the passkey on the new device?

When using passkeys stored in iCloud Keychain (Passwords app) via Passkey Autofill in browsers other than Safari, the userVerification parameter is ignored and user verification (UV) is not performed. As a result, relying party servers that require userVerification = required fail validation because the UV flag is not set, causing passkey authentication to fail. This issue occurs when the following setting is disabled: Settings → Face ID & Passcode → Use Face ID For → Password AutoFill The issue is reproducible only with the following combination: Non-Safari browsers (e.g. Chrome) Passkeys stored in iCloud Keychain (Passwords app) Passkey Autofill The issue does not occur in the following cases: Safari with passkeys stored in any credential manager Non-Safari browsers using credential managers other than iCloud Keychain Steps to Reproduce: Go to Settings → General → Autofill & Passwords, and enable the Passwords app under “Autofill From”. Go to Settings → Face ID & Passcode → Use Face ID For, and disable “Password AutoFill”. Open Chrome and navigate to https://webauthn.io Enter a username and tap “Register” to create a passkey using the Passwords app (iCloud Keychain). On webauthn.io, go to Advanced Settings → Authentication Settings, and set “User Verification” to “Required”. Reload the page, tap the input field, and perform Passkey Autofill. User Verification is not triggered, and “Authentication failed” is displayed on webauthn.io. === This issue has already been reported via Feedback Assistant as FB21756948. I am posting here to confirm whether this behavior is working as intended or represents a bug, and to make other developers aware of the current behavior.

To use passkeys, you need to place the correct AASA file on the web server and add an entry in the Entitlements.plist, for example webcredentials:mydomain.com. This is clear so far, but I would like to ask if it's possible to set this webcredentials in a different way in the app? The reason for this is that we are developing a native app and our on-premise customers have their own web servers. We cannot know these domains in advance so creating a dedicated app for each customer is not option for us. Thank you for your help!

hello, I'm writing to seek clarification on Apple account security, particularly regarding potential risks of compromise, implemented safeguards, and residual risks with corresponding mitigation strategies. We would appreciate your insights on the following specific points: iCloud Keychain Access: Is an Apple ID login strictly required to access iCloud Keychain? We understand that a compromise of iCloud Keychain is unlikely unless a malicious actor successfully takes over the legitimate user's Apple ID. Is this understanding correct? Passkey Theft Methods and Protections: What are the conceivable methods a malicious actor might employ to steal a legitimate user's passkey, and how are these attempts protected against? Impact of Apple ID Compromise on Passkeys: If a malicious actor successfully compromises a legitimate user's Apple ID, is it accurate to assume that the legitimate user's passkeys would then synchronize to the attacker's device, potentially allowing them to log in using their own biometrics? Authorization Flow on Legitimate User's Device: Could you please detail the authorization flow that occurs on the legitimate user's device? We are particularly interested in the types of authentication involved and the conditions under which they are triggered. Detection and Additional Authentication for Unauthorized Login: How are attempts to log in to an Apple ID from an unrecognized device or browser detected, and what additional authentication steps are implemented in such scenarios? Thank you for your time and assistance in addressing these important security questions.

Hello, guys. I am going through a situation in which an open validation appears in the system/developer mode and I would like to understand better if this is something normal in this process. Could someone confirm if this type of validation is expected at this stage? I would also like to know what criteria I can observe to be sure that it is legitimate and that I can trust the activation. Thank you in advance for your attention and help. Thank you

Summary: We are facing a serious issue on iPhone where multiple passkey authentication problems occur when accessing passkey-enabled login pages via shortcuts placed on the iPhone Home Screen. These issues may also occur when opening the same pages directly in a standard browser window. However, launching the login pages from a Home Screen shortcut appears to increase the likelihood of encountering these issues. Affected Services (examples, not exhaustive): Amazon GitHub Adobe Observed Issues: Issue 1: A passkey authentication dialog/popup shows two times without any user operation: What happens due to this issue: Login does not complete after the first passkey authentication. A second passkey authentication UI automatically appears. Completing or canceling the second authentication allows the login to proceed. Issue 2: Login remains stuck until the user manually invokes passkey again What happens due to this issue: The login page does not advance after the first authentication. The user must tap the ID/username field again to manually trigger the passkey UI. Completing the second authentication enables login. Issue 3: Automatic second authentication occurs, but login still fails What happens due to this issue: A second automatic authentication UI appears. Login still does not complete. Tapping the ID field no longer opens the passkey UI; instead, the password auto-fill panel appears. Passkey login becomes impossible. Observed reproduction steps (not guaranteed but most consistently observed): On iPhone, navigate to a passkey-enabled login page (e.g., Amazon, GitHub, Adobe) using a browser. Create a shortcut from the browser's share menu and place it on the Home Screen. Launch the login page from the Home Screen shortcut. Tap the ID/username field to invoke the passkey prompt. Complete passkey authentication. → One of the issues described above occurs. Environment: Device: iPhone SE OS: iOS 18.6.2

aID is an ID service for 150+ newspaper sites in Norway. Since the middle of January the average login time with passkeys on our site https://www.aid.no/ has increased for Safari users, the number of logins using passkey in Safari has decreased dramatically. Previously Safari was the browser that provided the best user experience during login, since it triggered fingerprint reader straight away, but this behavior has vanished. Has something changed that we should be aware of, and is there something we can do to make conditional get great again? Without mediation conditional, the passkeys work as expected. In Chrome and Firefox, we get passkey suggestions in the username field, in Safari it's only password suggestions. To make things even stranger, the same code works as it used to in our test environment. It triggers a small popup by the username field and activates the fingerprint reader. If I cancel this, I can click on the Passwords icon and get passkey suggestion there.

I’m currently developing an application using WKWebView. After updating to iOS 26.2 Developer Beta, the following Web API started returning false: isUserVerifyingPlatformAuthenticatorAvailable MDN: https://developer.mozilla.org/ja/docs/Web/API/PublicKeyCredential/isUserVerifyingPlatformAuthenticatorAvailable_static This issue did not occur on iOS 26.1 — it only happens on the beta version. Has anyone else encountered this problem or is aware of any related changes? OS: iOS 26.2 beta 3 (23C5044b)

I'm developing a passkey manager using ASCredentialProviderViewController. I've set a custom AAGUID in the attestation object during registration: let aaguid = Data([ 0xec, 0x78, 0xfa, 0xe8, 0xb2, 0xe0, 0x56, 0x97, 0x8e, 0x94, 0x7c, 0x77, 0x28, 0xc3, 0x95, 0x00 ]) However, when I test on webauthn.io, the relying party receives: AAGUID: 00000000-0000-0000-0000-000000000000 Provider Name: "iCloud Keychain" It appears that macOS overwrites the AAGUID to all zeros for third-party Credential Provider Extensions. This makes it impossible for relying parties to distinguish between different passkey providers, which is one of the key purposes of AAGUID in the WebAuthn specification. Is this expected behavior? Is there a way for third-party Credential Provider Extensions to use their own registered AAGUID? Environment: macOS 26.2 Xcode 26.2

hello im using the new IOS 26 api for passkey creation ASAuthorizationAccountCreationProvider however it only seems to work with apple's Passwords app. Selecting 3rd party password apps (1Password, google chrome, etc) does not create the passkey. The sign up sheet gives me the option to save in 3rd party apps, but when I select a 3rd party app, I just get the ASAuthorizationError cancelled error? So I dont even know what the problem is? When selecting "Save in Passwords(apple's app)" during the sign up it works fine Has anyone else run into this issue? Is there something I need to do enable 3rd party apps?

When using iCloud Keychain passkeys with WebAuthn (mediation: "conditional") in non-Safari browsers (e.g. Chrome or WKWebView-based browsers), Face ID / Touch ID is requested twice during Passkey Autofill. This issue occurs only when the focused input field shows a numeric keypad–style keyboard, such as: Japanese Kana Chinese Zhuyin With a standard QWERTY keyboard, authentication completes with a single user verification. Notably: Safari completes authentication with one Face ID / Touch ID prompt even with numeric keypad keyboards. Other browsers require two prompts. The issue does not occur with other credential managers (Google Password Manager, 1Password), suggesting this is specific to iCloud Keychain. This issue has been confirmed on the following OS versions: iOS 17.6.1 iOS 18.7.2 iOS 26.2 iOS 26.3 beta Impact This behavior results in a confusing and unintuitive login experience for users relying on Passkey Autofill. Steps to Reproduce: Go to Settings → Keyboards → Keyboards, and set “Japanese – Kana” as the primary keyboard. Enable Face ID / Touch ID, and make sure “Use Face ID / Touch ID For” → “Password Autofill” is enabled. Open Chrome and navigate to https://webauthn.io. Enter a username and tap “Register” to create a passkey using iCloud Keychain. Tap the username field again so that the “Japanese – Kana” keyboard appears and the passkey suggestion created in step 4 is shown. Tap the passkey suggestion. Face ID / Touch ID is requested twice. === This issue has already been reported via Feedback Assistant as FB21726047. I am posting here to confirm whether this behavior is working as intended or represents a bug, and to make other developers aware of the current behavior.