General: Forums topic: Privacy & Security Privacy Resources Security Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I’m looking for the documented Security.framework/macOS contract for this exact same-process sequence. An app creates a P-256 private key with SecKeyCreateRandomKey using: kSecAttrKeyType = kSecAttrKeyTypeECSECPrimeRandom kSecAttrKeySizeInBits = 256 kSecAttrTokenID = kSecAttrTokenIDSecureEnclave and, within kSecPrivateKeyAttrs: kSecAttrIsPermanent = true kSecAttrApplicationTag = <a unique tag> The app keeps the SecKeyRef returned directly by SecKeyCreateRandomKey alive and copies the corresponding public key with SecKeyCopyPublicKey. The app calls SecItemDelete with a query that uniquely matches that exact keychain item, and SecItemDelete returns errSecSuccess. Immediately after SecItemDelete returns, in the same process and without releasing or reacquiring the private-key reference, the app attempts a private-key operation using that same creation-returned SecKeyRef. Does errSecSuccess contractually guarantee that the already-retained SecKeyRef can no longer perform private-key operations from the point SecItemDelete returns? More concretely, is the following outcome forbidden by the API/platform contract: SecKeyCreateSignature succeeds after deletion, and the resulting signature verifies with the public key copied before deletion—that is, the public key from the same generated key pair? Or is invalidation of an already-issued SecKeyRef unspecified or otherwise not guaranteed by Security.framework? I’m asking only about the immediate post-return usability of the creation-returned SecKeyRef in this exact sequence. A clarification from Apple staff distinguishing the supported API/platform contract from current implementation behavior would be especially helpful.

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.

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 October 3rd, I've stopped receiving responses to the Private Access Tokens challenge. I'm using this link: https://demo-issuer.private-access-tokens.fastly.com/.well-known/token-issuer-directory. I receive tokens from Fastly and return a header to the iOS app, but then I don't receive another authentication request from iOS. The user has automatic verification enabled on their phone. The problem is global and affects all my mobile app users. Has anyone encountered a similar problem and found a solution?

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.

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.

Sign in with Apple fails with "Sign-Up Not Completed" for one App ID only — other apps in the same team work on the same device I have a Sign in with Apple failure that is isolated to a single App ID, and I would appreciate an Apple engineer looking at the server-side registration state for it. Filed as FB24483427. Symptom For App ID com.laonmon.twothrones (Team LH4XJ8LL98), Sign in with Apple never completes: The native ASAuthorizationController sheet appears correctly. The user authenticates with Face ID / Touch ID. iOS shows "Sign-Up Not Completed". The delegate receives ASAuthorizationError code 1000 with no further detail. No request ever reaches our server, so the failure happens entirely inside Apple's authorization flow. Our production database shows 0 accounts created via Sign in with Apple out of 147 total accounts — it has never succeeded for any user. The control experiment This is the part I think is diagnostic. Tested in one sitting, on the same iPad, signed in with the same standard (non-managed, adult) Apple ID: Notion (third-party App Store app) — sign-up completes SwingNote (my own released app, com.swingnote.app, Team LH4XJ8LL98) — sign-up completes Two Thrones (com.laonmon.twothrones, Team LH4XJ8LL98) — "Sign-Up Not Completed" Same device, same Apple ID, same team, same capability configuration — only the App ID differs. That rules out the device, the Apple ID, the team account, and the local configuration. What I have already checked Entitlement is in the signed binary. codesign -d --entitlements - on the archive shows com.apple.developer.applesignin = ["Default"]. (I did find and fix a real build defect earlier: our archive step ran with CODE_SIGNING_ALLOWED=NO, which skips entitlement processing entirely. Before that fix the sheet did not appear at all. Worth checking if you see no sheet — but that is a different symptom from this one.) App ID capability is enabled — APPLE_ID_AUTH, APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT. I removed and re-added the capability and regenerated the provisioning profile. No change. All four App IDs in the team have identical Sign in with Apple settings. Settings › Sign in with Apple does not list the app on the test device, so no app-scoped identifier was ever created. The sign-up genuinely never completes rather than failing on reuse. Updated Apple Developer Program License Agreement accepted; App Store Connect banner cleared. This is not propagation delay. I have seen the thread where it started working after ~2 days. The capability has been configured since Aug 16 and has never succeeded — across three App Review sessions on different devices (iPad Air 11-inch M3 / iPadOS 26.6, iPhone 17 Pro Max / iOS 26.6) and my own testing. Device logs captured over USB show AuthenticationServicesUI and AuthKitUIService starting normally, but all authentication detail is redacted as <private>. I understand the Accounts/AuthKit logging profile is needed to read it, and I will attach a sysdiagnose to the Feedback report once I have it. Impact Three consecutive App Review rejections under Guideline 2.1(a). This is the only thing blocking our initial release. Question Given that the same device and Apple ID succeed for another app in the same team, is there a server-side Sign in with Apple registration or account-association state per App ID that can get into a bad state, and is there anything a developer can do to reset it? Anything I can check or provide would be welcome. Feedback: FB24483427 DTS case: 20000144146252 (Developer Support advised filing here — they cannot see Feedback Assistant reports themselves.)

they have removed my last post these people have been harassing me for eight years or more and I need help. They’re using MDM software and other management software like Remote Desktop’s.

You know that you can install up to 9 eSIMs and activate 2, right? I use two activated eSIMs, but when I turn them both on, it says my location cannot be found. I only get through when I make calls, and I receive very few calls. When I answer a call, one of the two SIMs turns off. My carrier and Apple say they are currently looking into this, but where can I get a response? I am trying to surrender my current phone and watch for repair for the sake of public interest, even if it means sacrificing privacy, but I have no way to do so. What is even more ridiculous is that the paired watch does not match the watch name or the actual watch itself. It looks as if someone else's watch has been paired. The digital crown, gestures, and health sensors are not working. I am just using the watch as a speaker to listen to music. None of the functions work. If Developer Mode were enabled, I could force gestures to work through Accessibility, but Developer Mode won't turn on.

Team ID: ED9QVUCFPE (individual) Bundle IDs affected: com.lumevolab.justmorriz, com.lumevolab.memiq Broken since: 28 July 2026, immediately after the Apple Developer Program membership was renewed/reactivated. Still broken on 21 August 2026 (24 days). Apple Developer Support case: 20000131208746 (closed: "no anomaly found on the membership", referred to the forums) App Review rejection: submission f087942b, 13 Aug 2026, guideline 2.1(a), "unable to log in with Sign in with Apple", on iPad Air 11" M3 / iPadOS 26.6 Symptom The native Sign in with Apple sheet opens, Face ID succeeds, and then the sheet shows the red error "Sign Up Not Completed" ("Registrazione non completata") underneath the Continue button. The sheet stays open, so ASAuthorizationController never calls back — the app-side code never runs. The sheet's own wording is "Create an account for ", so it is the account-creation step that fails on Apple's side, not our token handling. Device log (captured with idevicesyslog during a reproduction) akd ... signing request, calling GrandSlam (gsService) akd ... server response (733 bytes) akd(AppleIDAuthSupport) setError: 2:M2 missing (bad password) AuthKitUIService ... Showing Authorization UI Alert (8 ms later) M2 missing is the SRP exchange: the server did not return its M2 proof, i.e. it refused the client's M1 for this operation. Why this is not an account or device problem Sign in with Apple works on the same iPhone with the same Apple Account in third-party apps (verified with Vinted). It also failed on the App Review team's own iPad, with their own Apple Account (rejection above). So it is not tied to one account or one device. It fails identically on two different App IDs of the same team. Tried and made no difference: device restart, changing the Apple Account password, signing out and back in to the Apple Account. Configuration — verified via the App Store Connect API, not by eye Item State App ID com.lumevolab.justmorriz (89A4UV66RF) APPLE_ID_AUTH present, setting APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT Provisioning profile IOS_APP_STORE, ACTIVE, includes the applesignin entitlement com.apple.developer.applesignin ['Default'] in Debug, Release and Profile entitlements files Same entitlement in the signed binary verified with codesign -d --entitlements :- build/ios/iphoneos/Runner.app Firebase project playmorriz apple.com provider enabled Program License Agreement released 18 Aug 2026, accepted 21 Aug 2026 Paid Apps / Free Apps agreements both Active Membership active, renews 4 Apr 2027 What we tried on 21 August 2026, with no change Accepted the pending Program License Agreement (it was released on 18 Aug, so it cannot explain a failure that started on 28 Jul, but we ruled it out). Removed and re-added the APPLE_ID_AUTH capability on the App ID via the App Store Connect API (DELETE then POST /v1/bundleIdCapabilities), to force Apple to re-provision the server-side Sign in with Apple record for the App ID. Device restarted afterwards. Same error. Prior art suggesting a server-side cause Forums thread 790323 — identical akd … "M2 missing (bad password)", same asymmetry (other apps fine, one team's apps broken), thorough config checks. It resolved by itself after 11 days with no developer action. Threads 789588, 789418, 789579, 803591 — same class of report, no client-side cause ever identified. June 18–23, 2025: Apple acknowledged a server-side configuration fault producing exactly "Sign Up Not Completed" + invalid_client, affecting only accounts that had recently created or modified App ID / Services ID configurations (thread 790827). Our team's capabilities were re-provisioned at renewal on 28 Jul 2026 — the same class of event. Ask Please check the server-side Sign in with Apple relying-party record for team ED9QVUCFPE. Everything under our control is correct and has been re-created from scratch; the failure is in the sign-up call to GrandSlam.

Hello, I making VPN client app and would like to clarify Apple Guideline 5.4 article: "VPN apps may not sell, use, or disclose to third parties any data for any purpose, and must commit to this in their privacy policy", does it mean anonymous nodes/servers telemetry also can't be provided to third parties? Thank you

Case #20000132024383 has been filed with Developer Support; posting here as well for visibility Hi Apple Developer Support team, We are experiencing a release-blocking issue: Sign in with Apple always fails server-side with AKAuthenticationServerError -24000 for our bundle com.dadilo.app, on all devices and all Apple IDs we have tested, while the same devices and accounts use Sign in with Apple successfully in other apps. IDENTIFIERS Team ID: HF53KC83Z3 (Individual - Nguyen Duy Mao) Bundle ID: com.dadilo.app (App ID resource 96Q4FAZ8PF) App Store Connect app: "Dadilo: Giup viec nha" - Apple ID 6782634291 (unreleased; TestFlight builds 1.0.0 (120-126)) Client: native ASAuthorizationAppleIDProvider request (Flutter sign_in_with_apple plugin). No web/Services-ID flow is involved. SYMPTOM Every Sign in with Apple attempt completes the system sheet (Face ID/password succeeds, scope selection is shown), then iOS shows the alert "Sign-Up Not Completed". The app's ASAuthorizationControllerDelegate receives ASAuthorizationError code 1001. No credential is ever issued. Device syslog at the exact moment of each failure (captured 2026-08-07 and 2026-08-08): akd: SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2 AKRemoteViewController did complete with authorization (null), error Domain=com.apple.AppleIDAuthSupport Code=2, NSUnderlyingError Domain=AKAuthenticationServerError Code=-24000 akd: Creating AKAuthenticationServerResponse with status contents: (null) akd: Invalid/missing value for key acname: (null); Invalid value for key ut: (null); Invalid value for key authType: (null) The server rejects the request and returns an EMPTY payload; -24000 is the client's reaction to it. An initial tap sometimes logs AKAuthenticationError -7003 first. REPRODUCTION - fails in EVERY combination Devices: iPad mini (iPad16,2, iPadOS 26.5.2) and an iPhone (iOS 26.x) - fails on both Apple IDs: 2 different accounts (2FA enabled, adult, region Vietnam) - fails on both Builds: TestFlight 1.0.0 builds 122, 124, 125, 126 - fails on all Request shape: the standard request (email + fullName scopes, SHA-256 nonce) AND a minimal request (no scopes, no nonce) both fail identically DECISIVE CONTROL TEST (2026-08-08) On the SAME iPad, SAME Apple ID, SAME network, minutes after our app failed,le authorization for another app (ChatGPT - never previously authorized on this account) succeeded normally. So fresh-authorization SRP works for this erver issues credentials for other bundles but rejects com.dadilo.app specifically. Existing authorizations (Notion, Grab, Shopee, Goodnotes) alsocounts. ALREADY VERIFIED / RULED OUT Entitlement com.apple.developer.applesignin = [Default] present in the binary; the provisioning profile contains the entitlement (decoded and checked); the authorization sheet opens and biometric completes, so the entitlement is honored App ID capability APPLE_ID_AUTH enabled, APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (verified via App Store Connect API); no grouped-app configuration conflicts on the team Program License Agreement issued 2026-06-18, accepted 2026-06-21; no pendi Test Apple IDs are healthy: 2FA on, adult birthdays, no Family restrictionh Apple with other apps No stale authorizations: this app is not listed in Settings > Sign in with- Capability re-provisioning attempted 2026-08-08: deleted and re-created APnerated a brand-new App Store provisioning profile, rebuilt and re-tested(build 125) - identical -24000 failure Apple System Status showed no Sign in with Apple outage during any test REQUEST AKAuthenticationServerError -24000 is not publicly documented. Everything clecks out, and the failure is 100% reproducible for this bundle ID only.Please inspect the server-side Sign in with Apple configuration/state for co3 and advise what is rejecting credential issuance.The app is complete and ready for App Store submission; Sign in with Apple ier Guideline 4.8, so this issue is blocking our first release. Fullidevicesyslog captures from both days are available on request. Thank you, Nguyen Duy Mao Team HF53KC83Z3

We have observed significant UI changes to the SFAuthorizationPluginView login experience in the latest macOS Golden Gate Beta 5. After entering the account password at the SFAuthorizationPluginView screen, we were previously able to access the buttons and other child elements present in the SFAuthorizationPluginView using "accessibilityChildrenInNavigationOrder" . Currently the method returns that there are no child elements eventhough there are clearly child elements presents including apple's native Ok and Cancel buttons.This behaviour is consistently reproducible in our testing. Steps to Reproduce Configure and launch an unlock authorization plug-in using SFAuthorizationPluginView. Display the authorization UI in unlock. Enter the account password. Wait for the authorization UI to finish transitioning to the authenticated state. Query the SFAuthorizationPluginView accessibility hierarchy. Specifically query accessibilityChildrenInNavigationOrder. Observe that the method returns no child accessibility elements. Inspect the UI visually or using Accessibility Inspector and observe that child controls are still present, including the native OK and Cancel buttons. We would like to understand: 1.Is this a known issue with the current macOS Golden Gate Beta? 2.Is this expected behaviour due to the UI redesign, or is it considered a bug? 3.If it is a known issue, is there a fix planned for an upcoming beta or the final release? Any information or guidance would be appreciated. Thank you.

I have discovered another app which has taken assets, screens etc from my IPA bundle and are passing off as their own. I also checked my own IPA bundle and my metal shaders are accessible. It's obvious that the app is vibe coded and they just handed as much of my code as possible to Claude and asked it to reverse engineer. Considering any IPA bundle can be downloaded from the AppStore, is there any way to protect against this? I have put a lot of time into some of the assets and shaders and it's kind of frustrating to see them so easily stolen. With the rise of AI this will become a more frequent occurrence for sure.

We have observed significant UI changes to the SFUnlock login experience in the latest macOS Golden Gate Beta. After entering the account password at the SFUnlock screen,user has to click on Use Password button once and then click on the OK button to proceed to the desktop and for the login process to continue successfully. This behaviour is consistently reproducible in our testing. We would like to understand: 1.Is this a known issue with the current macOS Golden Gate Beta? 2.Is this expected behaviour due to the UI redesign, or is it considered a bug? 3.If it is a known issue, is there a fix planned for an upcoming beta or the final release? Any information or guidance would be appreciated. Thank you.

Hey there, im getting Sign up not complete! even with the official template https://developer.apple.com/documentation/authenticationservices/implementing-user-authentication-with-sign-in-with-apple my developer account is recently renewed, which it has expired for a bit i am using automatic managed signing I have a feel something went wrong my apple developer account id, and also this cause me getting invalid client when sign in with app on web app.

I’m implementing server-side App Attest validation and trying to verify my implementation against Apple’s published Attestation Object Validation Guide sample. I have already filed Feedback Assistant report FB24281098. Using only the values published in Apple’s sample, I can reproduce four apparent inconsistencies: Nonce calculation The documented procedure says to compute: clientDataHash = SHA256(clientData) and then: nonce = SHA256(authenticatorData || clientDataHash) Using the published server challenge, this produces: 1d1ce78912897de88cfe9fce5521aab37abfb09dc544833ff115612552cf75f3 However, the nonce contained in the sample certificate / published expected nonce is: 87b7d06d93a4294e46f011e66b6cc400f0bab20729976c619580b42ae60bff6e That value is reproduced when the raw challenge is appended to authenticatorData instead of SHA256(challenge). The block labeled “Expected clientDataHash” also appears substantially longer than a 32-byte SHA-256 digest. Public-key hash / key ID SHA256 of the leaf certificate’s X9.62 uncompressed P-256 public key is: ce0498f58483fbb4da0d7b2c63a5a538f552d4adcb9a4fa916195c49613e655d This matches the decoded key ID / credential ID from the attestation object. However, the separately published expected public-key hash is: 8a71a32b625b68012102c6300a7b36cd3c990f3b09dce2b1dd0da79f193e9a46 which appears to be SHA256 of the key-ID bytes instead. Bundle version The sample certificate extension contains the value "1", while the guide prose describes "1.0". Validation category The sample extension contains four bytes 01 00 00 00, while the guide describes the value as UInt32 category 1. I’m looking for clarification on the authoritative wire representation / parsing rule. Could Apple please confirm the authoritative byte-level behavior for these four fields, particularly: whether the nonce must use SHA256(clientData) as documented; whether the key ID must equal SHA256 of the X9.62 uncompressed public key; the exact bundle-version comparison rule; and the canonical validation-category representation? I’m intentionally avoiding accepting multiple interpretations or adding fallback behavior in a security-sensitive server verifier, so clarification from Apple would be greatly appreciated.

Hello, We have an enterprise application that provides a security agent plugin with custom UI based on SFAuthorizationPluginView. We’ve been testing it on macOS 27 Developers Betas 1 through 4 and we noticed that if we set screenUnlockMode to 2, then after a screen is locked for the second time during one session, it can no longer be unlocked. Here are the concrete steps to reproduce: Open Terminal. Run sudo defaults write /Library/Preferences/com.apple.loginwindow.plist screenUnlockMode -int 2 Lock the screen. Observe the “You must enter the password to unlock the screen” dialog window. Enter the correct password and press OK. Lock the screen again. Expected result: The dialog “You must enter the password to unlock the screen” is displayed again. Entering the correct password unlocks the screen. Actual result: The screen is black with no visible UI. Rebooting the system seems to be the only way to leave this state. Displaying custom UI at the unlock screen is a part of our core functionality and it has been working fine with screenUnlockMode = 2 since at least macOS 14. I have filed a feedback FB23918474; if it is a known issue, please merge it with mine so that I can receive updates on the matter. In the meantime, do you have any suggestions on what can be done? Thanks.

I am seeing recurring DCError.invalidKey in my iOS app using App Attest, and I'am trying to determine whether throttling or a quota can be a contributing factor before we look further. Questions Are there rate limits or quotas on generateKey, attestKey, or generateAssertion — scoped per device, per key, or per app? I understand exact thresholds may not be published; what I'd mainly like to know is whether such limits exist and roughly what timing window they apply over. If a limit is hit, which error surfaces? Specifically, can throttling ever present as DCError.invalidKey, or would it always be serverUnavailable (or another distinct code)? Does calling the attestation flow repeatedly in a short window (e.g. several times within a few minutes from an onboarding sequence) risk triggering throttling or anti-abuse rejection? Am I right that generateAssertion is entirely on-device and therefore not subject to any server-side limit — i.e. only attestKey contacts Apple's servers? Is throttling one of the documented causes of invalidKey, or is invalidKey strictly a key-state error (key absent from the Secure Enclave, already attested, from a prior install, etc.)? Being able to rule throttling in or out would help us narrow the investigation considerably. Thanks.

Issue Summary We are seeing consistently high latency when calling DCAppAttestService.shared.attestKey(_:clientDataHash:). The call routinely takes 4–5 seconds in the development environment and 7–8 seconds in production. In contrast, other DeviceCheck operations execute very quickly on the same setup (e.g., DCDevice.generateToken takes ~100ms, and generateAssertion takes ~80ms). Environment Details Platform: iOS (reproduced on physical devices) Framework: DeviceCheck / App Attest Entitlements: com.apple.developer.devicecheck.appattest-environment set appropriately for each environment (development / production) Execution Flow: generateKey (or keychain lookup) $\rightarrow$ attestKey $\rightarrow$ generateAssertion Representative Timings (Development / Physical Device) ensureKey (keychain reuse): 5 ms generateDeviceToken: 91 ms attestKey (Apple API execution): 5,196 ms generateAssertion: 76 ms Total Wall Time: ~5,505 ms Steps to Reproduce On a physical iPhone, invoke DCAppAttestService.shared.generateKey() (or retrieve an existing keyId). Generate a client challenge hash (SHA256). Invoke attestKey(_:clientDataHash:completionHandler:) with the keyId and hash. Observe the multi-second delay before the completion handler returns the attestation statement. Questions & Guidance Requested Expected Baseline: Is 4–8 seconds for a successful attestKey call considered expected behavior for Apple’s attestation servers, or does this indicate an anomaly? Environment & Regional Latency: Are there known factors (e.g., server geographic routing, network handshakes, or environment differences) that cause attestKey to be noticeably slower in production compared to development? Mitigation / Best Practices: Since attestation is recommended once per key/device lifecycle upon key generation, are there specific architectural patterns Apple recommends to avoid blocking UI or onboarding flows during this high-latency step? Note: We can supply full sysdiagnose logs, device model/iOS version breakdowns, and code snippets if required.