Summary: invalid_client on a Services ID whose portal configuration is complete and correct, AND the same team's native App ID cannot be revoked from the iOS Settings UI ("Stop authorisation has failed - Invalid client"). Both started on 17 July 2026. Sign in with Apple on this App ID worked normally earlier the same day. Team ID: 8ASV5HF9RR Primary App ID: co.uk.2point45.calendarapp Services ID: co.uk.2point45.web Issue 1 (web): a request to the authorize endpoint with client_id set to the Services ID and redirect_uri set to a registered Return URL returns invalid_client. This reproduces with plain curl - no browser, no JS SDK, no popup, no scope, no nonce. The minimal request (response_type=code, response_mode=query) fails identically, so no application code is involved. Issue 2 (native): Settings > Apple Account > Sign in with Apple > [the app] > Stop using Apple ID returns "Stop authorisation has failed - Invalid client". This is the Settings app failing against the Sign in with Apple backend for the native App ID, with no third-party code in the path. sysdiagnose attached to the Feedback, captured with the Accounts/AuthKit profile installed. Already verified, so please don't return these as the cause: App ID has Sign in with Apple enabled and is set to "Enable as a primary App ID" Services ID has Sign in with Apple enabled, grouped to that primary App ID, with 6 Website URLs attached client_id is the Services ID, not the App ID redirect_uri is a character-for-character match of a registered Return URL Domains registered without a scheme; Return URLs registered with https TLS 1.2+ on all domains No domain association file uploaded, per the documentation ("You don't need to upload a file on your server to complete the registration process for domains and subdomains") Not applicable: no client secret JWT, refresh token or access token can be supplied, because this integration never calls the token endpoint. It uses Sign in with Apple JS with response_type=code id_token and verifies the returned id_token against the published JWKS. The failure is at the authorize endpoint, before any token exchange. The only portal changes between working and failing were: (1) creating the Services ID and selecting the App ID above as its Primary App ID, and (2) renaming the App ID's Description from the Xcode-generated default. No capabilities were changed.

Hi Everyone I’m using an iPhone running the latest version of iOS with a physical team after enabling lockdown mode. I have noticed what appears to be unusual issued. 1: wi-Fi works normally. 2: outgoing cellular calls fail wit “call failed.” 3: shortly after the status bar changes to “no service.” 4: I still receive SMS notifications from my courier informing me of missed calls. I’ve already: . Nothing nice. updated to the latest iOS. . Restarted the iPhone. . Confirm that Wi-Fi is functioning normally. From Apple‘s documentation, I understand that lockdown mode is intended to harden the device against sophisticated cyber rates. I should not normally disable voice call service as everyone else experience this after enabling lockdown mode? If so: Which iPhone model are you using? Which iOS version? Which carrie? Did you find a solution? I’m also interested in knowing whether Apple is aware of this as a potential software bug or whether it could be related to a carrier compatibility issue. Thank you

Sign in with Apple works correctly on a physical iPhone in my Capacitor-based app, but fails in the Simulator, and this appears to be causing repeated App Store review rejections. I'm trying to figure out how to get past review.... What happens On a physical iPhone, Sign in with Apple works as expected. In the Simulator, if the user signs into their Apple ID (Settings) and returns to the app, tapping "Sign up with Apple" fails immediately with: The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError error 1000.) (Screenshot attached.) The native Apple sheet never appears — the error returns right away. The actual problem Every time I submit to App Store review, the app gets rejected because Sign in with Apple fails for the reviewer — I believe they're testing in an environment (Simulator, or a device not signed into iCloud) where it returns error 1000. It works on real hardware, so I keep getting stuck in a review loop over something I can't reproduce on device. What I've already checked Sign In with Apple capability is present in Signing & Capabilities for both Debug and Release, and the entitlement is in the built product. The App ID has Sign In with Apple enabled in the Developer portal, and the Services ID / return URLs are configured for Clerk. Resolved an earlier iPad-specific issue where connectedScenes was empty (added a UIApplicationSceneManifest + AppDelegate.window fallback), so ASAuthorizationController now has a valid presentation anchor. Questions Is error 1000 (ASAuthorizationError.unknown) in the Simulator a known environment issue (e.g. no usable Apple ID for the authorization flow) rather than an app bug — given it works on physical devices? For anyone who has been rejected because Sign in with Apple failed in the reviewer's environment: what actually got you through review? Reviewer notes explaining it works on device? Replying in Resolution Center with a screen recording from a real device? Something else? Any guidance appreciated — I'd rather fix the root cause than keep resubmitting.

Hello Apple Developer Team, I am developing a general-purpose web browser for iOS using WKWebView. Current status: • The app is distributed through TestFlight (Internal Testing). • The app is registered in App Store Connect. • The browser supports standard web browsing with multiple tabs and arbitrary websites. My goal is to support WebAuthn passkey authentication for websites such as Google, GitHub, Microsoft, and other websites that support passkeys. While reviewing Apple's documentation, I found: "Passkey use in web browsers" "Authenticating people by using passkeys in browser apps" These documents mention that browser apps on iOS can support passkeys using: ASAuthorizationWebBrowserPublicKeyCredentialManager and the entitlement: com.apple.developer.web-browser.public-key-credential However, I could only find a request form titled: "Request the macOS Web Browser Public Key Credential Entitlement" which specifically asks: "Is your app a web browser on macOS?" My application is an iOS web browser, not a macOS browser. In addition, I previously requested the Default Web Browser entitlement, but my request was declined. My questions are: Is there a separate application process for requesting the Web Browser Public Key Credential entitlement for an iOS browser? Is approval of the Default Web Browser entitlement required before an iOS browser can use WebAuthn passkeys? Can an iOS browser request only the Web Browser Public Key Credential entitlement without becoming the system default browser? Is there any official documentation describing the entitlement request process for iOS browser apps? I know that third-party browsers such as Aloha Browser appear to support system Passkeys on iOS, so I would like to understand the correct implementation and entitlement process for an iOS browser. Thank you very much for your guidance.

Hi! We're developing a security product that uses both EndpointSecurity.framework to intercept and authorize process and file events; and NetworkExtension.framework o intercept and inspect network connections. We're occasionally seeing crashes caused by Endpoint Security timeouts. After investigating several crash reports, we believe we've identified a deadlock involving code signature verification: our Network Extension intercepts connections initiated by nsurlsessiond to retrieve OCSP/CRL data (we believe these requests are made on behalf of trustd during code signature validation). To determine which policy should be applied to an intercepted connection, our Network Extension verifies the code signature of the originating process. However, that code signature verification itself blocks while waiting for the OCSP/CRL requests to complete. Since those requests are being intercepted by our Network Extension, we end up with a circular dependency: A process requires code signature verification. Signature verification triggers OCSP/CRL network requests. Those requests are intercepted by our Network Extension. Our Network Extension attempts to verify the initiator's code signature before allowing the connection. That verification waits for the same OCSP/CRL requests to complete. As a result, code signature verification becomes blocked process-wide, including verification performed while handling Endpoint Security events. Eventually, our Endpoint Security client exceeds the allowed response timeout and is terminated. We're considering bypassing interception for OCSP/CRL traffic to avoid this deadlock, but we'd like to understand whether this is the recommended or most robust approach. Questions Is there a reliable way to identify network connections that are fetching OCSP or CRL data for code signature validation? What is the relationship between trustd and nsurlsessiond for these requests? Is there a dedicated nsurlsessiond instance serving trustd, or are these requests performed by the shared system/session-wide nsurlsessiond? Would it be a reasonable and future-proof approach to identify these requests by checking NEAppProxyFlow.remoteHostname (for example, ocsp.apple.com and crl.apple.com) and bypassing interception for those connections? Is there another recommended approach to avoid this deadlock when combining Endpoint Security and Network Extension in this way? Any guidance or best practices would be greatly appreciated. Thank you!

Sign in with Apple (web flow) fails 100% reproducibly at the token exchange for our newly created identifiers. POST to https://appleid.apple.com/auth/token with a REAL authorization code → 400 {"error":"invalid_client"}. The exact same client_id + client_secret from the same production server with a dummy code → {"error":"invalid_grant"} — i.e. client authentication passes and only the code is rejected, as expected. 16/16 probe requests across both registered redirect_uris. The authorization phase succeeds (user completes the appleid.apple.com sheet; code arrives via form_post to the registered return URL) and the exchange happens within ~1 second, so code expiry is not the cause. client_secret is an ES256 JWT with correct iss/sub/aud, validity ~6 months, sent via client_secret_post with no Authorization header. I have reviewed TN3107 — none of the documented invalid_client causes fit, given the invalid_grant asymmetry above. Persisted 24+ hours and survived: recreating the Services ID under a new identifier with a freshly minted secret; toggling the Sign in with Apple capability off/on (as primary) on the App ID; re-saving the Services ID configuration (domains and both return URLs re-confirmed). Team ID: CGSLWL988T Primary App ID: app.bookagym (created 2026-07-10) Services ID: app.bookagym.signin (an earlier Services ID app.bookagym.web behaved identically) Key ID: C99J756C86 This looks like stuck or unpropagated server-side provisioning for these identifiers rather than a client-side error. Per the "Gathering required information for troubleshooting Sign in with Apple authorization and token requests" post, I have filed the full details (including the failing request with all parameter values and a long-lived client secret) in Feedback Assistant: FB23692739

Hey guys, I am having issue, unable to verify the app. An internet connection is required to verify trust of the developer .... I am connected to the internet, date and time is correct. I did some google, some one reported this link: https://ppq-ext.v.aaplimg.com/ ssl expired, which is causing this issue. Can anyone help? I am testing to test my app on Iphone 15 pro max.

I'm building an iOS app using Capacitor with a Next.js 14 backend. Authentication currently uses: NextAuth Prisma Sign in with Apple Google Sign-In Magic Link The web version works correctly. For the native iOS app, tapping Continue with Apple currently opens the NextAuth endpoint (/api/auth/signin/apple), which launches the web authentication flow. App Review rejected the app because the Sign in with Apple flow leaves the native experience and opens a web view/browser during sign in. My goal is to keep Sign in with Apple fully native while continuing to use the same Prisma user database and authentication system used by the web application. What is Apple's recommended architecture for this scenario? Should I: Perform native Sign in with Apple in the Capacitor app. Send the returned identity token to my backend. Verify the token server-side. Create my own authenticated session instead of using the NextAuth Apple provider. Or is there another approach Apple recommends for hybrid apps using Capacitor? Any guidance would be greatly appreciated.

Quinn, you've often suggested that to validate the other side of an XPC connection, we should use the audit token. But that's not available from the XPC object, whereas the PID is. So everyone uses the PID. While looking for something completely unrelated, I found this in the SecCode.h file OSStatus SecCodeCreateWithXPCMessage(xpc_object_t message, SecCSFlags flags, SecCodeRef * __nonnull CF_RETURNS_RETAINED target); Would this be the preferred way to do this now? At least from 11.0 and up. Like I said, I was looking for something completely unrelated and found this and don't have the cycles right now to try it. But it looks promising from the description and I wanted to check in with you about it in case you can say yes or no before I get a chance to test it. Thanks

I am using ASAuthorizationProviderExtensionLoginManager.resetKeys() to generate new user-specific keys, specifically userDeviceSigningKey and userDeviceEncryptionKey. Based on the documentation, my understanding was that resetKeys() only resets keys associated with a particular user account: https://developer.apple.com/documentation/authenticationservices/asauthorizationproviderextensionloginmanager/resetkeys/ However, during testing, I observed that calling resetKeys() also resets sharedDeviceSigningKey. I had assumed that shared device keys would only be reset via resetDeviceKeys().

I’m seeing a regression in macOS 27 beta when using SwiftUI LocalAuthenticationView. When an LAContext is attached to LocalAuthenticationView, subsequent policy evaluation fails immediately with: Error Domain=com.apple.LocalAuthentication Code=-1007 NSDebugDescription="Caller is not Apple signed." NSLocalizedDescription="Authentication denied." The same policies work when evaluated on a plain LAContext that has not been attached to LocalAuthenticationView. Minimal shape of the failing path: @State private var context = LAContext() LocalAuthenticationView(context: context) { EmptyView() } context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: "Unlock") { success, error in print(success, error as Any) } This affects Touch ID unlock in our macOS app. We currently work around it by detecting LAErrorDomain / -1007, removing LocalAuthenticationView, and asking the user to manually start Touch ID with a fresh LAContext. Filed as Feedback: FB23262713 Could someone from the beta / LocalAuthentication team confirm whether this is an intended restriction for LocalAuthenticationView, or a macOS 27 beta regression?

Apple Developer Support Request - Sign in with Apple Failure Date prepared: 2026-07-08 App name: LingJing / XiaoLing Bundle ID: com.jachymchen.xiaoling Apple Developer Team ID: 765B64SW9Z Platform: iOS Summary Sign in with Apple fails before the app receives a usable Apple identity token. The user-facing Apple system sheet ends with the Chinese alert "未完成注册" ("Sign Up Not Completed"). The app callback does not receive an identityToken, so our backend auth provider is not reached successfully. We reproduced the same failure in a minimal native Swift app that only uses AuthenticationServices and the same Bundle ID / provisioning profile, without Supabase or any app-specific backend code. This suggests the failure is likely in the Apple Sign in with Apple authorization flow, account/device state, or App ID/provisioning configuration recognized by Apple's auth services, rather than in our app's backend implementation. Environment Mac: macOS 26.5 Apple Silicon MacBook Pro Xcode 26.5 iPhone: Real device connected over USB Device name: 硬糖的iPhone iOS 26.5.1 Device UDID: 00008150-000344540C99401C App: Bundle ID: com.jachymchen.xiaoling App version currently used for testing: 0.1.0 App Store Connect app ID observed during TestFlight work: 6784075688 TestFlight build upload previously succeeded for version 0.1.0 build 2 Provisioning / Entitlements Checked Development provisioning profile: Profile name: XiaoLing Dev application-identifier: 765B64SW9Z.com.jachymchen.xiaoling com.apple.developer.applesignin: [Default] com.apple.developer.team-identifier: 765B64SW9Z get-task-allow: true keychain-access-groups includes: 765B64SW9Z.* com.apple.token Profile includes the test device UDID: 00008150-000344540C99401C Expiration: 2027-06-27 Distribution / TestFlight provisioning profile: Profile name: XiaoLing AppStore application-identifier: 765B64SW9Z.com.jachymchen.xiaoling com.apple.developer.applesignin: [Default] beta-reports-active: true get-task-allow: false Signed app entitlements were checked from the executable and matched the expected Bundle ID / Team ID / Sign in with Apple entitlement. Important note: Running codesign -d --entitlements :- XiaoLing.app against the .app bundle may print an "invalid entitlements blob" style result. Running codesign against the actual executable inside the .app is the useful check, and that showed the expected entitlements. Reproduction Steps Install and launch the iOS app with Bundle ID com.jachymchen.xiaoling on the real iPhone. Tap "Sign in with Apple". Complete the Apple ID system prompt. The Apple system flow fails and shows "未完成注册". The app does not receive a valid ASAuthorizationAppleIDCredential identity token. Observed Result The Apple authorization flow fails before returning a usable credential to the app. The system UI shows "未完成注册" ("Sign Up Not Completed"). Expected Result AuthenticationServices should return an ASAuthorizationAppleIDCredential with an identityToken so the app can continue its own backend sign-in. Key Device Logs Observed During real-device attempts, the following log lines appeared around the failure: AuthKit continuation-key-creation token is missing AppleIDAuthSupport: setError: 2:M2 missing (bad password) SRP authentication with server failed AUTH_ALERT_SIGN_UP_NOT_COMPLETED -> 未完成注册 AKRemoteViewController did complete with authorization (null) AKAuthenticationServerError Code=-24000 The private framework error code by itself is not enough to identify the root cause, but the flow consistently fails inside Apple's AuthKit / Apple ID authorization path before our app receives an identity token. Minimal Native Demo Test To exclude app-specific implementation and backend issues, we created a minimal native SwiftUI app using only: AuthenticationServices SignInWithAppleButton ASAuthorizationAppleIDProvider The same Bundle ID: com.jachymchen.xiaoling The same Team ID / provisioning entitlement setup No Supabase No custom backend No React Native No third-party auth library The minimal native demo produced the same user-facing failure: "未完成注册". This strongly suggests the issue is not caused by Supabase, nonce hashing, OAuth handling, React Native, or our app UI. The failure happens before any backend auth exchange can occur. Additional Context The tester tried another Apple ID and still reproduced the failure. The tester stated the Apple ID itself is otherwise usable. The app's Bundle ID is intended to be exactly: com.jachymchen.xiaoling We specifically checked for provisioning profile / Bundle ID mismatch and did not find a mismatch in the installed build. Questions for Apple Developer Support Can Apple check whether App ID 765B64SW9Z.com.jachymchen.xiaoling has any server-side Sign in with Apple configuration issue? Can Apple explain what conditions produce: AUTH_ALERT_SIGN_UP_NOT_COMPLETED AKAuthenticationServerError Code=-24000 "M2 missing (bad password)" "AuthKit continuation-key-creation token is missing" in a native AuthenticationServices Sign in with Apple flow? Is there any known issue on iOS 26.5.1 or with development-signed apps where Sign in with Apple fails before returning an ASAuthorizationAppleIDCredential? Are there account-level or device-level requirements beyond normal Apple ID login that can cause Sign in with Apple to show "Sign Up Not Completed"? Can Apple verify whether this Bundle ID / Team ID is correctly enabled for Sign in with Apple on Apple's backend? Minimal Code Shape Used for Native Demo The native demo used a standard SignInWithAppleButton: SignInWithAppleButton(.signIn) { request in request.requestedScopes = [.fullName, .email] } onCompletion: { result in switch result { case .success(let authorization): // Check authorization.credential as ASAuthorizationAppleIDCredential // and read identityToken. case .failure(let error): // Log NSError domain, code, localizedDescription, and userInfo. } } Support Request Please help determine why Apple's Sign in with Apple authorization flow fails for Bundle ID com.jachymchen.xiaoling before returning a credential, despite the app having the Sign in with Apple entitlement and matching provisioning profile / Bundle ID.

We generate Secure Enclave keys via SecKeyCreateRandomKey with kSecAttrTokenIDSecureEnclave on macOS. We need to prove to a remote server that the key is genuinely hardware-bound, not a software key claiming to be one. Is there any API on macOS for an app to obtain an Apple-signed certificate or attestation statement for such a Secure Enclave key, similar to how ASAuthorizationProviderExtensionLoginManager.attestKey() works within Platform SSO but available to general apps? Or other possible workaround for this? Thank you!

Hi, I would like to share a keychain item common for mac os app (sandboxed) and swift cli app (non sandboxed). Is there a recommended way for doing this? Thanks

Subject: Sign In with Apple consistently fails with AuthorizationError 1000 (empty userInfo) immediately after successful biometric authentication — native delegate logging confirms failure occurs before authorization is returned to app App ID: com.andresalecina.vant
Team ID: C6GK7Z5GY2
Services ID: com.andresalecina.vant.signin Summary:
Sign In with Apple fails 100% of the time in our native iOS app (Capacitor 7 wrapper) with error code 1000 and completely empty userInfo. The native authentication sheet displays correctly and the user completes Face ID successfully, but authentication fails immediately afterward. Critical new evidence (delegate-level logging):
We instrumented both ASAuthorizationControllerDelegate callback methods directly with NSLog to determine exactly where the failure occurs: authorizationController(controller:didCompleteWithAuthorization:) — never fires. Confirmed across multiple fresh test attempts. authorizationController(controller:didCompleteWithError:) — fires every time, receiving: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1000 "(null)" with completely empty userInfo. This confirms the failure originates inside AuthenticationServices itself, before any authorization object is ever returned to our app. Our app code is not receiving a token, credential, or authorization of any kind to process — there is nothing for our code to mishandle. Everything already verified clean on our end: Sign In with Apple capability present in Xcode target and confirmed in Apple Developer Portal (Primary App ID, not grouped) Entitlement com.apple.developer.applesignin confirmed present in both the development-signed binary and the App Store distribution provisioning profile Team ID in the compiled binary matches the entitlement (verified via codesign -dv and codesign -d --entitlements) Provisioning profile freshly regenerated after capability was added Apple Developer Program License Agreement and Developer Agreement both fully accepted, no pending items Reproduces identically on two separate physical devices (one iOS 27 beta, one non-beta), on both WiFi and cellular Reproduces with a completely clean Apple ID test account (no prior Family Sharing/managed account involvement, confirmed adult standard account) Device clock, timezone, and Screen Time/Content & Privacy Restrictions confirmed not a factor Native plugin code reviewed line-by-line: uses stock ASAuthorizationAppleIDProvider().createRequest(), standard .fullName/.email scopes only, robust presentation anchor resolution (no detached/fake UIWindow) Timeline:
The Sign In with Apple capability was added to this App ID within the past 24–48 hours (it was missing entirely on our initial rejected App Store submission). Error 1000 has persisted consistently across many rebuilds since the capability was added, which raises the possibility of a propagation delay on Apple's authentication backend, but this has now exceeded typical propagation windows for other capabilities we've observed (Push Notifications, Associated Domains). What we're asking:
Can you verify, on Apple's side, whether App ID com.andresalecina.vant under Team C6GK7Z5GY2 is fully provisioned and active on Apple's Sign In with Apple authentication backend? All client-side, code-side, and account-side factors we can verify are confirmed correct; the delegate-level logging above confirms the failure is occurring before any authorization is returned to the client, which points to a state on Apple's servers that isn't visible to us through the standard Developer Portal UI. Happy to provide device sysdiagnose logs, the full Xcode archive, or a minimal reproduction project (bare SwiftUI, no Capacitor/Supabase) if useful.

I'm implementing Sign in with Apple for a web-only service (Services ID associated with a primary App ID, plus a private key for the client secret JWT). Before I finalize the setup I want to confirm one prerequisite, because two of Apple's own pages give different answers. "Configuring your environment for Sign in with Apple" states that to authenticate users with a web service you must have an existing app in the App Store that uses Sign in with Apple: https://developer.apple.com/documentation/signinwithapple/configuring-your-environment-for-sign-in-with-apple "Configure Sign in with Apple for the web" (Account Help) only says to associate your website with an existing primary App ID enabled for Sign in with Apple — i.e., just a registered identifier, with no mention of a published app: https://developer.apple.com/help/account/capabilities/configure-sign-in-with-apple-for-the-web/ My question: for a web-only service, is a published (or in-review) App Store app actually required, or is a registered App ID identifier with the Sign in with Apple capability enabled sufficient on its own? And if a published app isn't required, is the "existing app in the App Store" wording just meant to describe the App ID rather than a live listing? I've contacted Developer Support and was pointed back to the general docs, which are the source of the contradiction rather than the answer, so I'm hoping an engineer or someone who has shipped a web-only setup can confirm which prerequisite governs. Thanks in advance.

% curl -v https://app-site-association.cdn-apple.com/a/v1/zfcs.bankts.cn Host app-site-association.cdn-apple.com:443 was resolved. IPv6: (none) IPv4: 218.92.226.151, 119.101.148.193, 218.92.226.6, 115.152.217.3 Trying 218.92.226.151:443... Connected to app-site-association.cdn-apple.com (218.92.226.151) port 443 ALPN: curl offers h2,http/1.1 (304) (OUT), TLS handshake, Client hello (1): CAfile: /etc/ssl/cert.pem CApath: none (304) (IN), TLS handshake, Server hello (2): (304) (IN), TLS handshake, Unknown (8): (304) (IN), TLS handshake, Certificate (11): (304) (IN), TLS handshake, CERT verify (15): (304) (IN), TLS handshake, Finished (20): (304) (OUT), TLS handshake, Finished (20): SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF ALPN: server accepted http/1.1 Server certificate: subject: C=US; ST=California; O=Apple Inc.; CN=app-site-association.cdn-apple.com start date: Sep 25 13:58:08 2025 GMT expire date: Mar 31 17:44:25 2026 GMT subjectAltName: host "app-site-association.cdn-apple.com" matched cert's "app-site-association.cdn-apple.com" issuer: CN=Apple Public Server RSA CA 11 - G1; O=Apple Inc.; ST=California; C=US SSL certificate verify ok. using HTTP/1.x GET /a/v1/zfcs.bankts.cn HTTP/1.1 Host: app-site-association.cdn-apple.com User-Agent: curl/8.7.1 Accept: / Request completely sent off < HTTP/1.1 404 Not Found < Content-Type: text/plain; charset=utf-8 < Content-Length: 10 < Connection: keep-alive < Server: nginx < Date: Wed, 04 Feb 2026 02:26:00 GMT < Expires: Wed, 04 Feb 2026 02:26:10 GMT < Age: 24 < Apple-Failure-Details: {"cause":"context deadline exceeded (Client.Timeout exceeded while awaiting headers)"} < Apple-Failure-Reason: SWCERR00301 Timeout < Apple-From: https://zfcs.bankts.cn/.well-known/apple-app-site-association < Apple-Try-Direct: true < Vary: Accept-Encoding < Via: https/1.1 jptyo12-3p-pst-003.ts.apple.com (acdn/3.16363), http/1.1 jptyo12-3p-pac-043.ts.apple.com (acdn/3.16363), https/1.1 jptyo12-3p-pfe-002.ts.apple.com (acdn/3.16363) < X-Cache: MISS KS-CLOUD < CDNUUID: 736dc646-57fb-43c9-aa0d-eedad3a534f8-1154605242 < x-link-via: yancmp83:443;xmmp02:443;fzct321:443; < x-b2f-cs-cache: no-cache < X-Cache-Status: MISS from KS-CLOUD-FZ-CT-321-35 < X-Cache-Status: MISS from KS-CLOUD-XM-MP-02-16 < X-Cache-Status: MISS from KS-CLOUD-YANC-MP-83-15 < X-KSC-Request-ID: c4a640c815640ee93c263a357ee919d6 < CDN-Server: KSFTF < X-Cdn-Request-ID: c4a640c815640ee93c263a357ee919d6 < Not Found Connection #0 to host app-site-association.cdn-apple.com left intact

I've been implementing App Attest on macOS 27 following the WWDC 2026 Session 201 announcement. DCAppAttestService.shared.isSupported always returns false on my M4 Mac running macOS 27.0 (26A5368g), even with the correct entitlement and a valid provisioning profile. What I have set up (correctly, as far as I can tell) com.apple.developer.devicecheck.app-attest-opt-in capability enabled in the Developer Portal (value CDhash) Entitlement present in both the binary and the embedded provisioning profile Developer ID signed, ProvisionsAllDevices: true The problem DCAppAttestService.shared.isSupported returns false from every process type I tested: An EndpointSecurity system extension A launchd daemon A sandboxed app running in user session generateKey() fails with com.apple.devicecheck.error code 1 (featureUnsupported). Root cause? (from devicecheckd logs) I see these logs devicecheckd: [com.apple.devicecheck:aai] FeatureFlagsManager.m:35 Mac feature flag enabled { enabled=1 }. devicecheckd: (AppAttestInternal) [com.apple.appattest:secl] SecurityController.swift:44 Failed to fetch value for entitlement. { entitlement=com.apple.devicecheck.daemon-client } devicecheckd: (AppAttestInternal) [com.apple.appattest:aahl] AppAttestHandler.swift:48 Client connection is ineligible. { clientUUID=nil } So the feature IS active in macOS 27 (Mac feature flag enabled=1), but devicecheckd immediately rejects any connecting process that doesn't hold the private entitlement com.apple.devicecheck.daemon-client. What is com.apple.devicecheck.daemon-client? Searching public entitlement databases shows this entitlement exists on iOSbut no macOS binary appears to hold it in any public database. It's not available to third-party developers via the Developer Portal. This check in SecurityController.swift:44 appears to be new in this beta. Questions Is com.apple.devicecheck.daemon-client the correct mechanism for third-party developers to use App Attest on macOS 27, or is this an internal gating mechanism that will be replaced/removed before GM? Is App Attest on macOS 27 fully available to third-party developers in this seed, or is it still restricted to Apple-internal testing? Is there a different entitlement or provisioning capability that third-party developers should request to allow DCAppAttestService.isSupported to return true?

We have a custom SecurityAgentPlugin that is triggered by multiple authorizationdb entries. Some customers report that the SecurityAgent process takes window focus even though no UI or windows are displayed. Our plugin explicitly ignores the _securityAgent user and does not show any UI for that user. However, in macOS 26.1, it appears that the plugin still causes the SecurityAgent to take focus as soon as it is triggered. Is this a change in macOS 26.1 or a bug? Can we do anything to prevent "focus stealing"?

Environment: MacBook Pro 14-inch Nov 2023 (Apple Silicon M3) macOS 26.5 (25F71) and 26.5.1 (25F80) MDM: Kandji/Iru enrolled BeyondTrust EPM-M 26.1.1495 Confirmed chain via epsext exec logs: The Kandji/Iru Parameter Agent (kandji-parameter-agent) calls /usr/sbin/systemsetup -getusingnetworktime every 15 minutes. Each invocation requests the system.preferences authorization right, waking authd → writeconfig.xpc → SecurityAgent. SecurityAgent then opens a SkyLight connection, calls SetFrontProcess, causes the active window to resign key appearance, and closes — all within 3–15 seconds. Cross-referenced against user-reported times: User reported focus steal at 10:13, 10:58, 11:13, 11:43 (CDT). SecurityAgent fired at exactly those times to the second in our WindowServer logs. Key finding: The systemsetup call itself is not the root issue — it's doing its job. The problem is that on macOS 26 Tahoe, this auth request causes SecurityAgent to grab keyboard focus as a side effect, which it should not do for a background/silent authorization check with no user interaction required. BeyondTrust KB0023327 documents the PMCAdapter event as a separate but related trigger. Both are symptoms of the same underlying SecurityAgent behaviour change in macOS 26.