Hello, I am developing an application that integrates with Apple Music to provide a personalized music video experience for Apple Music subscribers. We are working on support for many devices like Android TV / Google TV / WebOS / etc. and would like to implement an authorization experience suitable for a television, where entering account credentials with a remote control is cumbersome. Intended authorization flow We would like to implement the following experience: The application on the TV displays a QR code or short activation code. The user scans the QR code with their phone and opens an Apple-hosted authentication and authorization page. The user signs in to their Apple Account if necessary and approves Apple Music access for the application on the TV. The TV application receives or retrieves the resulting authorization and can use it for the supported Apple Music functionality. The objective is for the TV application itself to be authorized following approval on the phone, with no need to enter the Apple Account credentials on the television. Relevant implementation evidence found on Apple’s website While researching this integration, we examined JavaScript publicly served by link.apple.com. In the following OAuth view bundle, we observed these identifiers: PartnerAuthorizationRequest isOffDeviceOAuth2Flow DEVICE_CODE Source: Apple-hosted OAuth view bundle — oauth-views-OAuth-vue.4db9105e.js In the associated OAuth initializer bundle, we observed properties including: client_id scope response_type Source: Apple-hosted OAuth initializer bundle — oauth-views-OAuthInitializer-vue.23605d03.js These elements suggest that Apple’s authorization interface includes an off-device authorization path associated with partner clients. We understand that these implementation details are not public API documentation and do not establish whether this flow is available to third-party developers. We are looking for the officially supported integration and enrollment process, if one is available. Clarification requested 1. Availability for third-party TV applications Does Apple offer a supported Apple Music authorization flow of this kind for third-party applications running on non-Apple devices? If the observed flow is limited to certain integrations or partners, what are the eligibility requirements for obtaining access? 2. Client registration and account configuration What is the official process for registering or obtaining a client_id authorized to use this flow? We have reviewed the standard MusicKit configuration involving Media IDs, Media Services keys, App Services and Capability Requests, but have not identified the configuration or application process for off-device authorization. Could you clarify whether this requires: A standard MusicKit Media ID and Media Services key; An additional service configuration or managed capability request in the Apple Developer account; A separate OAuth client registration; Or approval through an Apple Music partner program? 3. Supported integration documentation If this integration is available, where can we obtain the documentation or SDK covering: The required client configuration, request parameters and permitted scopes; Creation of the authorization request and the QR code or activation link; The mechanism by which the TV checks for completion or receives the result; The resulting token type, its intended use, and its expiration or reauthorization requirements? In particular, we would appreciate clarification on whether the resulting authorization provides a Music User Token usable by the TV application, or another token that requires a documented exchange. 4. Apple Music access on the authorized TV Which Apple Music APIs or SDKs can consume the resulting authorization? We would like to confirm its supported use with Apple Music API and MusicKit for Android, including any separate requirements for playback on the TV. Our intended design is for authorization to be issued for the TV application, rather than transferring a Music User Token issued for the phone. If this access is handled outside the standard MusicKit developer workflow, could you please identify the applicable program and enrollment process, or who to route this request to the Apple Music team responsible for partner authorization and connected-device integrations? Thank you for helping us identify the supported path for this integration. Louis

Sign in with Apple fails for every App ID in our team (K9UFUZF2XW), on every device and every Apple ID we have tried. The system sheet appears, the user authenticates successfully, the sheet then shows "Sign Up Not Completed", and no credential is returned. The failure happens after authentication — this is not a client-side rejection. I have spent several days isolating this and have ruled out everything on my side. Posting the full evidence in case an Apple engineer can look at the server-side state for our team, and in case it helps others hitting the same wall. WHAT THE FRAMEWORK ACTUALLY RETURNS The client library we use (expo-apple-authentication) discards the original NSError, so I patched its native layer to surface the raw error verbatim. This is what ASAuthorizationController hands back to didCompleteWithError, immediately after the user authenticated and the sheet displayed "Sign Up Not Completed": ASAuthorizationError .canceled (rawValue = 1001) domain = com.apple.AuthenticationServices.AuthorizationError code = 1001 desc = The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError, error 1001) userInfo: NSUnderlyingError: So the framework reports a user cancellation that never happened, with a completely empty userInfo and no underlying error. There is no diagnostic information on the client at all — I cannot debug this any further from my side, because the information does not exist there. Note: the same failure surfaces as a different error code depending on the client library version — .unknown (1000) with the older version, .canceled (1001) with the current one. The user-visible behaviour ("Sign Up Not Completed") is identical in both. So the error code is not a reliable signal here. WHAT I RULED OUT Not the App ID. I created a brand-new App ID (kz.auraai.ios) with Sign in with Apple enabled as a primary App ID, built a fresh binary, tested on the same device with the same Apple ID — identical failure. Two independent App IDs in the same team fail the same way. Not the entitlement. Verified inside the signed binary, not just in the portal: application-identifier = K9UFUZF2XW.kz.auraai.ios com.apple.developer.applesignin = ["Default"] I also tried the workaround suggested elsewhere on these forums (removing the entitlement while keeping the capability in the portal). That made it strictly worse: iOS then rejects the request instantly, without showing the sheet at all. Which confirms iOS reads the entitlement correctly, the sheet works, and the user authenticates — the failure is downstream of all of that. No stray or wildcard App IDs. A commonly cited cause is other App IDs in the team lacking the entitlement. I enumerated the whole team via the App Store Connect API: it contains exactly two App IDs, both with APPLE_ID_AUTH = PRIMARY_APP_CONSENT. No wildcard identifiers exist. Not the Apple ID, the device, or the iOS version. The same Apple ID, on the same device, with the same iOS, signs in successfully through another app belonging to a different team (Expo Go, host.exp.Exponent) — a valid identity token is returned. A second, unrelated Apple ID on another device fails in my app in exactly the same way. So this is not scoped to one account: it affects every user of the app. Agreements and membership are in good standing. Program License Agreement accepted 30 June 2026; Developer Agreement accepted 26 June 2026; membership active. Both distribution types fail. TestFlight and ad-hoc. WHAT IS LEFT After all of the above, the only variable that differs between the working case (a different team's app, same device, same Apple ID) and the failing case (my app) is the Apple Developer team itself. This exact signature — sheet renders fully, final server submit fails, "Sign Up Not Completed", delegate reports canceled with no userInfo, not reproducible in other apps on the same device — is documented in thread 122458 ("Error: Sign-Up Not Completed"). In that case it affected multiple developers, including Apple's own sample app, and was ultimately resolved by Apple on the server side, with a recurrence reported in June 2025. THE ASK Could someone from Apple check the server-side Sign in with Apple registration for team K9UFUZF2XW (App IDs kz.auraai.app and kz.auraai.ios)? I am not looking for configuration advice — I have exhausted the client side and there is nothing left to configure. This looks like the same server-side state that was fixed in the referenced cases. Feedback Assistant: FB23716661 (includes sysdiagnose with the Accounts/AuthKit profile, timestamp, and video of the failure). This is currently blocking us: because Sign in with Apple works for none of our users, guideline 4.8 prevents us from offering Google Sign-In, so we are shipping with email-only login. Happy to provide the binary, entitlements dump, or a fresh sysdiagnose on request.

Hello, I’m working on a security agent plugin for Mac. The plugin provides a mechanism with custom UI via SFAuthorizationPluginView and a privileged mechanism with the business logic. The plugin needs to support unlocking the device, so I changed the authorize right to invoke my agent: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>evaluate-mechanisms</string> <key>created</key> <real>731355374.33196402</real> <key>mechanisms</key> <array> <string>FooBar:loginUI</string> <string>builtin:reset-password,privileged</string> <string>FooBar:authenticate,privileged</string> <string>builtin:authenticate,privileged</string> </array> <key>modified</key> <real>795624943.31730103</real> <key>shared</key> <true/> <key>tries</key> <integer>10000</integer> <key>version</key> <integer>1</integer> </dict> </plist> I also changed the system.login.screensaver right to use authorize-session-owner: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>rule</string> <key>comment</key> <string>The owner or any administrator can unlock the screensaver, set rule to "authenticate-session-owner-or-admin" to enable SecurityAgent.</string> <key>created</key> <real>731355374.33196402</real> <key>modified</key> <real>795624943.32567298</real> <key>rule</key> <array> <string>authenticate-session-owner</string> </array> <key>version</key> <integer>1</integer> </dict> </plist> I also set screenUnlockMode to 2, as was suggested in this thread: macOS Sonoma Lock Screen with SFAutorizationPluginView is not hiding the macOS desktop. In the Display Authorization plugin at screensaver unlock thread, Quinn said that authorization plugins are not able to use Touch ID. However, on a MacBook with at touch bar, when I lock the screen, close the lid, and then open it, the touch bar invites me to unlock with Touch ID. If I choose to do so, the screen unlocks and I can interact with the computer, but the plugin UI stays on screen and never goes away, and after about 30 seconds the screen locks back. I can reliably reproduce it on a MacBook Pro with M1 chip running Tahoe 26.1. Is this a known macOS bug? What can I do about it? Ideally, I would like to be able to integrate Touch ID into my plugin, but since that seems to be impossible, the next best thing would be to reliably turn it off completely. Thanks in advance.

We develop an authorization plugin that replaces password entry at the login window and at screen unlock with a phone-based sign-in. The user scans a QR code with their phone, or the Mac reaches the phone over Bluetooth. Either way the plugin ends up with the user's password, which it hands to the authorization engine as if it had been typed. All networking runs in a LaunchDaemon that the plugin calls over XPC. Setup system.login.console: loginwindow:login → OurPlugin:login system.login.screensaver: rule use-login-window-ui → authenticate-session-owner-or-admin, with screenUnlockMode set to 2 authenticate: builtin:authenticate → OurPlugin:authenticate The UI is an SFAuthorizationPluginView subclass. On success we set username and password in the context (plus home at login) and call SetResult with kAuthorizationResultAllow. What we see on macOS 27 Since moving to macOS 27 on a MacBook Pro (M3 Pro), we hit these more often: Touch ID unlocks the Mac but leaves our view on screen. Open the lid and unlock with Touch ID. The desktop becomes usable, but our plugin view stays on top, and shortly after the screen locks again. Same symptom as thread 819454, where it was filed as FB22289735. Saved passwords disappear from apps after an unlock through our plugin. They come back only after the user logs out and in again. This looks like FB13128730 (thread 796487). The lock screen stays on the desktop after sign-in. The clock, the user picture and our view, with its filled-in password field, stay on screen while the menu bar and Dock are drawn on top of them. Similar to FB12074874. We also saw this once: the password field in our view would not take keyboard input at the lock screen. Every key press just played the system alert sound, and nothing was typed. Questions Is there any workaround for these on macOS 27? Or a supported way to stop macOS offering Touch ID while our plugin handles unlock? Is an SFAuthorizationPluginView plugin still a supported way to replace the login and unlock UI? If not, what should we move to? Is Platform SSO with the new web-based authentication in macOS 27 (login window, Lock Screen and FileVault unlock) the path you would recommend? If so, is there a supported option for offline sign-in, which we do over Bluetooth today?

I'm testing PRF evaluation with a YubiKey Bio through AuthenticationServices on iOS. Registration succeeds, but during later authentication with the enrolled fingerprint, I don't receive a PRF result. Using the key’s FIDO2 PIN works. Environment iPhone 12 iOS 27.0.1 YubiKey Bio connected through USB Firmware: 5.7.0 Steps to reproduce Configure a FIDO2 PIN and enroll a fingerprint on the YubiKey Bio. Connect the key to the iPhone. Register a credential using ASAuthorizationSecurityKeyPublicKeyCredentialProvider with PRF support requested. Request authentication for the registered credential with PRF input and userVerificationPreference = .required. Authenticate using the enrolled fingerprint. Check the returned PRF result. Compare this with authentication using the FIDO2 PIN. Expected result Successful authentication with PRF evaluation returns a 32-byte PRF output. Actual result No PRF result is returned when using fingerprint verification. The PIN flow works. Related report I found WebKit bug #314934, which reports missing PRF results with a YubiKey C Bio in Safari. The reporter observed successful authentication but a null PRF output. Could AuthenticationServices be affected by a similar issue? Is there a known limitation or workaround for PRF evaluation with YubiKey Bio fingerprint verification?

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.

Our app's Sign in with Apple never completes. Apple's create-account sheet renders fully (name + share/hide-my-email step), then the final server submit fails and shows the "Sign Up Not Completed" sheet. The authorization callback returns ASAuthorizationError.canceled (1001) with no userInfo — even though the user did not cancel. Reproduced on multiple physical devices and multiple Apple IDs (all with 2FA), on iOS 26.5.1, since our first build. Team ID: 24XS837728 App ID: C54N9Q226H (bundle com.sucsessmaperrs.careerAssessmentApp) Verified on our side: com.apple.developer.applesignin = [Default] present in the distribution build (codesign -d --entitlements); embedded profile is the explicit App Store profile for the App ID (not wildcard). App ID has Sign in with Apple enabled as a primary App ID; capability deleted + recreated via the App Store Connect API today, no change. Firebase consumes the identity token; the failure is in Apple's UI before our code runs. App Store Connect agreements are clean. Key isolating fact: the same Apple ID on the same device completes a first-time Sign in with Apple sign-up in other third-party apps — only ours fails. So the cause appears scoped to our App ID / team on Apple's side, not the device, the Apple ID, 2FA, or our client code. This matches the widespread server-side "Sign Up Not Completed" failure in thread 675756 — same signature: multiple devices/Apple IDs, no console error, the failure delegate surfacing only as "cancel", newly created apps affected, even Apple's own sample app failing — which Apple ultimately resolved server-side (with a recurrence reported June 2025). Note this is the native ASAuthorizationController flow, not the REST/web flow, so the query-parameter percent-encoding fix from thread 122458 does not apply here. Could an Apple engineer check the server-side Sign in with Apple / account-association state for App ID C54N9Q226H (Team 24XS837728)? Happy to provide a screen recording or sysdiagnose.

We are hitting the same Sign in with Apple failure described in thread 837986, with an identical log signature. Posting our team details in case it helps the ongoing investigation. Team ID: CDLWFYN589 Bundle IDs: br.com.cesto, br.com.cestoparceiros App IDs created: 2026-08-20 (both recreated on that date) Build: TestFlight, iOS 26, physical iPhone SUMMARY Every first-time Sign in with Apple authorization fails with "Sign Up Not Completed". The Apple sheet renders correctly, with the right app name and the user's account. The user authorizes. The failure happens AFTER consent, in the SRP exchange with the Apple ID server. Our backend is never reached - signInAsync never returns a credential, so no server-side code of ours participates in the failing step. DEVICE LOG (akd, 2026-09-05 17:21:06-13, UTC-3) Client has default access level in SiwA entitlement Fetching developer team for client with ID: Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 No applications were found with the provided Client ID: Application has no shared credentials Using personal credential state - 2, error - Error Domain=AKAuthenticationError Code=-7074 presenting authorization UI for request <- sheet appears Got a response from user <- user authorizes No password, but CK is available. Will ask for ck-based auth. Task <59764A72-...> received response, status 200 AppleIDAuthSupport: setError: 2:M2 missing (bad password) Invalid/missing value for key acname: (null) Invalid value for key ut: (null) Invalid value for key authType: (null) SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2 The server returns HTTP 200 with the server proof (M2) absent. The "bad password" string appears to be the generic label for error 2 rather than a diagnosis - there is no password in this exchange, as the preceding line shows (No password, but CK is available). WHAT WE HAVE ALREADY VERIFIED Capability APPLE_ID_AUTH present on both App IDs, with APPLE_ID_AUTH_APP_CONSENT: PRIMARY_APP_CONSENT (read back through the App Store Connect API). com.apple.developer.applesignin: [Default] present in the SHIPPED .ipa, verified with codesign -d --entitlements :- on the extracted payload rather than on the archive. Embedded profile is "iOS Team Store Provisioning Profile" and carries the entitlement (security cms -D -i embedded.mobileprovision). Bundle IDs match across the project config, Identifiers and App Store Connect. No other App ID in the team declares APPLE_ID_AUTH. Program License Agreement accepted on 2026-08-25; 2FA active on the account. Requesting only fullName, with no email scope, does not change the outcome. The log line "Client has default access level in SiwA entitlement" is what closes the client-side question for us: the entitlement is present and read correctly ON DEVICE, not merely present in our build output. QUESTION Given the confirmation earlier in thread 837986 for team GW7XA5CX69 - same build and same configuration starting to work with no changes on their side - this looks like the same server-side condition affecting recently created App IDs. Could our Team ID be included in that investigation? Happy to file a Feedback with the full log attached and post the number here if that is the preferred route.

Hi, I'm trying to understand how the new OpenID authentication in macOS 27 behaves after a user resets their password in the identity provider. I understand that Microsoft Entra ID does not currently support the new OpenID Platform SSO flow in macOS 27. I'm using Entra ID only as an example here, my question is about the general macOS behavior and should apply equally to other identity providers such as Okta, Google Workspace, or any other IdP that implements the required Platform SSO 2.0 / OpenID support. Example: Mac is configured with Platform SSO and AuthenticationMethod = OpenID FileVault is enabled the user already has an existing local account and login Keychain the user resets their IdP password remotely they no longer remember the old local Mac password at the next Mac login they authenticate successfully using the new OpenID web login What happens next? If AllowWebLoginPasswordSync is enabled, I understand that macOS can synchronize the new IdP password to the local Mac account. My main question is what happens to the existing Keychain. Does macOS preserve the existing login.keychain and its contents, or can the user lose access to it because the old local password is no longer known? I'm also interested in what happens to things that depend on the existing Keychain, for example: saved application credentials certificates and private keys Wi-Fi credentials Apple Account / iCloud sign-in state And how does Platform SSO 2.0 Key Service fit into this? Apple documentation says that Key Service can unlock the user's key bag before login. Does that also help preserve access to the existing login Keychain when the old local password is no longer available? In practical terms, I'm trying to understand whether macOS 27 finally supports this workflow without losing user data or credentials: User forgets the Mac password → resets their IdP password → signs in through OpenID → continues using the same Mac profile and Keychain normally. Thanks :)

Before promoting passkey registration, I would like to check whether the user device has platform authenticator (or passkey platform authenticator). While trying to search such feature in the docs, I cannot find it anywhere. Is this intended? If there is no such api, how can we know whether the user can register passkey?

Hi Apple Developers, I am attempting to create a Apple Sign In capability for a web app and I have attempted to configure my Services ID configuration on 2 devices in 4 browsers and I am unable to select Web Authentication Configuration > Website URLs from the list that I have added. I figured it would be easiest to share a video demonstrating what I am trying to do and proving that I cannot accomplish it. https://www.loom.com/share/b927b398ef2648e39e60c0fc76791c90 Any ideas?

Sign in with Apple is failing for every user, on every device, for our live App Store app. Each attempt fails inside Apple's native sign-in sheet with the error "Sign-Up Not Completed" — before any of our code runs (no ASAuthorizationController delegate callback is reached). Environment / identifiers: Bundle ID: online.framenet.app Team ID: 5F2256QJNT App Store app: FrameNet, App ID 6799345029 (approved and live as of Aug 24, 2026) Timeline: Last worked: Aug 8, 2026 Failing on every attempt since: Aug 14, 2026, across builds 12–16 Our sign-in code is unchanged between the working and failing period Already verified / attempted on our side: Sign in with Apple entitlement is present in the signed builds (confirmed via codesign entitlement dump) Capability is enabled on the App ID in Certificates, Identifiers & Profiles Provisioning profile is valid and includes the capability Removed and re-added the Sign in with Apple capability and regenerated the provisioning profile on Aug 17 — no change Google Sign-In in the same app works normally, so networking and the rest of the auth stack are fine Reproduced on multiple physical devices and Apple IDs Because the failure occurs inside Apple's own sign-in sheet before our code executes, this appears to be a server-side state problem with Sign in with Apple for our App ID, and nothing we change client-side has any effect. We were forced to ship v1.0 with Sign in with Apple disabled. A Developer Support case is already open for this: case 20000140460775. A screen recording and full environment details have been provided in that case. Has anyone from Apple seen this "Sign-Up Not Completed" state, and can engineering inspect/repair the server-side Sign in with Apple configuration for this App ID?

Sign in with Apple has never completed for our app. The native sheet presents correctly (name, Share/Hide My Email), but on confirmation it shows "Sign Up Not Completed" with a red exclamation. No identity token is returned; the delegate receives ASAuthorizationError 1001 only after the sheet is dismissed. The failure happens entirely inside the system sheet, before any callback reaches app code. Environment: iPhone 15 Pro Max / iOS 26.6, TestFlight builds. The Sign In with Apple capability was newly enabled on the App ID five days ago and the flow has failed on 100% of attempts ever since. (I'm withholding the Team ID / bundle ID here since this is public — happy to share them with an Apple engineer via the open support case or a Feedback report.) Implementation - identical to Apple's "Implementing User Authentication with Sign in with Apple" sample; we even replaced the third-party wrapper we originally used with this first-party version to rule it out, and the failure is unchanged: let provider = ASAuthorizationAppleIDProvider() let request = provider.createRequest() request.requestedScopes = [.fullName, .email] let controller = ASAuthorizationController(authorizationRequests: [request]) controller.delegate = self // controller strongly retained until completion controller.presentationContextProvider = self controller.performRequests() Verified correct (not assumed — extracted/inspected directly): Signed binary entitlements (extracted from the distributed IPA): com.apple.developer.applesignin = (Default), with the correct application-identifier and team-identifier for our team embedded.mobileprovision in the bundle contains the same entitlement App ID capability read back via the App Store Connect API: APPLE_ID_AUTH with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (portal shows "Enable as a primary App ID") Exactly one App ID in the account; no wildcard, no duplicates Program License Agreement accepted; nothing pending Already tried, no change: re-saving the capability in the portal; deleting and re-creating the capability via the App Store Connect API; generating a new provisioning profile after that re-registration and shipping a new build signed with it; Share My Email and Hide My Email; device restarts (iCloud + 2FA active); waiting 5+ days for propagation. This matches threads 789588, 789418 and 789323, and the service-side configuration issue described in thread 790827 (invalid_client / "Sign Up Not Completed" for developer accounts that created or edited app configurations, resolved server-side with no developer action). A Developer Support case and a TSI are already open. Question for Apple engineers: with the client implementation identical to the official sample and every developer-side artifact verified, is there anything left on the developer side that can produce this - or can the Sign in with Apple service-side registration for our client_id be checked? This is blocking an App Store release (the app was rejected under Guideline 4.8 and Sign in with Apple is the required remedy). A sysdiagnose captured during reproduction is available, and I can provide the Team ID, bundle ID and case numbers privately on request.

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.

Hi everyone, I'm integrating Apple Maps Server API into the backend of a production iOS application (Java / Spring Boot). Before posting, I reviewed the following Apple documentation: Apple Maps Server API Creating and using tokens with Maps Server API Integrating the Apple Maps Server API into Java Server Applications Try Maps Server API I also verified the current Developer Portal behavior and inspected the network requests made by the Try Maps Server API page. What I verified Using the current Apple Developer Portal: Certificates, Identifiers & Profiles → Services → Maps → Configure Tokens I can successfully create a Server API token. I verified the following behavior: A Server API token can be created successfully. The token only supports the None restriction type. The token expires after 7 days. The Try Maps Server API page first calls GET /v1/token using the Server API token. The /v1/token endpoint returns a short-lived Maps access token. That Maps access token is then used to call Apple Maps Server API endpoints such as /v1/place, /v1/search, and /v1/reverseGeocode. Documentation vs. Developer Portal The current Apple Maps Server API documentation describes a production authentication flow in which developers: Create a Maps Identifier Create a Maps Private Key (.p8) Generate a signed authentication JWT Exchange that JWT for a Maps access token via GET /v1/token Use the Maps access token to call Apple Maps Server API However, in my current Apple Developer account: There is no Maps IDs section under Certificates, Identifiers & Profiles → Identifiers. There is no Maps or Apple Maps Server API key available under Certificates, Identifiers & Profiles → Keys. My account information: Apple Developer Program: Active Account Type: Individual Role: Account Holder Based on these observations, I'm not sure how the authentication flow described in the documentation relates to the authentication flow currently supported by the Developer Portal. Questions What is the currently recommended production authentication flow for Apple Maps Server API? Is the Server API token created from Certificates, Identifiers & Profiles → Services → Maps → Configure Tokens intended only for development and testing, or is it also the recommended authentication mechanism for long-running production backend services? If the production authentication flow described in the documentation is still the recommended approach, how can developers create a Maps Identifier and Maps Private Key using the current Developer Portal? Any clarification from Apple or from developers who have recently deployed Apple Maps Server API in production would be greatly appreciated. Thank you!

Is it possible to get to the SymmetricKeys provided by a passkey as per the WebAuthn prf extension by just having to authenticate the user locally? The use case would be signing into an app and decrypting user data encrypted with those keys while the device is offline.

Hi everyone! We recently integrated "Sign in with Apple" into our application using standard social login flows. For the vast majority of our users, the integration works perfectly—we receive the user's email during sign-in and sign-up. However, we are noticing an edge case where a small subset of users are returning an ID token that is completely missing the email. We can't seem to reproduce this error ourselves during testing. Every time we test a sign-up or sign-in, the email payload is included exactly as expected. My Questions: Is there a specific reason why Apple would omit the email claim from the ID token? Any insights or guidance would be greatly appreciated. Thank you!

Sign in with Apple never completes for our app. The authorization sheet presents, the user confirms, and we get ASAuthorizationError 1000. The akd log shows the local entitlement check PASSING and the failure happening server-side. Environment: native ASAuthorizationAppleIDProvider (no web flow, no Services ID), TestFlight build, iOS 26. New App ID created 2026-08-06. akd, abridged — local check passes: akd Requesting password only: NO akd Client has default access level in SiwA entitlement akd Client has underage-users access level in SiwA entitlement sheet presents, user confirms: akd presenting authorization UI for request akd Remote view sent a user response event akd Attempting authorization with response then the server rejects it, after returning HTTP 200: akd Adding passwordlessToken: NO, and idmsDataToken: NO, to auth-params akd No password, but CK is available. Will ask for ck-based auth. akd Performing SRP request with context akd Task ... received response, status 200 content K akd AppleIDAuthSupport: setError: 2:M2 missing (bad password) akd Invalid/missing value for key acname: (null) akd SRP authentication with server failed! Domain=com.apple.AppleIDAuthSupport Code=2 akd Error performing auth request: Domain=AKAuthenticationError Code=-7003 What we have already ruled out: Sign in with Apple enabled on the App ID, configured as "Enable as a primary App ID" (verified in the portal UI, not just via the App Store Connect API). Provisioning profiles deleted and regenerated AFTER enabling the capability, twice, the second time a full day later. The embedded .mobileprovision in the shipped build contains com.apple.developer.applesignin = (Default). The signed binary carries the entitlement (codesign -d --entitlements on the archive). More than 24 hours elapsed since enabling the capability, per the guidance on -7003 in thread 789697. requestedScopes tried as both [.email] and [.fullName, .email]. App deleted and reinstalled; device restarted. Reproduced on a SECOND device (an iPad) that had never had the app installed. Control: a third-party App Store app created a brand-new Sign in with Apple association (it prompted for name, so first-time consent) on the same device and same Apple ID, minutes after our failure, so the account and device can create new associations. Question: what causes Apple's identity service to reject the SRP exchange for one client while accepting it for others on the same device and account? Is there additional App ID or account state we cannot see from the portal? Happy to provide the full akd log.