Hi Apple Developer Support, We are implementing Sign in with Apple for our web application hosted on example.com. In the Service ID settings, we have configured the following: Service ID (client_id): com.example.service.local Web Domain: example.com Return URL: https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple We also tested login via the following URL from our web application: https://appleid.apple.com/auth/authorize?response_mode=form_post&response_type=code&client_id=com.example.service.local&scope=name%20email&state=2f9gMY1rTe12-O7Wbnb7KWe504HQ0KWBSHTKHbg9ZEY=&redirect_uri=https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple However, we’re receiving an invalid_client error after submission. Our questions: Is it valid to use an ngrok URL like https://2db2-121-160-153-88.ngrok-free.app/... as the Return URL for development and testing? Does the Web Domain need to match the ngrok domain, or is it enough to register the production domain (e.g., example.com)? Is there any propagation delay or approval process after updating the Return URL in the Service ID? Is the client_id strictly required to match the Service ID exactly? We would greatly appreciate any insights or best practices to help us resolve this issue. Thank you in advance!

Sign in with Apple is failing for every user, on every device, for our live App Store app. Each attempt fails inside Apple's native sign-in sheet with the error "Sign-Up Not Completed" — before any of our code runs (no ASAuthorizationController delegate callback is reached). Environment / identifiers: Bundle ID: online.framenet.app Team ID: 5F2256QJNT App Store app: FrameNet, App ID 6799345029 (approved and live as of Aug 24, 2026) Timeline: Last worked: Aug 8, 2026 Failing on every attempt since: Aug 14, 2026, across builds 12–16 Our sign-in code is unchanged between the working and failing period Already verified / attempted on our side: Sign in with Apple entitlement is present in the signed builds (confirmed via codesign entitlement dump) Capability is enabled on the App ID in Certificates, Identifiers & Profiles Provisioning profile is valid and includes the capability Removed and re-added the Sign in with Apple capability and regenerated the provisioning profile on Aug 17 — no change Google Sign-In in the same app works normally, so networking and the rest of the auth stack are fine Reproduced on multiple physical devices and Apple IDs Because the failure occurs inside Apple's own sign-in sheet before our code executes, this appears to be a server-side state problem with Sign in with Apple for our App ID, and nothing we change client-side has any effect. We were forced to ship v1.0 with Sign in with Apple disabled. A Developer Support case is already open for this: case 20000140460775. A screen recording and full environment details have been provided in that case. Has anyone from Apple seen this "Sign-Up Not Completed" state, and can engineering inspect/repair the server-side Sign in with Apple configuration for this App ID?

Sign in with Apple has never completed for our app. The native sheet presents correctly (name, Share/Hide My Email), but on confirmation it shows "Sign Up Not Completed" with a red exclamation. No identity token is returned; the delegate receives ASAuthorizationError 1001 only after the sheet is dismissed. The failure happens entirely inside the system sheet, before any callback reaches app code. Environment: iPhone 15 Pro Max / iOS 26.6, TestFlight builds. The Sign In with Apple capability was newly enabled on the App ID five days ago and the flow has failed on 100% of attempts ever since. (I'm withholding the Team ID / bundle ID here since this is public — happy to share them with an Apple engineer via the open support case or a Feedback report.) Implementation - identical to Apple's "Implementing User Authentication with Sign in with Apple" sample; we even replaced the third-party wrapper we originally used with this first-party version to rule it out, and the failure is unchanged: let provider = ASAuthorizationAppleIDProvider() let request = provider.createRequest() request.requestedScopes = [.fullName, .email] let controller = ASAuthorizationController(authorizationRequests: [request]) controller.delegate = self // controller strongly retained until completion controller.presentationContextProvider = self controller.performRequests() Verified correct (not assumed — extracted/inspected directly): Signed binary entitlements (extracted from the distributed IPA): com.apple.developer.applesignin = (Default), with the correct application-identifier and team-identifier for our team embedded.mobileprovision in the bundle contains the same entitlement App ID capability read back via the App Store Connect API: APPLE_ID_AUTH with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (portal shows "Enable as a primary App ID") Exactly one App ID in the account; no wildcard, no duplicates Program License Agreement accepted; nothing pending Already tried, no change: re-saving the capability in the portal; deleting and re-creating the capability via the App Store Connect API; generating a new provisioning profile after that re-registration and shipping a new build signed with it; Share My Email and Hide My Email; device restarts (iCloud + 2FA active); waiting 5+ days for propagation. This matches threads 789588, 789418 and 789323, and the service-side configuration issue described in thread 790827 (invalid_client / "Sign Up Not Completed" for developer accounts that created or edited app configurations, resolved server-side with no developer action). A Developer Support case and a TSI are already open. Question for Apple engineers: with the client implementation identical to the official sample and every developer-side artifact verified, is there anything left on the developer side that can produce this - or can the Sign in with Apple service-side registration for our client_id be checked? This is blocking an App Store release (the app was rejected under Guideline 4.8 and Sign in with Apple is the required remedy). A sysdiagnose captured during reproduction is available, and I can provide the Team ID, bundle ID and case numbers privately on request.

Since October 3rd, I've stopped receiving responses to the Private Access Tokens challenge. I'm using this link: https://demo-issuer.private-access-tokens.fastly.com/.well-known/token-issuer-directory. I receive tokens from Fastly and return a header to the iOS app, but then I don't receive another authentication request from iOS. The user has automatic verification enabled on their phone. The problem is global and affects all my mobile app users. Has anyone encountered a similar problem and found a solution?

Since release of 18.4. prepareInterfaceToProvideCredential .oneTimeCode case is not called and instead prepareInterfaceForUserChoosingTextToInsert() is called. That is the wrong delegate for this case and it causes confusion for the users. Also, some TOTP fields are recognised however, the key icon button is not presented above the keyboard next to TOTP suggestions. I've also tested 18.5 and it has the same issue. provideOneTimeCodeWithoutUserInteraction works just fine.

Sign in with Apple fails with "Sign-Up Not Completed" for one App ID only — other apps in the same team work on the same device I have a Sign in with Apple failure that is isolated to a single App ID, and I would appreciate an Apple engineer looking at the server-side registration state for it. Filed as FB24483427. Symptom For App ID com.laonmon.twothrones (Team LH4XJ8LL98), Sign in with Apple never completes: The native ASAuthorizationController sheet appears correctly. The user authenticates with Face ID / Touch ID. iOS shows "Sign-Up Not Completed". The delegate receives ASAuthorizationError code 1000 with no further detail. No request ever reaches our server, so the failure happens entirely inside Apple's authorization flow. Our production database shows 0 accounts created via Sign in with Apple out of 147 total accounts — it has never succeeded for any user. The control experiment This is the part I think is diagnostic. Tested in one sitting, on the same iPad, signed in with the same standard (non-managed, adult) Apple ID: Notion (third-party App Store app) — sign-up completes SwingNote (my own released app, com.swingnote.app, Team LH4XJ8LL98) — sign-up completes Two Thrones (com.laonmon.twothrones, Team LH4XJ8LL98) — "Sign-Up Not Completed" Same device, same Apple ID, same team, same capability configuration — only the App ID differs. That rules out the device, the Apple ID, the team account, and the local configuration. What I have already checked Entitlement is in the signed binary. codesign -d --entitlements - on the archive shows com.apple.developer.applesignin = ["Default"]. (I did find and fix a real build defect earlier: our archive step ran with CODE_SIGNING_ALLOWED=NO, which skips entitlement processing entirely. Before that fix the sheet did not appear at all. Worth checking if you see no sheet — but that is a different symptom from this one.) App ID capability is enabled — APPLE_ID_AUTH, APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT. I removed and re-added the capability and regenerated the provisioning profile. No change. All four App IDs in the team have identical Sign in with Apple settings. Settings › Sign in with Apple does not list the app on the test device, so no app-scoped identifier was ever created. The sign-up genuinely never completes rather than failing on reuse. Updated Apple Developer Program License Agreement accepted; App Store Connect banner cleared. This is not propagation delay. I have seen the thread where it started working after ~2 days. The capability has been configured since Aug 16 and has never succeeded — across three App Review sessions on different devices (iPad Air 11-inch M3 / iPadOS 26.6, iPhone 17 Pro Max / iOS 26.6) and my own testing. Device logs captured over USB show AuthenticationServicesUI and AuthKitUIService starting normally, but all authentication detail is redacted as <private>. I understand the Accounts/AuthKit logging profile is needed to read it, and I will attach a sysdiagnose to the Feedback report once I have it. Impact Three consecutive App Review rejections under Guideline 2.1(a). This is the only thing blocking our initial release. Question Given that the same device and Apple ID succeed for another app in the same team, is there a server-side Sign in with Apple registration or account-association state per App ID that can get into a bad state, and is there anything a developer can do to reset it? Anything I can check or provide would be welcome. Feedback: FB24483427 DTS case: 20000144146252 (Developer Support advised filing here — they cannot see Feedback Assistant reports themselves.)

Team ID: ED9QVUCFPE (individual) Bundle IDs affected: com.lumevolab.justmorriz, com.lumevolab.memiq Broken since: 28 July 2026, immediately after the Apple Developer Program membership was renewed/reactivated. Still broken on 21 August 2026 (24 days). Apple Developer Support case: 20000131208746 (closed: "no anomaly found on the membership", referred to the forums) App Review rejection: submission f087942b, 13 Aug 2026, guideline 2.1(a), "unable to log in with Sign in with Apple", on iPad Air 11" M3 / iPadOS 26.6 Symptom The native Sign in with Apple sheet opens, Face ID succeeds, and then the sheet shows the red error "Sign Up Not Completed" ("Registrazione non completata") underneath the Continue button. The sheet stays open, so ASAuthorizationController never calls back — the app-side code never runs. The sheet's own wording is "Create an account for ", so it is the account-creation step that fails on Apple's side, not our token handling. Device log (captured with idevicesyslog during a reproduction) akd ... signing request, calling GrandSlam (gsService) akd ... server response (733 bytes) akd(AppleIDAuthSupport) setError: 2:M2 missing (bad password) AuthKitUIService ... Showing Authorization UI Alert (8 ms later) M2 missing is the SRP exchange: the server did not return its M2 proof, i.e. it refused the client's M1 for this operation. Why this is not an account or device problem Sign in with Apple works on the same iPhone with the same Apple Account in third-party apps (verified with Vinted). It also failed on the App Review team's own iPad, with their own Apple Account (rejection above). So it is not tied to one account or one device. It fails identically on two different App IDs of the same team. Tried and made no difference: device restart, changing the Apple Account password, signing out and back in to the Apple Account. Configuration — verified via the App Store Connect API, not by eye Item State App ID com.lumevolab.justmorriz (89A4UV66RF) APPLE_ID_AUTH present, setting APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT Provisioning profile IOS_APP_STORE, ACTIVE, includes the applesignin entitlement com.apple.developer.applesignin ['Default'] in Debug, Release and Profile entitlements files Same entitlement in the signed binary verified with codesign -d --entitlements :- build/ios/iphoneos/Runner.app Firebase project playmorriz apple.com provider enabled Program License Agreement released 18 Aug 2026, accepted 21 Aug 2026 Paid Apps / Free Apps agreements both Active Membership active, renews 4 Apr 2027 What we tried on 21 August 2026, with no change Accepted the pending Program License Agreement (it was released on 18 Aug, so it cannot explain a failure that started on 28 Jul, but we ruled it out). Removed and re-added the APPLE_ID_AUTH capability on the App ID via the App Store Connect API (DELETE then POST /v1/bundleIdCapabilities), to force Apple to re-provision the server-side Sign in with Apple record for the App ID. Device restarted afterwards. Same error. Prior art suggesting a server-side cause Forums thread 790323 — identical akd … "M2 missing (bad password)", same asymmetry (other apps fine, one team's apps broken), thorough config checks. It resolved by itself after 11 days with no developer action. Threads 789588, 789418, 789579, 803591 — same class of report, no client-side cause ever identified. June 18–23, 2025: Apple acknowledged a server-side configuration fault producing exactly "Sign Up Not Completed" + invalid_client, affecting only accounts that had recently created or modified App ID / Services ID configurations (thread 790827). Our team's capabilities were re-provisioned at renewal on 28 Jul 2026 — the same class of event. Ask Please check the server-side Sign in with Apple relying-party record for team ED9QVUCFPE. Everything under our control is correct and has been re-created from scratch; the failure is in the sign-up call to GrandSlam.

Case #20000132024383 has been filed with Developer Support; posting here as well for visibility Hi Apple Developer Support team, We are experiencing a release-blocking issue: Sign in with Apple always fails server-side with AKAuthenticationServerError -24000 for our bundle com.dadilo.app, on all devices and all Apple IDs we have tested, while the same devices and accounts use Sign in with Apple successfully in other apps. IDENTIFIERS Team ID: HF53KC83Z3 (Individual - Nguyen Duy Mao) Bundle ID: com.dadilo.app (App ID resource 96Q4FAZ8PF) App Store Connect app: "Dadilo: Giup viec nha" - Apple ID 6782634291 (unreleased; TestFlight builds 1.0.0 (120-126)) Client: native ASAuthorizationAppleIDProvider request (Flutter sign_in_with_apple plugin). No web/Services-ID flow is involved. SYMPTOM Every Sign in with Apple attempt completes the system sheet (Face ID/password succeeds, scope selection is shown), then iOS shows the alert "Sign-Up Not Completed". The app's ASAuthorizationControllerDelegate receives ASAuthorizationError code 1001. No credential is ever issued. Device syslog at the exact moment of each failure (captured 2026-08-07 and 2026-08-08): akd: SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2 AKRemoteViewController did complete with authorization (null), error Domain=com.apple.AppleIDAuthSupport Code=2, NSUnderlyingError Domain=AKAuthenticationServerError Code=-24000 akd: Creating AKAuthenticationServerResponse with status contents: (null) akd: Invalid/missing value for key acname: (null); Invalid value for key ut: (null); Invalid value for key authType: (null) The server rejects the request and returns an EMPTY payload; -24000 is the client's reaction to it. An initial tap sometimes logs AKAuthenticationError -7003 first. REPRODUCTION - fails in EVERY combination Devices: iPad mini (iPad16,2, iPadOS 26.5.2) and an iPhone (iOS 26.x) - fails on both Apple IDs: 2 different accounts (2FA enabled, adult, region Vietnam) - fails on both Builds: TestFlight 1.0.0 builds 122, 124, 125, 126 - fails on all Request shape: the standard request (email + fullName scopes, SHA-256 nonce) AND a minimal request (no scopes, no nonce) both fail identically DECISIVE CONTROL TEST (2026-08-08) On the SAME iPad, SAME Apple ID, SAME network, minutes after our app failed,le authorization for another app (ChatGPT - never previously authorized on this account) succeeded normally. So fresh-authorization SRP works for this erver issues credentials for other bundles but rejects com.dadilo.app specifically. Existing authorizations (Notion, Grab, Shopee, Goodnotes) alsocounts. ALREADY VERIFIED / RULED OUT Entitlement com.apple.developer.applesignin = [Default] present in the binary; the provisioning profile contains the entitlement (decoded and checked); the authorization sheet opens and biometric completes, so the entitlement is honored App ID capability APPLE_ID_AUTH enabled, APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (verified via App Store Connect API); no grouped-app configuration conflicts on the team Program License Agreement issued 2026-06-18, accepted 2026-06-21; no pendi Test Apple IDs are healthy: 2FA on, adult birthdays, no Family restrictionh Apple with other apps No stale authorizations: this app is not listed in Settings > Sign in with- Capability re-provisioning attempted 2026-08-08: deleted and re-created APnerated a brand-new App Store provisioning profile, rebuilt and re-tested(build 125) - identical -24000 failure Apple System Status showed no Sign in with Apple outage during any test REQUEST AKAuthenticationServerError -24000 is not publicly documented. Everything clecks out, and the failure is 100% reproducible for this bundle ID only.Please inspect the server-side Sign in with Apple configuration/state for co3 and advise what is rejecting credential issuance.The app is complete and ready for App Store submission; Sign in with Apple ier Guideline 4.8, so this issue is blocking our first release. Fullidevicesyslog captures from both days are available on request. Thank you, Nguyen Duy Mao Team HF53KC83Z3

We have observed significant UI changes to the SFAuthorizationPluginView login experience in the latest macOS Golden Gate Beta 5. After entering the account password at the SFAuthorizationPluginView screen, we were previously able to access the buttons and other child elements present in the SFAuthorizationPluginView using "accessibilityChildrenInNavigationOrder" . Currently the method returns that there are no child elements eventhough there are clearly child elements presents including apple's native Ok and Cancel buttons.This behaviour is consistently reproducible in our testing. Steps to Reproduce Configure and launch an unlock authorization plug-in using SFAuthorizationPluginView. Display the authorization UI in unlock. Enter the account password. Wait for the authorization UI to finish transitioning to the authenticated state. Query the SFAuthorizationPluginView accessibility hierarchy. Specifically query accessibilityChildrenInNavigationOrder. Observe that the method returns no child accessibility elements. Inspect the UI visually or using Accessibility Inspector and observe that child controls are still present, including the native OK and Cancel buttons. We would like to understand: 1.Is this a known issue with the current macOS Golden Gate Beta? 2.Is this expected behaviour due to the UI redesign, or is it considered a bug? 3.If it is a known issue, is there a fix planned for an upcoming beta or the final release? Any information or guidance would be appreciated. Thank you.

I have discovered another app which has taken assets, screens etc from my IPA bundle and are passing off as their own. I also checked my own IPA bundle and my metal shaders are accessible. It's obvious that the app is vibe coded and they just handed as much of my code as possible to Claude and asked it to reverse engineer. Considering any IPA bundle can be downloaded from the AppStore, is there any way to protect against this? I have put a lot of time into some of the assets and shaders and it's kind of frustrating to see them so easily stolen. With the rise of AI this will become a more frequent occurrence for sure.

We have observed significant UI changes to the SFUnlock login experience in the latest macOS Golden Gate Beta. After entering the account password at the SFUnlock screen,user has to click on Use Password button once and then click on the OK button to proceed to the desktop and for the login process to continue successfully. This behaviour is consistently reproducible in our testing. We would like to understand: 1.Is this a known issue with the current macOS Golden Gate Beta? 2.Is this expected behaviour due to the UI redesign, or is it considered a bug? 3.If it is a known issue, is there a fix planned for an upcoming beta or the final release? Any information or guidance would be appreciated. Thank you.

I’m implementing server-side App Attest validation and trying to verify my implementation against Apple’s published Attestation Object Validation Guide sample. I have already filed Feedback Assistant report FB24281098. Using only the values published in Apple’s sample, I can reproduce four apparent inconsistencies: Nonce calculation The documented procedure says to compute: clientDataHash = SHA256(clientData) and then: nonce = SHA256(authenticatorData || clientDataHash) Using the published server challenge, this produces: 1d1ce78912897de88cfe9fce5521aab37abfb09dc544833ff115612552cf75f3 However, the nonce contained in the sample certificate / published expected nonce is: 87b7d06d93a4294e46f011e66b6cc400f0bab20729976c619580b42ae60bff6e That value is reproduced when the raw challenge is appended to authenticatorData instead of SHA256(challenge). The block labeled “Expected clientDataHash” also appears substantially longer than a 32-byte SHA-256 digest. Public-key hash / key ID SHA256 of the leaf certificate’s X9.62 uncompressed P-256 public key is: ce0498f58483fbb4da0d7b2c63a5a538f552d4adcb9a4fa916195c49613e655d This matches the decoded key ID / credential ID from the attestation object. However, the separately published expected public-key hash is: 8a71a32b625b68012102c6300a7b36cd3c990f3b09dce2b1dd0da79f193e9a46 which appears to be SHA256 of the key-ID bytes instead. Bundle version The sample certificate extension contains the value "1", while the guide prose describes "1.0". Validation category The sample extension contains four bytes 01 00 00 00, while the guide describes the value as UInt32 category 1. I’m looking for clarification on the authoritative wire representation / parsing rule. Could Apple please confirm the authoritative byte-level behavior for these four fields, particularly: whether the nonce must use SHA256(clientData) as documented; whether the key ID must equal SHA256 of the X9.62 uncompressed public key; the exact bundle-version comparison rule; and the canonical validation-category representation? I’m intentionally avoiding accepting multiple interpretations or adding fallback behavior in a security-sensitive server verifier, so clarification from Apple would be greatly appreciated.

Hello, We have an enterprise application that provides a security agent plugin with custom UI based on SFAuthorizationPluginView. We’ve been testing it on macOS 27 Developers Betas 1 through 4 and we noticed that if we set screenUnlockMode to 2, then after a screen is locked for the second time during one session, it can no longer be unlocked. Here are the concrete steps to reproduce: Open Terminal. Run sudo defaults write /Library/Preferences/com.apple.loginwindow.plist screenUnlockMode -int 2 Lock the screen. Observe the “You must enter the password to unlock the screen” dialog window. Enter the correct password and press OK. Lock the screen again. Expected result: The dialog “You must enter the password to unlock the screen” is displayed again. Entering the correct password unlocks the screen. Actual result: The screen is black with no visible UI. Rebooting the system seems to be the only way to leave this state. Displaying custom UI at the unlock screen is a part of our core functionality and it has been working fine with screenUnlockMode = 2 since at least macOS 14. I have filed a feedback FB23918474; if it is a known issue, please merge it with mine so that I can receive updates on the matter. In the meantime, do you have any suggestions on what can be done? Thanks.

I am seeing recurring DCError.invalidKey in my iOS app using App Attest, and I'am trying to determine whether throttling or a quota can be a contributing factor before we look further. Questions Are there rate limits or quotas on generateKey, attestKey, or generateAssertion — scoped per device, per key, or per app? I understand exact thresholds may not be published; what I'd mainly like to know is whether such limits exist and roughly what timing window they apply over. If a limit is hit, which error surfaces? Specifically, can throttling ever present as DCError.invalidKey, or would it always be serverUnavailable (or another distinct code)? Does calling the attestation flow repeatedly in a short window (e.g. several times within a few minutes from an onboarding sequence) risk triggering throttling or anti-abuse rejection? Am I right that generateAssertion is entirely on-device and therefore not subject to any server-side limit — i.e. only attestKey contacts Apple's servers? Is throttling one of the documented causes of invalidKey, or is invalidKey strictly a key-state error (key absent from the Secure Enclave, already attested, from a prior install, etc.)? Being able to rule throttling in or out would help us narrow the investigation considerably. Thanks.

Issue Summary We are seeing consistently high latency when calling DCAppAttestService.shared.attestKey(_:clientDataHash:). The call routinely takes 4–5 seconds in the development environment and 7–8 seconds in production. In contrast, other DeviceCheck operations execute very quickly on the same setup (e.g., DCDevice.generateToken takes ~100ms, and generateAssertion takes ~80ms). Environment Details Platform: iOS (reproduced on physical devices) Framework: DeviceCheck / App Attest Entitlements: com.apple.developer.devicecheck.appattest-environment set appropriately for each environment (development / production) Execution Flow: generateKey (or keychain lookup) $\rightarrow$ attestKey $\rightarrow$ generateAssertion Representative Timings (Development / Physical Device) ensureKey (keychain reuse): 5 ms generateDeviceToken: 91 ms attestKey (Apple API execution): 5,196 ms generateAssertion: 76 ms Total Wall Time: ~5,505 ms Steps to Reproduce On a physical iPhone, invoke DCAppAttestService.shared.generateKey() (or retrieve an existing keyId). Generate a client challenge hash (SHA256). Invoke attestKey(_:clientDataHash:completionHandler:) with the keyId and hash. Observe the multi-second delay before the completion handler returns the attestation statement. Questions & Guidance Requested Expected Baseline: Is 4–8 seconds for a successful attestKey call considered expected behavior for Apple’s attestation servers, or does this indicate an anomaly? Environment & Regional Latency: Are there known factors (e.g., server geographic routing, network handshakes, or environment differences) that cause attestKey to be noticeably slower in production compared to development? Mitigation / Best Practices: Since attestation is recommended once per key/device lifecycle upon key generation, are there specific architectural patterns Apple recommends to avoid blocking UI or onboarding flows during this high-latency step? Note: We can supply full sysdiagnose logs, device model/iOS version breakdowns, and code snippets if required.

We have a macOS Authorization Plugin that reads and writes data from login.keychain-db during the login flow (logout→login scenario). On macOS 26.6, SecKeychainUnlock consistently fails in the pre-session context — before the user session is established. Error returned: Error Domain=NSOSStatusErrorDomain Code=-25293 "errSecAuthFailed: The username or passphrase you entered is not correct." However, the error message is misleading. We tested four combinations on macOS 26.6 to isolate the exact cause: Active session + correct password → Success Active session + wrong password → -25293 Pre-session + correct password → -25293 Pre-session + wrong password → -25293 In the pre-session context, macOS 26.6 returns -25293 for both correct and wrong passwords identically. This strongly suggests macOS is not evaluating the password at all in that context — the failure happens before password validation, likely because the session-bound material required to unlock login.keychain-db does not exist yet when the auth plugin runs. Key observations: The same code works correctly on macOS 26.3.1 and 26.5.1 — SecKeychainUnlock succeeds with the correct password in the pre-session context on those versions. The issue is specific to macOS 26.6. The file path /Users//Library/Keychains/login.keychain-db is unchanged — we get -25293 (auth failed), not -25294 (no such keychain), confirming the file is found and opened correctly. SecKeychainUnlock(ref, 0, NULL, NO) also fails for login.keychain-db in both pre-session and active session contexts. System.keychain with SecKeychainUnlock(ref, 0, NULL, NO) continues to work correctly in the pre-session context on macOS 26.6. Questions: Has the protection model for login.keychain-db changed in macOS 26.6 such that it can no longer be unlocked viaSecKeychainUnlock in a pre-session authorization plugin context? Is this an intentional security hardening change, or a regression? Is there a supported API or entitlement for authorization plugins to access login.keychain-db before the user session is established? Does the modern Data Protection Keychain (SecItemCopyMatching/SecItemAdd with kSecUseDataProtectionKeychain: @YES) work correctly in the authorization plugin pre-session context on macOS 26.6? If yes, is migrating to that API the recommended approach? Note: We are aware that SecKeychainUnlock is deprecated. We are actively evaluating migration to the modern Data Protection Keychain API, but understanding whether this is an intentional change, would help us choose the right fix approach.

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.