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"

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 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.

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.

Our macOS app makes an URLRequest (via URLSession) to an HTTP(S) server on the local network (a device at a private IP address, e.g. 192.168.x.x). The request fails with NSURLErrorNotConnectedToInternet (-1009) whose underlying error resolves to ENETDOWN (POSIX errno 50) at the socket/connection level — i.e. the failure happens before any TLS/HTTP exchange, at connect() time. This only reproduces on macOS 27 "Golden Gate" Public Beta. The exact same build/binary works correctly on: macOS 26 "Tahoe" (shipping release) macOS 27 "Golden Gate" Developer Beta Based on our diagnosis, we believe the Local Network permission prompt itself is never firing for direct-IP (non-Bonjour) connections on this Public Beta build, leaving the app's Local Network TCC grant permanently stuck in an "undetermined" state — which then surfaces as ENETDOWN. This is consistent with the app not appearing at all in System Settings → Privacy & Security → Local Network, and with tccutil reset LocalNetwork failing both per-app and system-wide (there's no grant to reset in the first place). We'd like a sanity check / to know if others are seeing this, and whether there's a known workaround. Environment App: com.example.Client, non-sandboxed Target: https://:/api/... macOS versions tested: macOS 26 Tahoe — OK; macOS 27 Golden Gate Developer Beta — OK; macOS 27 Golden Gate Public Beta (build: 26A5388g) — fails Mac model: Mac mini Xcode version used to build: 27 beta 2 Error details URLSession completion error: Error Domain=NSURLErrorDomain Code=-1009 "..." UserInfo={ _kCFStreamErrorCodeKey=50, NSUnderlyingError=0x... { Error Domain=kCFErrorDomainCFNetwork Code=-1009 UserInfo={ _NSURLErrorNWPathKey=..., _kCFStreamErrorCodeKey=50, _kCFStreamErrorDomainKey=1 } }, ... } _kCFStreamErrorDomainKey=1 is kCFStreamErrorDomainPOSIX, and code 50 is ENETDOWN. Console log for the same request shows the failure at the connection layer, before any TLS/HTTP activity: Connection 1: received failure notification Connection 1: failed to connect 1:50, reason -1 Connection 1: encountered error(1:50) Task <...>.<1> HTTP load failed, 0/0 bytes (error code: -1009 [1:50]) What we've ruled out / tried Added NSLocalNetworkUsageDescription to Info.plist — no change in behavior. Confirmed via codesign -d --entitlements - and plutil -p Info.plist that the built/signed app bundle actually contains the key. Checked System Settings → Privacy & Security → Local Network — the app itself does not even appear in the list. Tried resetting the Local Network TCC grant: sudo tccutil reset LocalNetwork com.example.Client → tccutil: Failed to reset LocalNetwork approval status for com.example.Client Also tried a full reset for the service (no bundle id): sudo tccutil reset LocalNetwork → tccutil: Failed to reset LocalNetwork Confirmed tccutil itself is functioning normally on this machine — resetting other services succeeds, e.g.: sudo tccutil reset Camera → Successfully reset Camera So tccutil works in general, but the LocalNetwork service specifically cannot be reset, on this Public Beta build, either per-app or system-wide. Question for the forum Is there a known change/regression on the Golden Gate Public Beta where the Local Network permission prompt doesn't fire for direct-IP connections that don't go through Bonjour/NWBrowser? (The same code works fine on the Developer Beta.) Has anyone else seen tccutil reset LocalNetwork fail (while other services reset fine) specifically on the macOS 27 Golden Gate Public Beta? Any known workaround short of downgrading — e.g. restructuring the connection to use Bonjour/NWBrowser instead of a direct IP connection, or some way to explicitly trigger the permission prompt? We're also planning to file this via Feedback Assistant with a full sysdiagnose, but wanted to check here first in case this is already a known/tracked issue or someone has a workaround. Thanks in advance.

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

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.

Sign in with Apple consistently fails with the sheet error "Sign up not completed" for every user and device we have tested. The authorization sheet presents correctly (name/email choices are shown); the failure happens on completion, so no credential is returned to the app. We have eliminated all client-side and account-side causes and believe this is a server-side registration issue with our App ID, matching previously reported cases that were ultimately fixed on Apple's side (forums threads 716252, 122458, 750633). App details: Team ID: Q7BH7CYU67 Client ID (Bundle ID): com.hohomom.baby (App ID resource id RN35DS29UD) Native flow: ASAuthorizationController identity token verified via Firebase signInWithCredential; audience = the bundle ID (no web Services ID involved) Distribution: TestFlight (external), build 1.0 (1784386654) Feedback Assistant report (with sysdiagnose + akd log): FB23839922 Developer Support case: 102946147992 What we verified (all pass): Delivered IPA binary entitlements: com.apple.developer.applesignin = [Default] (via codesign -d --entitlements). Embedded provisioning profile carries the same entitlement (via security cms -D). Signed with a fresh App Store profile created after a capability reset. Developer portal: App ID has APPLE_ID_AUTH enabled as primary (APPLE_ID_AUTH_APP_CONSENT: PRIMARY_APP_CONSENT). We also disabled/re-enabled the capability and rebuilt — no change. Every embedded target now has the entitlement too — we found and fixed a bundled Controls app-extension (com.hohomom.baby.Controls) that was missing the Sign in with Apple entitlement, added it, rebuilt and re-uploaded. Still fails. App Store Connect: no pending agreements. Apple System Status: Sign in with Apple operational at test time. The tester's Apple ID and device are fine: Sign in with Apple works in third-party apps from other teams on the same device. Device-side: rebooted the iPhone and retried on both Wi-Fi and LTE — same failure. Device log evidence (log collect during a failed attempt): at the moment of the attempt, a freshly spawned akd repeatedly fails to fetch the GrandSlam configuration: akd [com.apple.authkit:core] Bag fetch failed! Error Domain=NSURLErrorDomain Code=-1008 URL: https://gsa.apple.com/grandslam/GsService2/lookup/v2 (x4 consecutive) Could an Apple engineer please check the server-side Sign in with Apple registration state for Team Q7BH7CYU67 / com.hohomom.baby and repair or re-provision it? Full details, the affected Apple ID email, and a sysdiagnose are in FB23839922. This is currently blocking our App Store submission (guideline 4.8). 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.

Hi everyone, I'm integrating WeatherKit into an app for users in Mainland China, and I have a data residency question I haven't been able to resolve from the documentation. To fetch weather data, the app sends the user's precise latitude/longitude to WeatherKit. Under China's Personal Information Protection Law (PIPL), precise geolocation is personal information, and cross-border transfers are strictly regulated — so I need to understand where this data actually goes. While testing on Android (REST API), I captured the outbound request and it connected to an IP that appears to be located in Mainland China. That's encouraging, but a single edge/CDN IP doesn't prove the data stays in-country — it could still be forwarded to or accessed from servers outside Mainland China. My questions: When a request originates from Mainland China, does WeatherKit process and store the latitude/longitude within Mainland China, or is it transferred/accessible outside? Does WeatherKit have a data localization deployment for Mainland China (similar to how iCloud is operated locally there)? Is there any official documentation on WeatherKit's data residency and request logging (IP, coordinates, retention period)? If anyone from Apple or the community has insight — or can point me to the right documentation — I'd really appreciate it. Thanks!

Hi everyone, We're migrating our iOS app from Auth0 custom scheme callbacks to HTTPS Universal URLs using ASWebAuthenticationSession. We've configured everything correctly, but webcredentials only works when using ?mode=developer suffix in our entitlements, which is not allowed for App Store submissions. The Issue Without ?mode=developer: Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=1 "Application with identifier com.example.myapp is not associated with domain auth.example.com. Using HTTPS callbacks requires Associated Domains using the webcredentials service type for auth.example.com." With ?mode=developer: webcredentials:auth.example.com?mode=developer Works perfectly! Questions Why does it work with ?mode=developer but not without it, even though Apple's CDN has the correct AASA? Is there a way to force iOS to re-verify associated domains without requiring users to delete and reinstall? How will this affect existing users who update the app? Will they need to reinstall? Is there a known propagation delay beyond the CDN showing correct data? Any guidance would be greatly appreciated. We cannot ship to the App Store with ?mode=developer, but without it, the authentication fails. Thank you!

Hi all, I just enabled Sign in with Apple for my app for the first time. The app is built with FlutterFlow using its native Authenticate with Apple action. When I tap Sign in with Apple, nothing happens: the Apple authorization sheet never appears. To investigate further, I created a custom action that directly calls: SignInWithApple.getAppleIDCredential(...) and catches any exception. It consistently returns: SignInWithAppleAuthorizationException( AuthorizationErrorCode.unknown, The operation couldn't be completed. (Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1000) ) The app is distributed through TestFlight and the issue occurs on a real device. I'm wondering whether anyone has experienced the same behavior after enabling Sign in with Apple on a new App ID. If so: Did the issue resolve itself after some time? Was there any Apple-side propagation delay involved? Or was there an additional FlutterFlow or Apple Developer configuration that I might be missing? What I've already verified ✅ Sign in with Apple capability is enabled on the App ID. ✅ Distribution certificate is valid. ✅ Provisioning profile was regenerated after enabling the capability and lists Sign in with Apple under Enabled Capabilities. ✅ Firebase Authentication has the Apple provider enabled. ✅ Google Sign-In works correctly in the same TestFlight build. ✅ Tested only on a physical device via TestFlight. ✅ Rebuilt and redeployed the app from FlutterFlow after every configuration change. ✅ Disabled Firebase App Check enforcement for Authentication as a test (no change). Any suggestions or similar experiences would be greatly appreciated.

We are evaluating using the WeatherKit REST API for our app in Mainland China. To ensure compliance with local data protection regulations (such as PIPL / Data Security Law), we need to clarify how location data (latitude and longitude) is routed and stored during WeatherKit API calls. Could someone from Apple or the community clarify the following two questions regarding WeatherKit API calls made within Mainland China: When our server queries the WeatherKit REST API using a location's latitude and longitude from Mainland China, is this coordinate data routed to/processed on servers located outside Mainland China? Data Storage (At-rest): Does Apple store or log these queried coordinates on servers located outside Mainland China? Any official documentation, guidelines, or insights regarding WeatherKit's infrastructure setup for Mainland China would be greatly appreciated.

We have an application (macOS) which opens an ASWebAuthenticationSession window to prompt the user for credentials. This works well, except for there are times when the window is opened behind other windows - and the user does not see that they are being prompted for authentication. Is there some way to force this window to be always-on-top or at the very least, to bring it to the foreground on top of other windows (including other browser windows from the same default system browser).