The IPA generated for the project contains references to the malloc function, which is flagged as an insecure function. This occurs when using standard higher-order functions such as filter, first, etc., on arrays containing value-type elements. How can we address or eliminate this security finding? Example code struct ContentView: View { let arr = [1,2,3] var body: some View { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello, world!") } .padding() .onAppear{ let twos = arr.filter{ $0 == 2 } } } }

Is it possible to get to the SymmetricKeys provided by a passkey as per the WebAuthn prf extension by just having to authenticate the user locally? The use case would be signing into an app and decrypting user data encrypted with those keys while the device is offline.

We have a macOS application that adds entries to the Authorization Database (system.login.console) as part of its setup. We observed that after upgrading from macOS Tahoe to the macOS Golden Gate beta, the entries added by our application were removed, and the default system.login.console configuration was restored. Is this expected behavior in the current Golden Gate beta, or is it a known issue? If it is a known issue, is there an expectation that it will be addressed in a future beta release? Additionally, is there any recommended approach for preserving or restoring application-specific Authorization Database entries across major macOS upgrades? It would be of great help if there is any suggested approach for the same.

I am planning an app transfer between two developer teams, iOS only, no macOS app. The app shares an app group with a notification service extension and a share extension. The container holds a SQLite database, message attachments and user avatars. The database encryption key is in the keychain. I have read thread https://developer.apple.com/forums/thread/706128 (including the 2026-03-31 revision), and the plan is to follow it: a pre-transfer release moving keychain items into the AGI keychain access group, time for adoption, then the app transfer, then the app group transfer. I've also read https://developer.apple.com/forums/thread/774831, https://developer.apple.com/forums/thread/782132 and https://developer.apple.com/forums/thread/815779. My questions are about the container rather than the keychain: Step 7 of 706128 says that when a user installs the post-transfer version, "it will have access to your app group, and hence your keychain items". Does that access include the files already in the app group container, written while the app was signed by the old team? Or does the transfer restore only AGI keychain access group membership, leaving the container's prior contents inaccessible? If those files are not preserved, is there a supported way to migrate them, or should I relocate that data into the app's own container before the transfer? Thread 815779 asked this and I do not think it was answered. While the app group transfer is in progress, do already installed builds signed by the old team, which the user has not updated, keep working against the original container? App Store Connect Help (Transfer an app > Overview of app transfer > Apps using App Groups) says the app group "can be deleted from the transferor's account and registered to the recipient's account". Is that the same operation as step 5 of 706128, "transfer the app group ID", or two different things? I ask because the developer in thread 774831, who lost shared container data for roughly 25% of users, deleted and recreated the group during the transfer, whereas 706128 step 5 says to do it once the app transfer is complete.

Product area macOS / Privacy & Security / ScreenCaptureKit / Core Graphics Environment macOS 27 Beta 4 (build: fill in your exact build number, e.g. 27A5xxx) Xcode 26.5 / SDK 260500 (adjust to match what you actually built with) App holds the com.apple.developer.persistent-content-capture entitlement (approved via Apple's request form), targeting macOS 14.4+ Summary Our app is a remote-support/remote-control tool (screen viewing + control), comparable to VNC-style products. On macOS 27, we've found that System Settings > Privacy & Security now shows a "Remote Desktop" entry that is distinct from "Screen & System Audio Recording" — granting one does not affect the other. We need a way to check, at any time, whether our app currently has "Remote Desktop" authorization, without causing the system to show a permission-request alert as a side effect. We have not found a documented, public API that does this. What we've tried CGPreflightScreenCaptureAccess() Confirmed via a controlled test on-device: granting only "Remote Desktop" leaves this API returning false; granting only "Screen & System Audio Recording" makes it return true. So this API appears to reflect kTCCServiceScreenCapture only, and does not reflect the "Remote Desktop" permission at all. ScreenCaptureKit (SCShareableContent, e.g. via a refreshAvailableContentWithCompletionHandler:-style call) This call does appear to interact with the "Remote Desktop" permission — but calling it triggers a real system consent alert every time we call it, even when we only intend to read the current status, not request it. This makes it unusable for passive/background status polling (e.g. to decide what to show in our own onboarding UI without surprising the user with an OS-level prompt). We are intentionally not reading /Library/Application Support/com.apple.TCC/TCC.db directly — we understand this is a private, undocumented database and want a supported API instead. Sample code illustrating both attempts // Attempt 1: CGPreflightScreenCaptureAccess — does not reflect Remote Desktop grant BOOL preflightResult = CGPreflightScreenCaptureAccess(); // preflightResult stays NO even after the user grants "Remote Desktop" in // System Settings > Privacy & Security > Remote Desktop. // It correctly flips to YES only when "Screen & System Audio Recording" is granted. // Attempt 2: ScreenCaptureKit-based check — reflects it, but prompts every time SCShareableContent... // (via our wrapper) refreshAvailableContentWithCompletionHandler: // This call appears to influence/query the Remote Desktop TCC entry, but the OS // shows a permission alert as a side effect of the call itself, even when we only // want to read the current authorization state. Question Is there a public, documented API equivalent to CGPreflightScreenCaptureAccess() — i.e., a read-only, non-prompting status check — for the new "Remote Desktop" privacy category introduced around macOS 26/27? Is com.apple.developer.persistent-content-capture actually the entitlement that governs this new "Remote Desktop" category, or is it unrelated? Apple's own documentation describes this entitlement purely in terms of "persistent access to screen capture" for VNC apps, with no mention of a distinct "Remote Desktop" permission surface — we'd like to confirm whether that description is still accurate on macOS 26/27, or whether the underlying TCC service (kTCCServiceRemoteDesktop, which we found via TCC.db schema inspection only, not public docs) has been intentionally split out. If no such API exists yet, is this planned, and is there a recommended interim approach for apps that need to know this state before deciding whether to show their own onboarding/permission UI?

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.