Following the pinned post "Gathering required information for troubleshooting Private Email Relay with Sign in with Apple" (thread 794191, which is locked, so I am posting here as instructed): I have filed FB24564316 with the required information. Since 28 July, every message from our app's sending domain to @privaterelay.appleid.com addresses is rejected by iCloud Mail with 554 5.7.1 [HM08], so users who signed up with Sign in with Apple and Hide My Email cannot receive their sign-in emails. Plain-text messages with no URL bounce as well, SPF/DKIM/DMARC pass on two independent sending systems, and external reputation checks are clean, so this looks like a false positive on the sending domain. The feedback contains the App ID (6761705463), Services ID, SMTP error codes and transaction IDs. iCloud postmaster case 21382576 and Developer Support case 20000139732014 did not resolve it. Happy to provide message headers. FB24564316

Sign in with Apple has failed for every user of our app for four weeks. It fails inside Apple's own authorization sheet, before any credential reaches our code. App ID: com.chorestoreapp.app (SJRRC8Q327) Team ID: T4KD7949GL App Apple ID: 6797335710 — TestFlight builds 7 and 8, version 1.0.1 Symptom: The authorization sheet appears and behaves normally. When the fingerprint read is complete, it immediately fails with "Sign Up Not Completed". No credential is returned. When I cancel, it returns ERR_REQUEST_CANCELED, consistent with the sheet being dismissed by the user after being unable to sign in. Sign in with Apple works on the affected device and Apple ID. Downloading an unrelated App Store app and creating a new account with Sign in with Apple succeeded immediately, on the same iPad, with the same Apple ID, minutes before and after a ChoreStore failure. Before that test, Settings → [name] → Sign in with Apple was empty, so the account had never completed the flow — it is demonstrably capable of it now, for other apps. Reproduced with: two Apple IDs, two physical devices, both "Share My Email" and "Hide My Email", Wi-Fi and cellular, and two builds on freshly regenerated credentials. Verified on our side: The signed binary contains com.apple.developer.applesignin = ["Default"] The embedded provisioning profile includes the same entitlement App ID capability, read back from the App Store Connect API: APPLE_ID_AUTH with [{"key":"APPLE_ID_AUTH_APP_CONSENT","options":[{"key":"PRIMARY_APP_CONSENT"}]}] Provisioning profile IOS_APP_STORE, state ACTIVE, expires 2027-08-20 Distribution certificate valid to 2027-08-20 Exactly one bundle ID in the account; no grouped App ID The client call is the standard one, with no nonce or custom parameters: signInAsync({ requestedScopes: [FULL_NAME, EMAIL] }) The distribution certificate and App ID survived an Individual → Organization conversion unchanged (re-verified after the conversion) Why I'm posting rather than filing a code-level request. The request form requires a focused sample Xcode project. A sample cannot demonstrate this: anyone who opens it must sign it with their own team, which changes the App ID — the one variable that is failing. The fault appears to be server-side provisioning for this specific App ID, which no sample can carry. Question: Given the client configuration verifies correct and Sign in with Apple works on the same device and Apple ID for other apps, what would cause the authorization sheet itself to fail for a single App ID, and how can that be investigated or reset? Happy to provide a sysdiagnose, timestamps of specific failed attempts, a screen recording showing the working and failing cases minutes apart, or a TestFlight build.

Feedback Assistant: FB24556583 Please inspect Sign in with Apple server-side registration for Team LQR9X2NWFT / App ID com.kanca.kanca. This is not a client-code or JWT issue. It is blocking App Store review (Guideline 2.1(a)). NATIVE Bundle ID: com.kanca.kanca App Store id: 6804206744 ASAuthorizationController / Flutter sign_in_with_apple. System sheet opens (Hide My Email), Face ID succeeds, then Apple's sheet shows Sign Up Not Completed. No identity token reaches the app. The app does not appear under Settings > Sign in with Apple. Reproduced for days. App Review reproduced it on iPhone 17 Pro Max iOS 26.6 and iPad Air 11-inch M3 iPadOS 26.6. App ID has Sign in with Apple enabled as a primary App ID. Capability re-saved; no change. Same Apple ID completes Sign in with Apple in other teams' apps on the same device. WEB Services ID: com.kanca.kanca.web GET https://appleid.apple.com/auth/authorize?client_id=com.kanca.kanca.web returns invalid_client before any login form (also via curl; no JWT involved). Dummy POST to /auth/token with a valid ES256 client_secret (iss=LQR9X2NWFT, sub=com.kanca.kanca.web, kid=KKYD9GMJS6) and a fake code returns invalid_grant, so the key/JWT/client_id are accepted at the token endpoint. Authorize still reports client not found. Please repair SIWA registration for this team/App ID. Happy to attach a sysdiagnose if needed.

https://feedbackassistant.apple.com/feedback/24553094 Security.framework returns NULL from SecPolicyCreateSSL when the directory containing the running executable no longer exists. That commonly happens with "go run" after the go command deletes its temporary build directory while a child process is still running. More details on how to reproduce: https://github.com/golang/go/issues/68557 Golang team rejected my workaround https://github.com/golang/go/pull/80471/changes so we're relying on the macOS team to allow this, unless of course there is a great reason not too. This is problematic when developing applications in golang, especially daemons.

Sign in with Apple for the web returns invalid_client at the authorization request for every Services ID in our team. The failure occurs before any token exchange, so no client secret is involved. Team ID: UGZTH42J5G Primary App ID: UGZTH42J5G.com.nearbuddy.mobile (Sign in with Apple enabled; "Enable as a primary App ID" selected) Services IDs: com.nearbuddy.mobile.signin com.nearbuddy.mobile.signin2 (created solely as a control) Both Services IDs are configured with: Sign in with Apple: enabled Primary App ID: UGZTH42J5G.com.nearbuddy.mobile Domain: dkhtjkcygbpomaummdih.supabase.co Return URLs: https://dkhtjkcygbpomaummdih.supabase.co/functions/v1/auth-apple-web/callback https://dkhtjkcygbpomaummdih.supabase.co/auth/v1/callback Failing authorization request: GET https://appleid.apple.com/auth/authorize client_id=com.nearbuddy.mobile.signin redirect_uri=https://dkhtjkcygbpomaummdih.supabase.co/functions/v1/auth-apple-web/callback response_type=code id_token response_mode=form_post scope=name email state= nonce= Apple responds with: invalid_client Invalid client. The same failure is reproduced: with both Services IDs; in Safari; in Chrome on Android; via curl; and using the authorization URL generated by Supabase GoTrue. The failure occurs before authentication/consent and before any authorization code or ID token is issued. Membership is active until March 18, 2027. The Account Holder is active and there are no pending membership or agreement banners. A fresh control Services ID reproduces exactly the same failure. Feedback Assistant report: FB24549460 Please inspect the Sign in with Apple provisioning/configuration state for Team UGZTH42J5G and determine why the registered Services IDs are not being recognized at the authorization endpoint.

What is the rationale for not including support for ML-DSA-44 in Apple CryptoKit?

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?

I’m looking for the documented Security.framework/macOS contract for this exact same-process sequence. An app creates a P-256 private key with SecKeyCreateRandomKey using: kSecAttrKeyType = kSecAttrKeyTypeECSECPrimeRandom kSecAttrKeySizeInBits = 256 kSecAttrTokenID = kSecAttrTokenIDSecureEnclave and, within kSecPrivateKeyAttrs: kSecAttrIsPermanent = true kSecAttrApplicationTag = <a unique tag> The app keeps the SecKeyRef returned directly by SecKeyCreateRandomKey alive and copies the corresponding public key with SecKeyCopyPublicKey. The app calls SecItemDelete with a query that uniquely matches that exact keychain item, and SecItemDelete returns errSecSuccess. Immediately after SecItemDelete returns, in the same process and without releasing or reacquiring the private-key reference, the app attempts a private-key operation using that same creation-returned SecKeyRef. Does errSecSuccess contractually guarantee that the already-retained SecKeyRef can no longer perform private-key operations from the point SecItemDelete returns? More concretely, is the following outcome forbidden by the API/platform contract: SecKeyCreateSignature succeeds after deletion, and the resulting signature verifies with the public key copied before deletion—that is, the public key from the same generated key pair? Or is invalidation of an already-issued SecKeyRef unspecified or otherwise not guaranteed by Security.framework? I’m asking only about the immediate post-return usability of the creation-returned SecKeyRef in this exact sequence. A clarification from Apple staff distinguishing the supported API/platform contract from current implementation behavior would be especially helpful.

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.

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.

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.

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.

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.

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

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.

We urgently need a response from the relevant authorities

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?