General: Forums topic: Privacy & Security Apple Platform Security support document Developer > Security Enabling enhanced security for your app documentation article Creating enhanced security helper extensions documentation article Security Audit Thoughts forums post Cryptography: Forums tags: Security, Apple CryptoKit Security framework documentation Apple CryptoKit framework documentation Common Crypto man pages — For the full list of pages, run: % man -k 3cc For more information about man pages, see Reading UNIX Manual Pages. On Cryptographic Key Formats forums post SecItem attributes for keys forums post CryptoCompatibility sample code Keychain: Forums tags: Security Security > Keychain Items documentation TN3137 On Mac keychain APIs and implementations SecItem Fundamentals forums post SecItem Pitfalls and Best Practices forums post Investigating hard-to-reproduce keychain problems forums post App ID Prefix Change and Keychain Access forums post Smart cards and other secure tokens: Forums tag: CryptoTokenKit CryptoTokenKit framework documentation Mac-specific resources: Forums tags: Security Foundation, Security Interface Security Foundation framework documentation Security Interface framework documentation BSD Privilege Escalation on macOS Related: Networking Resources — This covers high-level network security, including HTTPS and TLS. Network Extension Resources — This covers low-level network security, including VPN and content filters. Code Signing Resources Notarisation Resources Trusted Execution Resources — This includes Gatekeeper. App Sandbox Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

General: Forums topic: Privacy & Security Privacy Resources Security Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

CANT SOMEONE HELP ME SOMEONE STARTED THIS ACCOUNT WITHOU ME KNOWING NOW I CANT GET BACK THE ACCOUNT ITS ALSO ACROSS MULTIPLE PLATFORMS PLEASE I NEED HELP MY THIS IS A SERIOUS SECURY BREACH THEY CONTROL THIS WHOLE ACCOUNT AND JUST HERE POWERLESS

Hi Apple Developer Technical Support, We have a locally signed macOS system daemon that an administrator starts manually. It needs to use a dedicated P-256 signing key in a file-based keychain. We want macOS to let only the exact approved build use that key, without a prompt. A different build signed with the same certificate should be denied. Apple’s published Security source shows that the keychain can identify some callers by their code directory hash (cdhash). Is setting a key’s partition list to that exact hash a supported way to enforce this restriction for a system daemon? If so, which macOS versions support it, and what API or Apple tool should we use to configure it? After setup, how can we verify that the intended key has the exact restriction in place, including whether any broader rule allows another process to sign with the key, export it, or change its access rules? If macOS doesn’t offer a supported way to set and verify this restriction, please confirm that limitation.

Hi all. I'm a solo developer of an iOS fitness app and I just got rejected under Guideline 5.1.2(i). I'd really appreciate some guidance, because I think I understand the rejection but I'm not sure of the right way to handle it. Here's what App Review said: "The app does not use App Tracking Transparency to request the user's permission before collecting data used to track them. Instead, the app displays a custom prompt that requests the user to allow tracking." The prompt they're talking about is a sheet I show that asks "Share usage data?" and lets the person say yes or no. Nothing is sent to our analytics provider unless they say yes. The reason I'm confused is that I don't think my app tracks anyone by Apple's definition (and a few other posts I saw online say that PostHog doesn't fall under this category). The way I read it, tracking means linking data from my app with other companies' data for targeted advertising or ad measurement, or sharing it with data brokers. My app: - Has no ads and no ad SDKs - Doesn't use the advertising identifier (IDFA) - Doesn't combine user data with other companies' data - Doesn't share data with data brokers - Declares no tracking in its privacy manifest and App Privacy label The prompt is only for product analytics through PostHog, so I can see things like which screens and features get used. Those events are tied to a random account ID. They don't include workout totals, health readings or cycle data. I asked for permission because I thought it was the right thing to do for a health and fitness app, and because Guideline 5.1.2(i) says to get permission before sharing data with third parties. It seems like the prompt may have been read as asking to track, when it's really asking for permission for analytics that aren't tracking. My plan for the resubmission is to remove the prompt, explain that in my notes, and leave a switch in Settings that's off by default. The downside is that almost nobody will ever turn it on, so I'd have very little data on how people use the app. My questions: 1. Is a custom prompt allowed when it asks permission for first-party product analytics and not tracking? Has anyone gotten one approved, and did specific wording or a note to App Review help? 2. If the app really doesn't track, is removing the prompt and explaining that in the review notes the right way to resolve this? 3. Would it be wrong to use the App Tracking Transparency prompt here? My understanding is that it's only for apps that actually track, and using it would wrongly suggest that mine does. 4. Is an off-by-default switch in Settings enough permission for analytics like this? Or is there a better way to ask that App Review is comfortable with? If anyone has been through this, or anyone from Apple can point me in the right direction, I'd really appreciate it. I want to do this the right way. Thanks!

Overview We are investigating repeated "login" Keychain prompts affecting our macOS application on macOS 26.6.x. The issue appears after upgrading an existing installation. A clean uninstall/reinstall of the same version resolves it. Changing the affected Keychain item's Access Control from "Confirm before allowing access" to explicitly allowing our application/process also stops the prompts. On one affected machine, Apple Support observed a securityd crash followed by: SecKeyCreateSignature failed CSSMERR_DL_INVALID_DB_HANDLE Our code uses some legacy SecKeychain* APIs, so we are currently investigating whether this is related. Questions Were there any changes in macOS 26.6.x around securityd, Keychain ACL handling, or legacy SecKeychain* APIs that could explain this? Could an existing Keychain ACL become stale after an application upgrade, even when both versions are signed with the same Developer ID?

Hello Apple Developer community, I'm investigating an unexpected metadata representation returned by Apple's Security framework while inspecting an existing Secure Enclave-associated Keychain item on macOS. A read-only inspection using SecItemCopyMatching returns one matching key record with a successful status, a Secure Enclave token identifier (com.apple.setoken), and a 256-bit key size. However, direct Core Foundation type inspection reports: kSecAttrKeyType: CFNumber kSecAttrKeyClass: CFNumber kSecAttrSynchronizable: CFNumber The raw Core Foundation observations and bridged observations agree. Our current validator rejects these unexpected types and returns UNSUPPORTED_OR_INCOMPLETE_METADATA. We have deliberately stopped further key operations pending clarification. Questions: Can these CFNumber values legitimately appear in a dictionary returned by SecItemCopyMatching for Secure Enclave-associated key items on macOS? What returned value types should be expected for these three attributes, and are they dependent on the query or Keychain implementation? Is there an Apple-recommended way to normalize or validate these attributes without incorrectly accepting incompatible metadata? How should an application distinguish an existing Secure Enclave-backed key from an incomplete or unsupported Keychain record without performing a private-key operation? Are there relevant Security framework documentation references or known implementation differences we should consult? Our aim is to validate the existing record safely without regenerating, deleting, or using the private key. Thank you for your guidance.

Hello everyone, I'm trying to understand the actual limitations of the Secure Enclave (SEP) regarding cryptographic key capabilities, and more specifically how to generate and store the following key types in the keychain: Sign only: The key can only be used for digital signatures. Key agreement only: The key can only be used for key agreement operations. All operations: The key can be used for both signing and key agreement. I've noticed some apparent differences between Apple's Security framework and CryptoKit, and I'm trying to understand whether these differences reflect actual SEP limitations or simply framework-level restrictions. 1. Security framework: dual purpose keys I'm currently using SecKeyCreateRandomKey to generate Secure Enclave-backed keys. Here is the relevant code: NSDictionary *privateAttributes = @{ (__bridge id)kSecAttrIsPermanent : @YES, (__bridge id)kSecAttrAccessControl : ..., (__bridge id)kSecAttrApplicationTag : ..., // key agreement only (__bridge id)kSecAttrCanSign: @NO, (__bridge id)kSecAttrCanDerive: @YES }; NSMutableDictionary *attributes = [ @{ (__bridge id)kSecAttrKeyType : (__bridge id)kSecAttrKeyTypeECSECPrimeRandom, (__bridge id)kSecAttrTokenID : (__bridge id)kSecAttrTokenIDSecureEnclave, (__bridge id)kSecAttrKeySizeInBits : @256, (__bridge id)kSecPrivateKeyAttrs : privateAttributes } mutableCopy ]; CFErrorRef generationError = nullptr; SecKeyRef privateKey = SecKeyCreateRandomKey( (__bridge CFDictionaryRef)attributes, &generationError );However, when experimenting with these attributes, I encountered the following error: SecKeyCreateRandomKey failed: Error Domain=NSOSStatusErrorDomain Code=-50 "Failed to generate keypair" Underlying error: Error Domain=CryptoTokenKit Code=-8 "sepkey: sign requires '1' value when present"Using signing-only attributes results in the same kind of error. This makes me wonder whether the Security framework actually allows generating (and adding entries in the keyChain) only keys with both capabilities enabled. It is possible to create siging only key or key agreement only key with Security framework? 2. CryptoKit: Separate key types On the other hand, CryptoKit seems to expose two distinct Secure Enclave key types: P256.SecureEnclave.Signing.PrivateKey P256.SecureEnclave.KeyAgreement.PrivateKeyFrom the API design, it appears that CryptoKit only allows creating keys dedicated to one operation or the other. For example, a Signing.PrivateKey cannot be used for key agreement, and a KeyAgreement.PrivateKey cannot be used for signing. Is it possible to create both capabilities keys with CryptoKit framework? 3. Actual Secure Enclave limitations What are the actual cryptographic capability limitations imposed by the SEP itself? I'd particularly like to understand which restrictions originate from: The Secure Enclave hardware. Security and CryptoKit frameworks. Is there a documented way to generate and store in the keychain: A signing-only Secure Enclave key? A key-agreement-only Secure Enclave key? A Secure Enclave key supporting both operations? Thanks in advance, Idopte

Hi, I'm trying to understand how the new OpenID authentication in macOS 27 behaves after a user resets their password in the identity provider. I understand that Microsoft Entra ID does not currently support the new OpenID Platform SSO flow in macOS 27. I'm using Entra ID only as an example here, my question is about the general macOS behavior and should apply equally to other identity providers such as Okta, Google Workspace, or any other IdP that implements the required Platform SSO 2.0 / OpenID support. Example: Mac is configured with Platform SSO and AuthenticationMethod = OpenID FileVault is enabled the user already has an existing local account and login Keychain the user resets their IdP password remotely they no longer remember the old local Mac password at the next Mac login they authenticate successfully using the new OpenID web login What happens next? If AllowWebLoginPasswordSync is enabled, I understand that macOS can synchronize the new IdP password to the local Mac account. My main question is what happens to the existing Keychain. Does macOS preserve the existing login.keychain and its contents, or can the user lose access to it because the old local password is no longer known? I'm also interested in what happens to things that depend on the existing Keychain, for example: saved application credentials certificates and private keys Wi-Fi credentials Apple Account / iCloud sign-in state And how does Platform SSO 2.0 Key Service fit into this? Apple documentation says that Key Service can unlock the user's key bag before login. Does that also help preserve access to the existing login Keychain when the old local password is no longer available? In practical terms, I'm trying to understand whether macOS 27 finally supports this workflow without losing user data or credentials: User forgets the Mac password → resets their IdP password → signs in through OpenID → continues using the same Mac profile and Keychain normally. Thanks :)

We are interested in using a hardware-bound key in a launch daemon. In a previous post, Quinn explicitly told me this is not possible to use an SE keypair outside of the system context and my reading of the Apple documentation also supports that. That said, we have gotten the following key-creation and persistence flow to work, so we have some questions as to how this fits in with the above. (1) In a launch daemon (running thus as root), we do: let key = SecureEnclave.P256.Signing.PrivateKey() (2) We then use key.dataRepresentation to store a reference to the key in the system keychain as a kSecClassGenericPassword. (3) When we want to use the key, we fetch the data representation from system keychain and we "rehydrate" the key using: SecureEnclave.P256.Signing.PrivateKey(dataRepresentation: data) (4) We then use the output of the above to sign whatever we want. My questions: in the above flow, are we actually getting a hardware-bound key from the Secure Enclave or is this working because it's actually defaulting to a non-hardware-backed key? if it is an SE key, is it that the Apple documentation stating that you can only use the SE with the Data Protection Keychain in the user context is outdated (or wrong)? does the above work, but is not an approach sanctioned by Apple? Any feedback on this would be greatly appreciated.

The issue below affects every partner app embedding our SDK, so we'd appreciate DTS taking a deeper look. We're happy to open a code-level support request and provide screen recordings and a sysdiagnose. Details are in FB25326312. We ship an SMS filtering SDK (a Message Filter app extension) that partner apps embed. Password AutoFill is treating the SDK's messagefilter: associated domain as a credential domain for the host app, so unrelated saved logins appear on the partner app's sign-in screen. Configuration Apple validates Message Filter network deferral against the containing app (an unauthorized containing app gets ILMessageFilterError.Code.networkURLUnauthorized), so the entitlement must be declared on each host app, not the extension: messagefilter:messagefilter.example.comThe AASA file at messagefilter.example.com lists the host app IDs under messagefilter only. It has no webcredentials key. Network deferral works as expected. (The real domain is in FB25326312.) Observed behavior On the host app's sign-in screen, saved logins for the SDK provider's domain (example.com) are suggested in the QuickType bar and the QuickType suggestions list: No webcredentials: domain: only example.com logins are suggested. App's own webcredentials: domain added (valid AASA entry): the app's logins appear, but example.com logins are still suggested alongside them. Password managers Reproduces with Apple Passwords and third-party password managers (tested with 1Password, Dashlane, and Norton Password Manager): Credential providers appear to receive the messagefilter domain in the serviceIdentifiers array passed to prepareCredentialList(for:). Some use only the first identifier, others use all of them. QuickType suggestions come from iOS itself, so the unrelated credentials appear regardless of which password manager is used. Seen on iOS 26 and iOS 27 in a production partner app. Questions Is it intended that a messagefilter: domain contributes to Password AutoFill credential matching? Is there a supported way to exclude it from AutoFill without breaking Message Filter network deferral?

Our iOS app uses shm_open to create an app-owned, App Group-scoped POSIX shared-memory object. Before allowing access to previously authorized offline data, we call fstat on its file descriptor to verify the object's size, owner UID, and permission mode. We do not access file timestamps, use this information for fingerprinting, or send the metadata off-device. Apple's approved reason C617.1 refers to files inside app or App Group containers. However, POSIX shared-memory objects have no filesystem entry. Does C617.1 cover this specific use of fstat? If not, should we request a new approved reason?

Hi, are there any known issues with delayed iCloud Keychain synchronization to macOS? I have an app for iOS and macOS that supports creating, reading, updating, and deleting synchronizable Keychain items. Both versions are signed with the same Team ID, and all test devices are signed in to the same Apple Account. I’m observing a significant difference depending on the direction of synchronization: macOS → iOS: approximately 30 seconds. iOS → other iOS devices: approximately 30 seconds. iOS → macOS: approximately 30 minutes, with some variation. Changes eventually appear on the Macs, but incoming updates take much longer. Is this expected behavior, a known issue, or something that could be caused by my implementation? What diagnostics would help investigate it? Devices are on iOS 26 and macOS 26.

I am preparing a data-preserving, same-bundle-identifier update of my own development-signed iOS/iPadOS app (Target Keeper). Existing installations contain records that must be preserved. No update has been attempted, and no Keychain loss or entitlement incompatibility has been demonstrated. Environment: iOS/iPadOS 27.0.1 and Xcode 27.1. The original signed packages/archives for the installed older builds are no longer available. The proposed update has a valid Development signature and a profile covering the test devices. Its signed application identifier, Team identifier and Keychain groups have been inspected locally. The current and a retained later source snapshot use a bundle-derived service and a generic-password query without an explicit kSecAttrAccessGroup, with kSecAttrSynchronizable false and WhenUnlockedThisDeviceOnly accessibility. However, those source snapshots are not authenticated as the source used to produce the older installed binaries. I am therefore not assuming they prove the older effective groups or App ID prefix. I have read Sharing access to keychain items among a collection of apps, TN2415, QA1726, TN2311, and SecItem: Pitfalls and Best Practices: https://developer.apple.com/documentation/security/sharing-access-to-keychain-items-among-a-collection-of-apps https://developer.apple.com/library/archive/technotes/tn2415/_index.html https://developer.apple.com/library/archive/qa/qa1726/_index.html https://developer.apple.com/library/archive/technotes/tn2311/_index.html https://developer.apple.com/forums/thread/724013 These explain the access-group rules, first-group default and service/query distinctions. My remaining question is how to obtain authoritative evidence for the already-installed older app when its original signed package is missing. Is there a supported Xcode, Device Hub, devicectl or other Apple workflow to read/authenticate the effective application-identifier, Team and keychain-access-groups (including relevant App Groups) of an existing development installation without replacing it or extracting any Keychain values? If a local provisioning/install receipt can help, what establishes that it belongs to the installed binary rather than merely showing what a candidate profile permits? If no supported read-only method exists, what minimal controlled diagnostic does Apple recommend to qualify same-app Keychain continuity while preserving the original installation? Please distinguish methods requiring app launch/debugger attachment from genuinely read-only device-management inspection. Available app metadata and an exported app-data container have not supplied a signed entitlement list in the checks performed. Matching the candidate Team and bundle ID alone is not being treated as proof. A cross-bundle shipping migration is a separate problem and is not being attempted here. I am not asking to bypass code-signing or Keychain access controls, broaden access groups, uninstall the old app, or dump credentials. No passwords, certificates/private keys, device identifiers, backup files or application records are attached.

I'd like to prevent an attacker who uses a jailbroken iPhone or iPad from reading the contents of the Keychain of my app. Is there any point in using the Secure Enclave to generate a public-private key pair if an attacker with a jailbroken device can easily attach a debugger to my app, read from the Keychain of my app and also request decryption via the Secure Enclave while appearing to the Secure Enclave as my genuine app? Doesn't the whole security of the Keychain stand on the assumption that an attacker cannot attach a debugger to my app? Is there really no reliable way how to prevent someone from attaching a debugger to my app? I think that using PT_DENY_ATTACH is very easily bypassed by attackers. I don't mind if someone attaches a debugger to a re-signed version of my app, because such re-signed app would have a different Team ID, so the Secure Enclave would fail when attempting to use the key generated by my genuine app. I just want to prevent the situation when an attacker could read from the Keychain of my app and request the Secure Enclave to apply the private keys which were generated by my genuine app. Is the Keychain and the Secure Enclave essentially worthless on jailbroken devices if a determined attacker wants to take control of my app running on their jailbroken device?

in this weeks i received this error: ITMS-91055: Invalid API reason declaration - The PrivacyInfo.xcprivacy for the “VanigliaPro” file contains “App Functionality” as the value for a NSPrivacyAccessedAPITypeReasons key instead of a valid reason code for using an API in the NSPrivacyAccessedAPICategoryFileTimestamp category. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, values for NSPrivacyAccessedAPITypeReasons keys in your app’s privacy manifest must be valid reason codes for the corresponding API category. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api. ITMS-91053: Missing API declaration - Your app’s code in the “xxxx” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryUserDefaults. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api. ITMS-91053: Missing API declaration - Your app’s code in the “xxxx” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryFileTimestamp. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api. any help for make correct privacy file?

Hello Apple engineers and fellow developers, We plan to distribute our iOS / iPadOS games in Germany, France, Italy, Poland, Romania, and other EU countries. We would like to clarify whether the ATT changes introduced in iOS / iPadOS 27.2 require developers to adopt the new authorization API. We currently request tracking authorization using: ATTrackingManager.requestTrackingAuthorization(completionHandler:)We access IDFA only after the user grants ATT authorization. We reviewed the following official documentation: User Privacy and Data Use — ATT in the European UnionThis page states that, beginning with iOS / iPadOS 27.2, only the alternative ATT system prompt is available for apps distributed in the five countries listed above due to legal requirements. requestTrackingAuthorization(completionHandler:) — API DocumentationThe documentation states that the system presents a full-page sheet in these five countries when this existing API is called. Based on these documents, our understanding is that the existing API automatically presents the appropriate alternative ATT prompt in these countries. Therefore, developers do not need to migrate to the new API with the preferExpandedInterface and additionalInformationAction parameters solely to request authorization and access IDFA. Could you please clarify the following? Is this understanding correct? Can games distributed in these five countries continue using the existing API and access IDFA after the user grants authorization? Is adopting the new API also optional in other EU countries? If migration is mandatory, could you point us to the official requirement, applicable OS versions, and effective date? Our question concerns Apple’s ATT API integration and migration requirements, so we can plan the necessary SDK updates. Thank you for your help!

On macOS 27.0.1, SecItemCopyMatching returns -25293 (errSecAuthFailed) when a native app reads an existing login keychain item. We have verified that the app signature matches and that the user has added the app to the list of allowed applications. This occurs with user interaction disabled, and execution stops before connecting to the mail server. Is there an officially recommended diagnostic method to distinguish whether the cause is app authorization, the execution session, or the internal state of the keychain, without reading secret information, changing permissions, or unlocking the keychain?

Hello, We're a game studio. Our app has already been transferred from Team A to Team B, and no build has been released from Team B yet. We're now deciding how to handle guest accounts in the first update from B, and we'd like to confirm several platform behaviours before we commit to a plan. Current state The app is now owned by Team B. The build currently on the App Store was published while the app was still under Team A, and is the only build users have. No build has been uploaded or released from Team B — including TestFlight. The app signs users in either with a bound credential (phone number or third-party sign-in) or as a guest. A guest account has no recoverable credential: no email, no phone number, no third-party identifier. The only handle tying the user to their progress is a token stored locally on the device. That guest token is stored in the keychain under a plain keychain access group declared in the Xcode project: $(AppIdentifierPrefix)com.example.game.shared. It is not an App Group, and not an AGI keychain access group. The problem From "Overview of app transfer" we understand that keychain sharing "continues to work only until the app is updated", and that after the first update from B the token in the A-prefixed group will no longer be readable. For a user with a bound credential that's a single re-login. For a guest user it means the account becomes unreachable — there is nothing to re-login with. Their progress, purchases and inventory would be orphaned, and we have no way to identify them from the new build. So the first update from B is a one-way decision point for us, and we'd like to get it right. What we're evaluating Option 1 — Ship from B and carry the guest identity in the app container. If the app's sandbox container (Documents / Library / UserDefaults) survives an in-place cross-team update, we could read a guest identifier written there by the old build and exchange it server-side for a fresh B-prefixed token. No further transfer needed. This only helps users who update in place — anyone who deletes and reinstalls loses the container. Option 2 — Transfer back to A, ship a migration build, then transfer to B again. Have Team A publish a build that moves the token into an AGI keychain access group for a dedicated App Group ID, wait until most users have run it, then transfer the app back to B and transfer the App Group ID, as described in "App ID Prefix Change and Keychain Access". Option 3 — Dual-write now and accept loss for users who don't update in time. Our questions Q1 — App container across a cross-team update. Does an app's sandbox container (including UserDefaults, Library and Documents) persist when a user updates in place to a build signed by the recipient team? We can't find this stated anywhere, and Option 1 depends entirely on the answer. Q2 — identifierForVendor. Does identifierForVendor stay stable across an app transfer, i.e. when the signing team changes? We'd like to use it as a secondary anchor for guest accounts, but we're unwilling to rely on undocumented behaviour, and we can't find documentation either way. Q3 — Transferring back. Is transferring an app back to its original team supported? Are there restrictions we should know about — a cooldown, a cap on the number of transfers, or a requirement that the app meet the transfer criteria again? Specifically, if Team B has uploaded a build to App Store Connect but never released it (no App Store release, no TestFlight distribution), does that affect the app's eligibility to be transferred back? And when the app returns to A, is the App ID Prefix guaranteed to revert to the value it had originally, or can a team end up with a different prefix than it had before (for example on legacy accounts that hold more than one prefix)? Q4 — Keychain-only state. Given that the original build never declared an App Group, is there any supported way to recover items from an A-prefixed keychain access group once the app is owned by B and the next build is signed by B? We assume not, and that Option 2 is the only supported path — please confirm. Q5 — Recommended practice. Is there a recommended approach for migrating accounts that have no recoverable credential? We'd rather follow an established pattern than invent one. A separate question: certificate and profile expiry on Team A's side Team A's distribution certificate and provisioning profile will expire at some point, while the app stays under B without an update. We'd like to confirm that this has no effect on sign-in and no effect on payments for the version currently installed from the App Store. Reasoning that applies to both. The App Store re-signs the app during distribution, and the delivered build contains no embedded provisioning profile (TN3125), so neither A's certificate nor A's profile exists on the device. "Certificates overview" also states that an expired App Store distribution certificate does not affect existing App Store apps, and only prevents uploading new builds signed with it — which the transferor can no longer do in any case. Sign-in. Tokens — guest and bound alike — live in the keychain under the A-prefixed access group. Our reading is that certificate expiry has no bearing on keychain access at all, because the access check compares the group string in the binary's entitlements against the item's kSecAttrAccessGroup. The signing certificate isn't an input to that comparison. Is that correct? Payments. Our reading is that payments are unaffected on both sides: StoreKit transactions (purchase, renewal, refund) are handled by Apple's servers and don't depend on the app's signing certificate or provisioning profile; our server-side receipt validation relies on the app-specific shared secret — a 32-character hexadecimal string with no relationship to any certificate — so verifyReceipt and the App Store Server API keep working. Is that correct, or does something break here? One consequence we do care about. For Option 2 we'd need Team A to sign and publish that migration build. We assume A must therefore issue a new, valid certificate and profile before it can ship again — that is, expiry doesn't affect the installed app, but it does affect A's ability to publish anything further. Is that right? We also assume the App Store Server Notifications URLs configured for the app are unchanged by the transfer. Could you confirm that as well? Thanks!

I'm investigating the boundary between Documents TCC protection and the app-created-file/user-intent exceptions on macOS 27.0.1. This is a request for supported diagnostics and revocation guidance, not a claim of a security bypass. Paths and process labels below are anonymised; the trace summaries describe observations, not a complete reproducer. Observed behaviour With Documents access disabled for a ChatGPT/Codex desktop app in Privacy & Security, its direct file tool created a workspace directory under ~/Documents and a new text file inside it. The file and contents were independently verified in Terminal. After the workspace was deleted manually and its absence verified, the tool recreated the directory and another test file without a new consent prompt. Restarting the app did not prevent this. No access to unrelated, pre-existing personal documents has been established. An fs_usage capture during a successful test showed an open for writing followed by WrData[A] on the test path, attributed to a local process named codex. The numeric suffix in that capture has NOT been conclusively correlated to the executor PID; it should not be treated as proof of the exact process chain. Process and signing observations A separate launchctl procinfo inspection of a local Codex exec-server showed sandboxed = no, with the desktop app as its responsible process. This establishes the inspected executor's state, not necessarily the dynamic restrictions of the exact writer or its children. The desktop bundle identifier is com.openai.codex. The embedded CLI has signing identifier codex and application identifier 2DC432GLL2.com.openai.codex.cli. These are vendor identifiers, not account identifiers. Embedded entitlement XML was read directly from the Mach-O LC_CODE_SIGNATURE superblob, because codesign diagnostics inside a later restricted tool environment were inconclusive. The desktop executable declares com.apple.security.app-sandbox = false, com.apple.security.files.user-selected.read-write = true and com.apple.security.automation.apple-events = true. The CLI's embedded entitlements include its application/team identifiers and JIT/unsigned-executable-memory permissions, with no app-sandbox entitlement. These are embedded declarations, not a claim that runtime validation or every effective grant has been verified. Being outside App Sandbox does not itself remove TCC protection. TCC chronology Earlier, a Python operation attributed to com.openai.codex requested kTCCServiceSystemPolicyDocumentsFolder. Its AUTHREQ_RESULT had authValue=0 and authReason=2. A later log recorded deletion of a Documents TCC record for that app, before the successful Codex write. Thus the earlier Python denial does not establish the decision applicable to the later write. Filtered TCC logs around the successful write contained app identity information but no matching Documents decision; a sandbox-log search found no relevant entry. Those are search results, not proof that no security check occurred. Extended attributes and application policy The parent Documents directory had a 216-byte com.apple.macl; the workspace had a 72-byte com.apple.macl. The parent's attribute remained when the child directory was deleted, and the recreated child acquired an attribute again. The identities represented by those records and their causal role are unknown. A Codex task configuration separately allowed the workspace as writable. That explains an application-policy allowance, not automatically the macOS authorisation. Filename searches did not identify a definite security-scoped bookmark; that does not rule one out. TCC database queries were inaccessible. No Full Disk Access was granted to inspect them. Questions Apple's WWDC19 session 701 explains that creating new documents in protected locations needs no consent, and that apps can access files they created or the user selected: https://developer.apple.com/videos/play/wwdc2019/701/ Does that documented exception also explain creating/recreating a directory and then accessing its descendants while the Documents switch is off on current macOS? What supported read-only diagnostics distinguish app-created-item access, a parent-directory MACL grant, security-scoped bookmarks, dynamic sandbox extensions and TCC responsible-process attribution? Is there a supported way to revoke per-item/user-intent access? Does the Documents switch intentionally leave new-file creation possible? For a user who wants to prohibit all Documents writes while retaining the desktop app, is an independently enforced filesystem sandbox required? How should that boundary be tested across direct file tools, shell children and GUI automation? I would appreciate guidance before any further disposable-file tests, attribute changes or TCC resets. No general Documents bypass or access beyond the workspace has been demonstrated.

Hello, We have an app that was transferred from Team A to Team B. We are now considering transferring it back to Team A, and we would like to confirm what happens to the keychain items that the original Team A build wrote, before we commit to that plan. Current state The app is currently owned by Team B. No build has ever been released or distributed from Team B — no App Store release and no TestFlight distribution. Every user on the App Store is still running the build that Team A signed. The app stores a login token in the keychain under a plain keychain access group declared in the Xcode project: $(AppIdentifierPrefix)com.example.game.shared. It is not an App Group, and not an AGI keychain access group. Some of our users are guest accounts. A guest account has no recoverable credential — no email, no phone number, no third-party identifier — so the token in the keychain is the only thing tying them to their progress. The plan would be: transfer the app back to Team A, then have Team A create a new distribution certificate and a new provisioning profile, and ship a new build. Our understanding We read the documentation as follows. An access group is "a logical collection of apps tagged with a particular group name string", and each keychain item is "always part of exactly one group". The group name is the string declared in the entitlements with the App ID Prefix prepended — "Xcode automatically prefixes keychain groups with your team ID" — and that prefix is resolved at build time from the provisioning profile. Access is decided by comparing the group string in the binary's entitlements against the item's kSecAttrAccessGroup. If the group is not one the app belongs to, a write returns errSecMissingEntitlement and a read returns errSecItemNotFound. A provisioning profile's DeveloperCertificates property lists "the certificates of each developer who can sign code covered by the profile" (TN3125). So the certificate decides who may sign, not which access group the app belongs to. When the app is transferred back to Team A, its App ID returns to Team A, and therefore the App ID Prefix — and with it the group name — should be the same string as before. If all five hold, a new build signed by Team A with a newly issued certificate should still be able to read the items written by the original Team A build, and our guest users would not be affected at all. Our questions Q1 — Does the App ID Prefix revert? When an app is transferred back to its original team, is the App ID Prefix guaranteed to return to the value it had before? Or can a team end up with a different prefix than it had originally,This is the one step in our reasoning that we have not been able to find stated anywhere. Q2 — Does a newly issued certificate or profile have any bearing? Team A would create a new distribution certificate and a new provisioning profile rather than reuse the previous ones. Does that affect keychain access in any way? Our reading is that it does not, because the access check compares group strings and the signing certificate is not an input to that comparison. Could you confirm? Q3 — Are the original items still present and readable? Assuming no Team B–signed build ever reached any device, are the items written by the original Team A build still on the device and readable by a Team A–signed build after the round trip? "Overview of app transfer" says keychain sharing "continues to work only until the app is updated" — we read that as meaning the trigger is a build from the new team reaching the device, not the transfer itself. Q4 — Transferring back. Is transferring an app back to its original team supported? Are there restrictions we should know about — a cooldown, a cap on the number of transfers, or a requirement that the app meet the transfer criteria again? Specifically: if Team B has uploaded a build to App Store Connect but never released or distributed it, does that affect the app's eligibility to be transferred back? Q5 — Guest accounts. Because our guest users have no recoverable credential, "just ask the user to sign in again" is not available to them. Is there a recommended approach for this case that we should follow? Thanks!

Hello Apple Technical Support, We need a documented feasibility clarification before implementing a native macOS app running in the logged-in user's context. The app needs to generate and persist a software RSA 3072-bit private key in the Data Protection Keychain (DPK), for RS256 (RSASSA-PKCS1-v1_5 with SHA-256). The required properties are effective private-key non-exportability and signing-only use, enforced beyond our app's choice not to call export or other cryptographic operations. We also need a supported way to verify these properties without attempting any private-key export. We distinguish these requirements from access-group authorization, kSecAttrSynchronizable=false, ThisDeviceOnly accessibility, and hardware-bound keys. We recognize that access groups are a different boundary from exact CDHash/build exclusivity; we do not claim that exclusivity is satisfied. Group membership alone does not establish the requested key properties, including for another process legitimately entitled to the same group. Environment: recorded static header provenance is MacOSX27.0.sdk (Command Line Tools), not a successful build or runtime validation. Target macOS version and build: Apple M4, 16GB in memory, macOS Tahoe version 26.6.2. No DPK implementation or experiment is being submitted as evidence. Please clarify these four points: Is there an officially supported API/attribute combination to generate and persist this software RSA3072 key in DPK with enforceable non-exportability and signing-only use (no decrypt, unwrap or derive)? If yes, please identify the exact APIs, attribute placement and values, applicable macOS/SDK versions, and enforcement limits. Please distinguish actual key restrictions from requested attributes or app-side policy. How does that combination, if supported, relate to the generic macOS kSecKeyExtractable=false exception documented for SecKeyCopyExternalRepresentation [1], versus the Apple DTS explanation that raw bytes of standard DPK keys can be obtained through that API [2]? Does the exception apply to software RSA keys generated in DPK, or only to other key implementations? Please distinguish kSecKeyExtractable from kSecAttrIsExtractable where relevant. Which supported attributes, query APIs or other evidence establish effective non-exportability and signing-only restrictions without attempting export? Please specify whether SecKeyCopyAttributes or an item query guarantees the required fields for this key/store combination, and how absent or unsupported fields must be interpreted. We will not treat a missing field as false or infer enforcement from creation inputs. If this combination is not supported for software RSA in DPK, please confirm that limitation explicitly and distinguish it from hardware-bound keys. We are not asking to substitute Secure Enclave/EC or another algorithm, and do not assume hardware guarantees apply to software RSA. References: [1] SecKeyCopyExternalRepresentation https://developer.apple.com/documentation/security/seckeycopyexternalrepresentation(::) [2] Apple DTS reply (June 2023), Developer Forums thread 731001 https://developer.apple.com/forums/thread/731001 [3] TN3137: On Mac keychain APIs and implementations https://developer.apple.com/documentation/technotes/tn3137-on-mac-keychains [4] Protecting keys with the Secure Enclave https://developer.apple.com/documentation/security/protecting-keys-with-the-secure-enclave An applicable technical answer with references and limits, or an explicit statement that this combination is unsupported, would resolve the feasibility question. If support or a non-exporting verification method cannot be established, we will keep support NOT_ESTABLISHED and implementation blocked. A successful signature or access-group isolation alone would not close it. Thank you. fapontec