We are implementing a one-free-trial-per-device rule for an iOS app. Our server uses App Attest to validate the app instance and DeviceCheck’s per-device bits to record that the device has received its trial. We grant the trial only after the server can confirm that the DeviceCheck bit was successfully stored. The unresolved case is when our server sends an update request to Apple, but the connection times out or closes before receiving a response. Apple may have accepted the write even though our server does not know the outcome. What is Apple’s recommended recovery procedure for this situation? Specifically: After an uncertain update response, can the server query the device’s bits to authoritatively determine whether the update succeeded? Does DeviceCheck provide read-after-write consistency for this query? If the queried bit is still unset, is it safe and supported to retry the update using the same desired bit values? Are repeated updates that set the bits to their existing values idempotent? Which response, if any, should be treated as confirmation that the write is durable before granting the trial? Our current design fails closed: it does not grant the trial when the write outcome is uncertain. We want to avoid both granting multiple trials and permanently denying an eligible user because of a transient network failure.

I'm building an iOS app (bundle identifier ca.fanforge.pos, Team ID 856C6JT832) that uses a third-party payment SDK to connect to a physical Bluetooth card reader. The SDK requires my app to successfully complete Apple's App Attest process against the production environment before it will allow a real card reader to connect. I have set the entitlement com.apple.developer.devicecheck.appattest-environment to production in my app's entitlements, and I have enabled the App Attest capability on my App ID in the Apple Developer portal. I confirmed directly, by extracting the compiled app binary and running codesign -d --entitlements :- MyApp on it, that the entitlement is present with the value production in the actual signed binary, not just in my source configuration. When I distribute this exact build as an ad-hoc build (a registered test device added to my provisioning profile, not through TestFlight or the App Store), the card reader fails to connect with an error indicating it cannot establish a secure connection to the payment provider's servers. When I distribute the identical app (same version, same entitlements, same provisioning) through TestFlight instead, the card reader connects successfully and I am able to process a real payment. Steps I have already taken to rule out other causes: Verified the payment provider's account credentials are valid and correctly configured for production (confirmed via a direct API call returning a successful response) Verified the App Attest capability is enabled on my App ID in the Apple Developer portal Verified the entitlement value directly in the compiled binary's code signature (not just my source files) Registered the required application signature with the payment provider Fully removed and reinstalled the app between tests Confirmed the reader hardware itself works correctly (it connects successfully in the TestFlight-distributed build) My question: Does ad-hoc distribution have different behavior than documented for the com.apple.developer.devicecheck.appattest-environment entitlement? Apple's documentation states that after distribution through TestFlight, the App Store, or the Apple Developer Enterprise Program, an app automatically uses the production App Attest environment regardless of the entitlement value. It also states that for other distribution methods, the entitlement value itself should directly control which environment is used. My ad-hoc build has the entitlement explicitly set to production, yet its behavior matches what I would expect from the sandbox environment, not production. Expected outcome: I would like to understand whether ad-hoc distribution is expected to correctly honor an explicit production entitlement value for App Attest, or whether there is a known limitation or additional requirement for ad-hoc distribution specifically that isn't covered in the entitlement's documentation.

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

Problem On iOS 27.0 beta (build 24A5430a) ATTrackingManager.requestTrackingAuthorization() completes with the status still .notDetermined and no prompt is ever presented. The ATT system prompt does not appear in any app on the Store. Environment iOS 27.0 beta 8 iPad and iPhone, both affected Country IT Question: Is this expected behavior, or is it a change in the new version of iOS? If it is a change, could you please point me to a reference that documents this? Happy to provide anything further through the Feedback report rather than here.

⚠ It'd be great to get some Apple Dev eyes on this -- it's one of my last remaining issues before submission. Regarding migrating Sign In with Apple users from team PLR8R96VKA to team Y76F338229... I'm following the migration steps at the bottom of https://developer.apple.com/documentation/signinwithapple, in the Transfers Across Teams section. My call to the /auth/usermigrationinfo endpoint results in a 400 error: invalid_request, but my request params all look correct: transfer_sub is set to the the value I got from a successful /auth/usermigrationinfo response. client_id is set to Services ID of the new team's Sign In with Apple service. client_secret was built from the new team's Key ID, Team ID and Services ID. I know it's content and format is valid because it worked fine when calling the /auth/token endpoint. I know my auth token is fine (the one I got from /auth/token)--I'm sure I'd see an auth error if it wasn't. Is there any way I can get more information about what is invalid about the request?

We are evaluating a native iOS feature for Kept, a two-adult daily-connection app, with initial customers physically in the United States using US-region Apple Accounts. Each adult would independently authorize access on their own iPhone and opt in to share daily total screen time and per-app names/minutes with one paired adult through our backend. Each person would preview the same summary their partner receives and could stop sharing or unpair at any time. Neither could configure or enforce restrictions on the other's device. Any app blocking would be separately controlled by the device owner. We do not need message contents, websites visited, or a live activity feed. We have reviewed: DeviceActivityReport, whose extension isolates usage data and prevents networking. DeviceActivityData.activityData(filteredBy:using:), whose documented customer availability is limited to EU devices/accounts, despite broader development testing access. Developer Program License Agreement section 3.3.3 P, which raises a separate question about sharing usage information between adults. Is there a documented, supported API that allows the containing app to obtain and transmit these summaries for US customer installations? If so, which API, minimum OS/SDK, authorization, entitlement, and distribution requirements apply? A local usage report or a threshold notification would not meet the requested summary format. We are at feasibility stage: no native build, entitlement request, or device results yet. We are seeking a supported route rather than an extension-sandbox workaround. If no US route exists, confirmation would help us avoid building against development-only access. Separate agreement/support question For the use case above, does Apple's agreement permit transmitting user-authorized Screen Time measurements to that user's paired adult through our backend? Please clarify how section 3.3.3 P applies and which team can assess this use and any required distribution capability. We understand that individual device-management approval does not by itself establish permission for partner sharing. We have not enrolled in the paid Developer Program yet.

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.

Symptom: the Sign in with Apple sheet renders, Face ID is accepted, then "Sign Up Not Completed". The framework returns com.apple.AuthenticationServices.AuthorizationError code 1001 with an EMPTY userInfo. Nothing ever reaches our server — we have verified zero rows in both our staging and production databases, across every attempt since 22 Aug 2026. Every App ID in our team fails, including a minimal control app: com.anralabs.lifecompass APPLE_ID_AUTH / PRIMARY_APP_CONSENT FAILS com.anralabs.lifecompass.dev APPLE_ID_AUTH / PRIMARY_APP_CONSENT FAILS com.anralabs.signinrepro APPLE_ID_AUTH / PRIMARY_APP_CONSENT FAILS The third is a throwaway app created solely to isolate this: a single view, a single ASAuthorizationAppleIDButton, no networking, no server, no shared code with our product. It was created well after the failures began. It fails identically — 1001, empty userInfo. Variables we have varied, all with the same result: 3 different Apple IDs, including two belonging to different people 3 devices (iPhone 13, 2 different iPhone 17 Pros) both a development build and a TestFlight build of the production bundle fresh install after a full power cycle; the app has NEVER appeared under Settings > Apple Account > Apps Using Apple ID for any Apple ID, because nothing has ever completed Sign in with Apple works normally in third-party apps on the same devices with the same Apple IDs, which rules out the Apple IDs, the devices and 2FA — but not our team's registration, which those apps do not share. Verified correct on our side, via both the developer portal and the App Store Connect API: capability present and enabled on all three App IDs, seedId W4LV5W25SX matching the signing team, com.apple.developer.applesignin = ["Default"] in the signed binary and in the embedded provisioning profile, PLA accepted 22 Aug 2026. We have NOT toggled the capability off and on, regenerated profiles, or recreated App IDs, since other teams in this thread report those steps made no difference and we would rather preserve the current state for inspection. We opened a DTS code-level request on 25 Aug 2026 and have had no substantive response. Given that teams GW7XA5CX69 (31 Jul) and FRL3DTJQ62 (12 Aug) were resolved by a server-side re-registration with no client changes, could our team be added to that queue? Happy to supply an akd log excerpt or a sysdiagnose on request.

We are designing account deletion and token storage for Sign in with Apple across a native iOS flow and a web-based flow used by our Android client. Apple’s documentation describes a successful /auth/revoke request as revoking the user session associated with the supplied token. It also states that the client_id used for revocation must match the client_id used during authorization. We need to understand the documented revocation boundary: whether it is limited to the supplied token or session, or whether it also affects other tokens associated with the same Apple user, client ID, primary app group, or Developer Team. Definitions: A: Our primary App ID. B: A Services ID associated with primary App ID A. C: Another App ID grouped with primary App ID A. D: An App ID in the same Developer Team but belonging to a different primary app group. Assume that the tokens in the questions below belong to the same Apple user. Questions: For a refresh token issued under each of A, B, C, and D, which authorizations or tokens under A, B, C, and D are invalidated by a successful revocation request? Please clarify the result separately for each starting client ID (A, B, C, and D), rather than assuming that the relationship is symmetrical. Please also state whether the result differs depending on whether the identifiers belong to the same primary app group. If multiple refresh tokens have been issued for the same user under the same client_id, does revoking one refresh token invalidate the other refresh tokens, or only the user session associated with the supplied token? If an access token is revoked, is the refresh token from which it was derived also invalidated? Conversely, if a refresh token is revoked, are access tokens derived from it also invalidated? When processing an account deletion request, is revoking one stored token sufficient to remove the user’s complete Sign in with Apple authorization for our Developer Team, or must every refresh token and access token that we have stored be revoked individually? We are asking for the documented behavior that an implementation can safely rely on, rather than behavior observed in a single test. If the only guaranteed scope is the user session associated with the supplied token, please confirm that explicitly.

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 :)

We are seeing a reproducible system-wide input hang when Accessibility permission is revoked from an application that has an active Quartz event tap. The behavior reproduces on macOS Sequoia, Tahoe, and Golden Gate. I have created the standalone diagnostic app(EventTapPassThroughTest) isolates an active Quartz event tap implementation. It creates a session-level event tap for keyboard and mouse events and returns every event unchanged. It does not register for Accessibility-change notifications, suppress events, recreate the tap, or re-enable a tap disabled by macOS. It contains only the following behavior: Requests Accessibility access using AXIsProcessTrustedWithOptions. Creates a session-level, head-insert CGEventTap with .defaultTap. Observes common keyboard and mouse event types. Returns every received CGEvent unchanged with Unmanaged.passUnretained(event). Adds the tap to the main run loop and enables it. It does not suppress or modify events. It does not register for Accessibility-change notifications, recreate the tap, or re-enable a tap disabled by macOS. In both the disable and delete cases, local keyboard and mouse input become unresponsive. A forced restart is required when no remote session is available. The result reproduces even though the event-tap callback always returns the event unchanged. We did not observe a tapDisabledByTimeout or tapDisabledByUserInput callback before input became unresponsive. System logs show TCC modifying or deleting the Accessibility record. WindowServer then checks the running application's kTCCServicePostEvent/kTCCServiceListenEvent access and receives a denied or unknown result. Input subsequently stops being delivered normally. Expected result Revoking the permission should invalidate or disable the application's event tap without affecting system-wide input. If the application is expected to perform cleanup, it should receive a documented notification or tap-disabled callback early enough to disable and invalidate the tap safely. Questions Is revoking Accessibility permission while an active .defaultTap event tap exists expected to be supported? Is there a documented notification that an application can observe before or when its Accessibility/PostEvent access is revoked? Is there a supported way to ensure an existing event tap is safely disabled when the user turns off or deletes the application's permission? Should WindowServer automatically invalidate the tap in this situation?

Hello, Since we enabled App Attest in our production app on Aug 13, 2026, a small subset of users consistently fails attestation with DCError.invalidKey. For multiple confirmed devices the failure appears to be permanent: attestKey rejects even newly generated keys, and reinstalling the app, rebooting the device, or updating the app does not help. Environment Production builds from the App Store, real devices only, production App Attest environment Attestation succeeds for the vast majority of users (about 70,000 keys registered so far) Primary case (user-reported, verified end to end): iPhone XS Max, iOS 17.6.1, region US. 34 invalidKey events since Aug 13; no attestation record on our server; reinstall and reboot did not help Other devices showing the same persistent pattern in our internal logs (each of these reported invalidKey exclusively): iPhone X, iOS 16.7.16: 69 events over 16 days iPhone X (a second device), iOS 16.7.16: 60 events over 17 days iPhone 8, iOS 16.7.16: 12 events over 7 days iPhone XR, iOS 18.7.9: 11 events over 7 days We also see a smaller number of devices failing persistently with unknownSystemFailure instead of invalidKey, for example an iPhone XR on iOS 18.6.2 with 39 events over 15 days In our internal logs, App Attest errors in general appear across a range of iOS versions and devices Implementation flow DCAppAttestService.shared.generateKey attestKey(_:clientDataHash:) with a SHA-256 hash of a server-issued nonce On failure we retry up to 3 times, with backoff intervals of 0.5, 1, and 2 seconds. For DCError.invalidKey, each retry discards the previous key and generates a brand-new key before calling attestKey again; for serverUnavailable we retry with the same key and clientDataHash, per the DCError header guidance Error characteristics For the affected device, all 3 attempts fail with DCError.invalidKey (com.apple.devicecheck.error code 3), even though every attempt uses a newly generated key ID The failure has persisted continuously since Aug 13, 2026 (19 days and ongoing at the time of writing) App reinstall and device reboot do not resolve it, and the failure has persisted across three consecutive app versions Our server has no attestation record for this user at all, so the key has never been successfully attested; this is not a case of a stale or previously attested key being reused The device supports App Attest. For some users of our sibling app in Japan the same error was transient: they hit invalidKey and then attested successfully later, so invalidKey is clearly transient in some cases but appears permanent in others Scale Our internal logs show 478 attestation-failure events from 61 users between Aug 13 and Sep 1, across all DCError codes Of those, at least 298 events from 30 users are invalidKey, roughly 0.01 percent of our active users (about 360,000) What we have ruled out Key reuse: every retry generates a fresh key clientDataHash handling: identical code succeeds for 99.99 percent of users Server-side verification: the failure happens client-side in attestKey, before our server is ever contacted Account state: the affected user is in good standing Questions Under what conditions can attestKey return invalidKey for a freshly generated key? The documentation describes invalidKey as an invalid key identifier, but here the key ID comes directly from a just-completed generateKey call. Is there any known device-side or Apple-server-side state that can cause a specific device to fail attestation persistently (for weeks, across reinstalls and reboots)? If so, is there anything the user or we can do to remediate it? Is there a recommended way to distinguish between a transient failure, a permanent device-level failure, and an Apple-side service issue, or to get more diagnostics for these failures in production? The NSError carries no information beyond the DCError code, which does not seem to differentiate these cases. Is the guidance from earlier threads (for example thread 812308) still current, that is: should we treat a device that persistently fails attestation as if App Attest were unsupported and fall back accordingly? We are hesitant because that fallback becomes an obvious bypass path for bad actors. Could this be related to throttling or rate limiting of attestKey? Our retries are capped at 3 attempts per verification flow, with 0.5 to 2 second backoff. Any insight would be greatly appreciated. Thank you.

We are in the process of transferring our existing Apple account to a new account. We read the documentation and we realized that "Sign in with Apple" users needs to be migrated via API. This API seems to require "sub" which we are not currently storing in our systems. So we are planning to "collect subs" over a period before we can start transfer. I want to make sure we are collecting correct data so I am looking for confirmation from Apple engineers on this. Should we get "sub" from "user" property in ASAuthorizationAppleIDCredential or by decoding identityToken and get "sub" from the token? I think both are same but wanted to double check. Thank you!

The AppTrackingTransparency documentation says: You must use the AppTrackingTransparency framework if your app collects data about end users and shares it with other companies for purposes of tracking across apps and web sites. If I create a unique customer_id value to submit to the GIPHY Actions Register endpoint to track GIFs a user has clicked or sent, does that count as "tracking across apps and web sites"?

Hi, so far i've been using the following API Call Sequence in order to check the keychain status prior to using one of the certificates inside the keychain for signing or verifying remote tls connection. // Step 1: Open keychain SecKeychainRef keychain = nil; OSStatus status = SecKeychainOpen(keychainPath, &keychain); // Result: errSecSuccess (0) — always succeeds, returns valid ref // Step 2: Get keychain status SecKeychainStatus keychainStatus = 0; status = SecKeychainGetStatus(keychain, &keychainStatus); // Result: FAILS : see table below I observed SecKeychainGetStatus return errSecInternalError or errSecInvalidHandle │ Process │ Keychain │ Error │ Code │ │ GUI App │ login.keychain. | errSecInternalError │ -26276 │ │ GUI App │ login.keychain | errSecInvalidHandle │ -25308 │ │ GUI App │ /Library/Keychains/System.keychain | errSecInvalidHandle │ -25308 │ │ Daemon │ /Library/Keychains/System.keychain │ errSecInvalidHandle │ -25308 │ SecKeychainOpen always returns errSecSuccess with a non-null SecKeychainRef SecKeychainGetStatus fails immediately when called on that reference The error for login.keychain varies between calls (not deterministic) The error for System.keychain is consistently errSecInvalidHandle Issue is 100% reproducible. every keychain access attempt fails Started immediately after macOS 26.6.2 upgrade Do you know if there were any changes in 26.6.2 that could have caused this behavior? If this is expected, how should I address it? Thanks

Overview We are investigating repeated "login" Keychain prompts affecting our macOS application on macOS 26.6.x. The issue appears after upgrading an existing installation. A clean uninstall/reinstall of the same version resolves it. Changing the affected Keychain item's Access Control from "Confirm before allowing access" to explicitly allowing our application/process also stops the prompts. On one affected machine, Apple Support observed a securityd crash followed by: SecKeyCreateSignature failed CSSMERR_DL_INVALID_DB_HANDLE Our code uses some legacy SecKeychain* APIs, so we are currently investigating whether this is related. Questions Were there any changes in macOS 26.6.x around securityd, Keychain ACL handling, or legacy SecKeychain* APIs that could explain this? Could an existing Keychain ACL become stale after an application upgrade, even when both versions are signed with the same Developer ID?

Team ID: 2357A78TMR Affected App ID: me.manulorenzo.crossfittracker (App Store Connect app 6760609857) Reproduces identically across every app under this team, on a real device, personal (non-managed) Apple ID with 2FA enabled, persisting for multiple days across device reboots. Symptom matches the documented pattern in developer.apple.com/forums/thread/837986 and /thread/789222: native SIWA sheet renders, biometric/password succeeds, then "Sign Up Not Completed" — no credential ever returned. This matches Apple's own described root cause of an App ID/team never being fully provisioned server-side for Sign in with Apple (AKSQLError -6003 / GSA "Invalid client" / ASAuthorizationError 1001 with empty userInfo). Client-side configuration has been independently verified correct: provisioning profile carries com.apple.developer.applesignin entitlement, App ID capability APPLE_ID_AUTH is configured with PRIMARY_APP_CONSENT, Firebase's apple.com provider has the correct bundle ID registered. Requesting the server-side team registration fix described as the resolution in the linked threads.

Following the pinned post "Gathering required information for troubleshooting Private Email Relay with Sign in with Apple" (thread 794191, which is locked, so I am posting here as instructed): I have filed FB24564316 with the required information. Since 28 July, every message from our app's sending domain to @privaterelay.appleid.com addresses is rejected by iCloud Mail with 554 5.7.1 [HM08], so users who signed up with Sign in with Apple and Hide My Email cannot receive their sign-in emails. Plain-text messages with no URL bounce as well, SPF/DKIM/DMARC pass on two independent sending systems, and external reputation checks are clean, so this looks like a false positive on the sending domain. The feedback contains the App ID (6761705463), Services ID, SMTP error codes and transaction IDs. iCloud postmaster case 21382576 and Developer Support case 20000139732014 did not resolve it. Happy to provide message headers. FB24564316

Sign in with Apple has failed for every user of our app for four weeks. It fails inside Apple's own authorization sheet, before any credential reaches our code. App ID: com.chorestoreapp.app (SJRRC8Q327) Team ID: T4KD7949GL App Apple ID: 6797335710 — TestFlight builds 7 and 8, version 1.0.1 Symptom: The authorization sheet appears and behaves normally. When the fingerprint read is complete, it immediately fails with "Sign Up Not Completed". No credential is returned. When I cancel, it returns ERR_REQUEST_CANCELED, consistent with the sheet being dismissed by the user after being unable to sign in. Sign in with Apple works on the affected device and Apple ID. Downloading an unrelated App Store app and creating a new account with Sign in with Apple succeeded immediately, on the same iPad, with the same Apple ID, minutes before and after a ChoreStore failure. Before that test, Settings → [name] → Sign in with Apple was empty, so the account had never completed the flow — it is demonstrably capable of it now, for other apps. Reproduced with: two Apple IDs, two physical devices, both "Share My Email" and "Hide My Email", Wi-Fi and cellular, and two builds on freshly regenerated credentials. Verified on our side: The signed binary contains com.apple.developer.applesignin = ["Default"] The embedded provisioning profile includes the same entitlement App ID capability, read back from the App Store Connect API: APPLE_ID_AUTH with [{"key":"APPLE_ID_AUTH_APP_CONSENT","options":[{"key":"PRIMARY_APP_CONSENT"}]}] Provisioning profile IOS_APP_STORE, state ACTIVE, expires 2027-08-20 Distribution certificate valid to 2027-08-20 Exactly one bundle ID in the account; no grouped App ID The client call is the standard one, with no nonce or custom parameters: signInAsync({ requestedScopes: [FULL_NAME, EMAIL] }) The distribution certificate and App ID survived an Individual → Organization conversion unchanged (re-verified after the conversion) Why I'm posting rather than filing a code-level request. The request form requires a focused sample Xcode project. A sample cannot demonstrate this: anyone who opens it must sign it with their own team, which changes the App ID — the one variable that is failing. The fault appears to be server-side provisioning for this specific App ID, which no sample can carry. Question: Given the client configuration verifies correct and Sign in with Apple works on the same device and Apple ID for other apps, what would cause the authorization sheet itself to fail for a single App ID, and how can that be investigated or reset? Happy to provide a sysdiagnose, timestamps of specific failed attempts, a screen recording showing the working and failing cases minutes apart, or a TestFlight build.

Feedback Assistant: FB24556583 Please inspect Sign in with Apple server-side registration for Team LQR9X2NWFT / App ID com.kanca.kanca. This is not a client-code or JWT issue. It is blocking App Store review (Guideline 2.1(a)). NATIVE Bundle ID: com.kanca.kanca App Store id: 6804206744 ASAuthorizationController / Flutter sign_in_with_apple. System sheet opens (Hide My Email), Face ID succeeds, then Apple's sheet shows Sign Up Not Completed. No identity token reaches the app. The app does not appear under Settings > Sign in with Apple. Reproduced for days. App Review reproduced it on iPhone 17 Pro Max iOS 26.6 and iPad Air 11-inch M3 iPadOS 26.6. App ID has Sign in with Apple enabled as a primary App ID. Capability re-saved; no change. Same Apple ID completes Sign in with Apple in other teams' apps on the same device. WEB Services ID: com.kanca.kanca.web GET https://appleid.apple.com/auth/authorize?client_id=com.kanca.kanca.web returns invalid_client before any login form (also via curl; no JWT involved). Dummy POST to /auth/token with a valid ES256 client_secret (iss=LQR9X2NWFT, sub=com.kanca.kanca.web, kid=KKYD9GMJS6) and a fake code returns invalid_grant, so the key/JWT/client_id are accepted at the token endpoint. Authorize still reports client not found. Please repair SIWA registration for this team/App ID. Happy to attach a sysdiagnose if needed.