We urgently need a response from the relevant authorities

It appears that we are able to read the currently logged-in Platform SSO user by reading the AltSecurityIdentities field in the dscl repository for the user. However, that seems to be something that could easily be spoofed by just having an external process write a new AltSecurityIdentities value. It also feels "hacky" to just read that value directly from the dscl repository for this purpose. Our application would like to read the user that is logged in to Platform SSO so we can report it up to our security service as the "device logged in user". Is there an API-based approach to retrieving the true user that is logged in via Platform SSO from within the context of my application?

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!

Hi, Feedback ID - FB24176019 I am investigating a Sign in with Apple issue affecting my production application and would appreciate guidance on what Apple may be rejecting during the token exchange. The authorization stage succeeds and Apple returns an authorization code to our callback. The failure occurs when the authorization code is exchanged at: https://appleid.apple.com/auth/token The production OAuth implementation uses Better Auth 1.6.13. Apple configuration: Primary App ID / Bundle ID: com.whatsupplier.uk Services ID / client_id: com.whatsupplier.uk.signin Registered return URL: https://www.whatsupp.uk/api/auth/callback/apple We have checked the client secret JWT and confirmed: alg = ES256 kid matches the active Apple key iss matches our Apple Team ID sub = com.whatsupplier.uk.signin aud = https://appleid.apple.com iat/exp are valid the JWT signature verifies locally against the configured Apple private key the signature is P1363/raw r||s rather than ASN.1 DER the private key is EC / prime256v1 the redirect_uri exactly matches the registered return URL the token request uses application/x-www-form-urlencoded The unusual behaviour is reproducible: The real Better Auth token exchange reaches Apple's /auth/token endpoint but Apple responds: HTTP 400 error: invalid_client We created a diagnostic request directly to the same Apple token endpoint using the same configured credentials and a deliberately invalid authorization code. Apple responds: HTTP 400 error: invalid_grant "The code has expired or has been revoked." This indicates Apple accepts the client credentials/JWT in the direct request and proceeds as far as validating the authorization code. We also performed an A/B test using the exact same generated client-secret JWT: Test A: grant_type code redirect_uri client_id client_secret Result: invalid_grant Test B: grant_type code redirect_uri client_id client_secret code_verifier Result: invalid_grant Therefore code_verifier alone does not change Apple's classification. We then captured the observable shape of the real Better Auth token request and compared it with a direct request. The client_id, redirect_uri, grant_type, client-secret JWT claims, URLSearchParams/form encoding and absence of an Authorization header were consistent. Despite this, the real framework-generated exchange returns invalid_client while the direct diagnostic request is accepted at the client-authentication stage and returns invalid_grant. Could Apple advise what additional property of the token request could cause this difference in classification? In particular, is there any server-side state or request characteristic used by Sign in with Apple that could cause an otherwise valid client_secret to be classified as invalid_client only during the real authorization-code exchange? I have also prepared detailed diagnostic evidence and can submit the requested sensitive request information through Feedback Assistant rather than posting JWTs, authorization codes, or other credentials publicly. 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.

Hi, we are currently investigating an issue with Kerberos support in one of our apps. The apps are deployed as managed apps via MDM, together with the new extensible SSO Kerberos profile. In this scenario, Ivanti EPMM is used as MDM, and the extensible SSO configuration has placeholders for the actual user principal name that get filled with the users actual information from our directory. In general, the setup works fine, the Kerberos tickets are requested and supplied to the device, and the SSO extension is providing them to the service. However, in our test MDM environment we enroll i.e. iPad test devices with different test users from our directory and change those users during testing to switch between defined personas. We observed that the credentials acquired by the Kerberos SSO extension dialogue persist even after MDM unenrollment, and even after a device reset. Even if we enroll back to MDM with another user, the previous principal name shows in the SSO extension dialogue and cannot be changed. To us, this seems like a design issue. We use same Apple ID when running these tests, so I suspect that the credential caching could be at Keychain level. Regardless of where they are cached, since the configuration was a managed one, I would expect it to clear the credentials after unenrollment and at least after a device reset. We found some article regarding macOS on the internet, which seems to go into a similar direction however the author states that the credentials could be removed with MDM removal. https://automatica.com.au/2026/01/remove-additional-platform-single-sign-on-credentials-saved-in-macos-when-using-psso-with-microsoft-365-entra-and-company-portal/ Question: How are we supposed to get Kerberos SSO credentials cleared on iOS devices? Is this a known issue, or something that does not work as designed?

Dear Apple Developer Support, We are currently encountering a recurring issue with the DeviceCheck API across multiple devices in our production environment. The following error is frequently returned: com.apple.devicecheck.error 0 We would like to ask the following: What are the possible underlying causes that could lead to this specific error code (0) in the DeviceCheck API? Is there any known behavior or condition where Wi-Fi network configurations (e.g., DNS filtering, proxy settings, captive portals) could result in this error? Are there known timeouts, connectivity expectations, or TLS-level requirements that the DeviceCheck API enforces which could fail silently under certain network conditions? Is this error ever triggered locally (e.g., client library-level issues) or is it always from a failed communication with Apple’s servers? Any technical clarification, documentation, or internal insight into this error code would be greatly appreciated. This would help us significantly narrow down root causes and better support our users

Hi, We are looking for guidance on synchronizing a user’s login keychain passphrase after changing that user’s local account password, when the user is not currently logged in. Context We have an MDM product for macOS, and we sometimes need to change a local account password while that user is not logged in. Updating the account password itself from our privileged daemon is fine. The hard part is keeping their login keychain in sync — that only seems to work when we run as that user, in their own session. So we perform the keychain update from a per-user LaunchAgent, not from root. What works (user is logged in) From the user’s LaunchAgent we run: # 1) Change account password (if not already changed) dscl . -passwd "/Users/<username>" "<currentPassword>" "<newPassword>" # 2) Sync login keychain passphrase security set-keychain-password -o "<currentPassword>" -p "<newPassword>" login.keychain-db With correct current/new secrets, this succeeds when the helper is running as that user while they are logged in. What fails (user is not logged in) Starting the same LaunchAgent for that user fails with: Bootstrap failed: 125: Domain does not support specified action So we cannot get user-context execution for the keychain update while the user is not logged in. Approaches we already tried Post-login LaunchAgent — We stage the current/new passwords and install a LaunchAgent that runs after the user logs in to migrate the keychain. By the time the user is logged in and the agent runs, macOS has already created a new login keychain and renamed the previous one (e.g. login.keychain-db-renamed-N). At that point we can no longer reliably migrate/restore the original keychain. sudo -u <username> security set-keychain-password … from a root daemon — Led to Keychain Access / keychain state corruption in our testing; we do not consider this a production path. Delete the login keychain — Works as a reset, but discards saved credentials. Acceptable for some admin reset flows; not acceptable for a password change where we know both secrets and want to preserve the keychain. Ask Is there a supported way to update login.keychain-db for a user who is not logged in, given known current and new passphrases, without deleting the keychain? If so, what is that way? If not is there a way to merge the old login keychain as we have the old password too? Also please confirm whether updating another user’s login keychain from root / sudo -u is unsupported, so we can exclude it from product design. Happy to provide sanitized logs (error 125, security failures, renamed keychain timelines) if useful. Thanks.

Trying to find the best place to get guidance from Apple on this issue. Apple support has suggested this Forum. We are trying to get our BIMI to show in iOS devices but so far in the inbox it does not show. But the email header indicates all is good, BIMI=pass. Not sure where to turn to next. My ticket is 20000127527288 with Apple support. But where to get appropriate feedback on our issue is what I'm looking for guidance.

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

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

In order to use Sign in with Apple, I issued a JWT client according to the instructions and was able to connect without any problems, but suddenly an INVALID_CLIENT error started to occur. The error was resolved by re-obtaining the JWT client token and resetting it. The validity period of the JWT client token is 6 months and it has not expired yet, but I would like to know why I am getting an INVALID_CLIENT error.

I am looking for help diagnosing a Sign in with Apple failure that occurs after Face ID and before a credential is returned. Environment iPhone 15 Pro iOS 26.2 Xcode 26.3 TestFlight distribution builds Team ID 42U……D944 Bundle IDs com.vybers.vybers-ios com.vybers.vybers Reproduction Install the app from TestFlight. Tap Sign in with Apple. Complete Face ID. Face ID succeeds but the authorization sheet reports that registration could not be completed. The app receives no ASAuthorizationAppleIDCredential and no identityToken. The same behavior occurs Across multiple builds. On multiple physical devices. With multiple Apple IDs. In both Bundle IDs belonging to the same team. In Apple's official Juice sample app using the official Sign in with Apple flow. Control experiment The same iPhone successfully signs in with Apple in a newly downloaded unrelated App Store app. The relevant device log captured immediately after the failure includes Apple server response HTTP 200 AppleIDAuthSupport setError 2M2 missing bad password SRP authentication with server failed AKRemoteViewController did complete with authorization null AKAuthenticationServerError Code=-24000 The “bad password” text is confusing but the Apple ID works in unrelated apps and the failure happens after successful Face ID. The application server is never contacted because no credential or identityToken is produced. Could this be caused by a team-scoped Sign in with Apple/AuthKit registration or synchronization problem rather than by the client implementation or server-side token verification In particular I would appreciate guidance on Checking the Sign in with Apple registration for the team. Checking whether multiple client IDs in one team can become stale or out of sync. Whether an individual Developer Program membership changes any requirement for this flow. Which diagnostic information Apple needs to investigate the AuthKit backend response. I can provide the full Team ID build details signing entitlements and a sysdiagnose through a private support case.

Hello, We already have an existing iOS app on this Apple Developer team that successfully uses Sign in with Apple. However, Sign in with Apple consistently fails for our second and newer App ID, com.siremo.flare, before any Apple credential or identity token is returned. Both apps belong to the same Apple Developer team and have equivalent Sign in with Apple configurations. App information: Affected app: Flare Affected Bundle ID: com.siremo.flare Working existing Bundle ID: com.siremo.aily Team ID: JYGN9K53XA Distribution: iOS Simulator and TestFlight TestFlight build: 0.2.3 (2) Developer Support case: 102947765951 Symptoms: In the iOS Simulator, the Sign in with Apple sheet becomes unresponsive after entering the Apple ID password. In TestFlight on physical devices, the system sheet displays “Sign Up Not Completed”. No Apple credential or identity token is returned to the app. Firebase Authentication and our backend authentication code are never reached. Console output from a reproduction using Apple’s native SwiftUI SignInWithAppleButton: Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.siremo.flare} ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)" The user did not cancel the authorization request. What we have verified: Sign in with Apple is enabled for com.siremo.flare in Certificates, Identifiers & Profiles. Apple Developer Support confirmed that Sign in with Apple is enabled for this App ID under case 102947765951. We removed and re-added the Sign in with Apple capability in Xcode and the Developer Portal. We regenerated the provisioning profile, created a new Archive, and distributed a new TestFlight build. The issue persists. We inspected the entitlements embedded in the actual archived Flare app: application-identifier = JYGN9K53XA.com.siremo.flare com.apple.developer.applesignin = [Default] The embedded provisioning profile contains the same application identifier and Sign in with Apple entitlement. The issue reproduces with multiple Apple ID accounts and multiple physical devices. Flare is our second app and newer App ID on this Apple Developer team. Our existing app, com.siremo.aily, successfully completes Sign in with Apple using: the same Apple Developer team the same physical device the same Apple ID an equivalent native Sign in with Apple implementation an equivalent entitlement and provisioning configuration Only the newer App ID, com.siremo.flare, fails with AKAuthenticationError -7003 and AuthorizationError 1001. We reproduced the same failure using Apple’s native SwiftUI SignInWithAppleButton. This rules out our custom ASAuthorizationController delegate, controller retention, presentation-anchor implementation, and custom button implementation. Our diagnostic logging confirms that the failure occurs before the Apple authorization callback succeeds and before an identity token is issued. Firebase Authentication and our backend are downstream of this callback and are therefore not involved in the failure. The combination of: AKAuthenticationError -7003 AKClientBundleID=com.siremo.flare AuthorizationError 1001 without a user cancellation the “Sign Up Not Completed” system message an existing App ID on the same team working correctly only the second and newer App ID failing the failure reproducing with Apple’s native SignInWithAppleButton appears similar to other reports where existing App IDs continue to work while newly registered App IDs fail, despite having valid Sign in with Apple capabilities, entitlements, and provisioning profiles. Could an Apple engineer please compare the server-side Sign in with Apple registration state of: Working: JYGN9K53XA.com.siremo.aily Failing: JYGN9K53XA.com.siremo.flare and verify whether the newer App ID was correctly registered and propagated in the Sign in with Apple backend? If the registration is incomplete, stuck, or inconsistent, could it be repaired or re-provisioned on Apple’s side? We can provide reproduction timestamps, Archive entitlement dumps, provisioning profile details, screenshots, and additional diagnostic logs if needed. Thank you.

iPadOS 27.0 developer beta not auto-dismissing "Use security key" system popup after authentication. iPadOS 26.6 did not require the user to "X" the popup after auth. I restored to iPadOS 26.6 on same device which seems to confirm that it is iPadOS 27.0 developer beta related. Is this a known issue in the 27 betas, or an intended behaviour change to remote authorization UI dismissal that apps should adapt to? Thank you for any info you might share on this.

Hi all, I tried to implement Apple Login in my Expo App for iOS (as I also want to use Google login and Apple makes Apple login mandatory in this case). But I always get an error when I try to sign in. Problem Sign in with Apple never completes. The system sheet appears, the user taps "Continue", then the sheet shows "Sign up not completed" and the API returns: ASAuthorizationError with message "The user canceled the authorization attempt" (no error code is provided; the error object is otherwise empty) This happens on every attempt, with no user cancellation involved. What I have already verified App ID capability: APPLE_ID_AUTH is enabled with setting APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (verified via App Store Connect API and visible as enabled in the Developer Portal UI). Provisioning profile: freshly generated AFTER enabling the capability. Decoded profile contains: com.apple.developer.applesigninDefault Signed binary: I downloaded the built IPA and inspected it. codesign -d --entitlements shows: com.apple.developer.applesignin = ["Default"] The embedded.mobileprovision inside the IPA is the newly generated one. No app extensions: the IPA contains no PlugIns directory, so there is no bundled extension missing the entitlement. Not account-specific: reproduced with two different Apple IDs (both with two-factor authentication enabled). Not bundle-ID or distribution-specific: reproduced with both com.enplace.app.dev (Ad Hoc) and com.enplace.recipes (App Store build distributed via TestFlight). No stale authorization: Settings > Apple Account > Sign in with Apple lists no entry for this app. Agreements: "Free Apps" agreement is active. Expected signInAsync() returns a credential with an identityToken. Actual Promise rejects with "The user canceled the authorization attempt" without any user cancellation, on every attempt, on all tested configurations. Environment Device: iPhone SE (Touch ID), iOS 26.5.2 Framework: React Native / Expo SDK 56 with expo-apple-authentication (wraps ASAuthorizationController; no custom native code involved) The app bundles no app extensions Capability was enabled on 2026-07-28; still failing on 2026-07-29 Has anyone found the actual cause for this? Several older threads describe the same symptom, but none of them ends with a resolution.

Our app can no longer complete native Sign in with Apple: the system sheet appears, the user authenticates (Face ID / password succeeds), and the sheet then fails before any credential is returned to the app. Console shows AKAuthenticationError -7003 from the AppleAccount/AuthorizationServices stack. Details: App: "Antes y Después: Fotos" — bundle ID com.jpbaldi.antesydespues, live on the App Store Team ID: PZDWZHXF9V (individual membership) Implementation: ASAuthorizationController (via expo-apple-authentication), scopes full name + email; the identityToken is exchanged with our backend (Supabase). The failure happens inside the native sheet, before any token is issued. Reproducible across devices, networks and Apple IDs — and App Review reproduced it too: our build was rejected under 2.1(a) because the reviewer hit the same failure. It does not look device- or account-specific. What we've already tried, with no change: Removed and re-added the Sign in with Apple capability on the App ID in Certificates, Identifiers & Profiles, regenerated provisioning profiles, rebuilt and resubmitted. Verified com.apple.developer.applesignin (Default) is present in the shipped binary's entitlements. Fresh devices, different Apple IDs, different networks. As a workaround we shipped v1.0 with Sign in with Apple disabled (email/password only), so guideline 4.8 doesn't apply — but we want to restore it. Since -7003 appears to be returned server-side for our client ID rather than by anything in the app, is there any account-side registration state for the App ID that can be checked or reset? Has anyone resolved this exact error without creating a new App ID (not viable for a shipped app)? Feedback Assistant: FB23890204 (sysdiagnose + screen recording attached) Developer Support case ref: 102944296016

macOS 27.0 beta 4 I have an installer app which needs to set a key/value inside a plist file during installation. This is for a screensaver that runs under the legacyScreensaver system, so the plist lives at: ~/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver.x86-64/Data/Library/Preferences/com.foobar.plist Although I can see the plist file in the Finder, my installer app can't read or write it, and the NSAppDataUsageDescription string is not shown, nor does the OS ask the user for permission. Also, trying to do this via the Terminal app is also blocked (even using 'sudo'). I understand this is part of the new Golden Gate security system. In Golden Gate, is there a legitimate way to accomplish this so it works like it did in macOS 26 and earlier? I'd like my installer to request access, the NSAppDataUsageDescription string is shown, and the user can grant or deny permission.

Hi everyone, I am working on an iOS application that utilizes a Broadcast Upload Extension (ReplayKit) to perform local, on-device screen analysis. Currently, we are using RPSystemBroadcastPickerView to allow the user to initiate the broadcast session. However, for our specific tracking use case, requiring the user to manually tap the "Start Broadcast" button every time creates a significant friction point in the user experience. My questions are: Is there any private API, entitlement, or MDM (Mobile Device Management) configuration that allows an app to programmatically start a ReplayKit screen recording session completely in the background without explicit human intervention (e.g., without tapping a button in the UI)? If this is strictly prohibited for consumer apps on the App Store due to privacy guidelines, are there any exceptions or enterprise-level profiles available for supervised devices that bypass the mandatory RPSystemBroadcastPickerView user interaction? My understanding is that Apple enforces this manual trigger and the red status bar indicator for strict security and privacy reasons, but I am looking for an official confirmation on whether any programmatic workaround exists for this in modern iOS versions (iOS 15+). Thank you in advance for your time and clarification!

App: Subio - Quản lý đăng ký Bundle ID: io.ausynclab.subio Team ID: DMB7A87LM9 App Store Connect App ID: 6785710632 SUMMARY Sign in with Apple in our app consistently fails during the account-creation flow with the system error "Sign-Up Not Completed" (shown by iOS's own native AuthenticationServices UI, before any of our app code runs). This has caused App Review to reject our app 5+ times over the past week (builds 16, 17, 19, 20, 21, 22), each citing Guideline 2.1(a) with this exact error. KEY EVIDENCE THIS IS SERVER-SIDE, NOT APP-SIDE The failure reproduces for TWO COMPLETELY INDEPENDENT Apple ID accounts: Our own developer test account (used repeatedly since build 16) Apple App Review's own test account/device (different devices each time: iPad Air 11" M3, iPad Air 11" M4, iPhone 17 Pro Max — running iPadOS 26.5.2 and iOS 27.0) Two unrelated accounts hitting the identical failure strongly suggests the issue is in our app's Sign-In-With-Apple server-side registration (tied to our Team ID/Bundle ID), not any individual user's account state. Our backend receives ZERO HTTP requests at the moment of failure, confirmed via server-side logging. This proves the failure occurs entirely within iOS's native account-creation sheet, before our JavaScript code (or the identityToken) is ever produced. TROUBLESHOOTING ALREADY COMPLETED (to save engineering time) We have verified all of the following are correctly configured, and the issue persists regardless: Bundle ID capability: APPLE_ID_AUTH is enabled with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (confirmed via App Store Connect API) Provisioning profile: App Store distribution type, contains com.apple.developer.applesignin entitlement (Default), correct Team ID Signing certificate: valid iOS Distribution cert, serial number matches the certificate linked to the provisioning profile in App Store Connect Entitlements embedded in the actual signed, submitted binary (extracted directly from the .ipa and inspected with codesign -d --entitlements) match expectations exactly Tried requesting full scopes (FULL_NAME + EMAIL), reduced scopes (FULL_NAME only), and zero scopes at all (requestedScopes: []) — the failure is identical in all three configurations Added a guard to prevent concurrent/duplicate calls to signInAsync() (in case of rapid double-taps) — failure persists Confirmed the failure occurs both when the button is presented inside a React Native Modal and when presented on a plain (non-modal) screen — ruling out a presentation-context conflict WHAT WE'D LIKE APPLE'S HELP WITH Please check, on your side, whether there is a stuck, incomplete, or corrupted Sign-In-With-Apple account-linking record associated with Bundle ID io.ausynclab.subio / Team ID DMB7A87LM9 that could be causing account-creation requests to fail at the server level. We are happy to provide additional logs, device details, or a screen recording if useful. We would greatly appreciate guidance, as this is blocking our very first App Store submission and we've been unable to identify anything further to fix from the client side. Thank you for your time.