Our app signs users up through ASWebAuthenticationSession (not ephemeral). The sign-up page is a normal HTML form that posts to our server. When sign-up succeeds, the server redirects to our custom-scheme redirect_uri, which closes the session, as expected. When the user types a password and submits, iOS shows the "Save Password?" modal inside the session. From there, iOS 26 and iOS 27 behave differently: iOS 26.5: iOS waits. The form isn't sent until the user answers the modal. Then the request goes out, the redirect closes the session, and the password has been saved. iOS 27.0 and 27.2 beta 2: iOS doesn't wait. The form is sent right away, the redirect closes the session in under a second, and the modal disappears with it. The user never gets to tap Save. Things we checked: Same server, same page, same device, same app build. Only the iOS version changes the result. prefersEphemeralWebBrowserSession is off. Safari itself never waited on neither versions. The waiting only happened inside ASWebAuthenticationSession. Saving passwords still works on the device otherwise, and every test used a new account and password. Questions: Is the iOS 27 behaviour intended? If so, is there any supported way to let the user answer the sheet before the redirect closes the session? If it's a bug, is it tracked somewhere? The only fix we've found is to show an extra page after sign-up and only redirect from there, which adds a step for every user. We'd rather not ship that if the iOS 26 behaviour is coming back.

I’m investigating App Attest sandbox configuration for a native macOS app. Apple DTS suggested asking here. Environment: Physical MacBook running macOS 27.0.1 (26A434) Xcode 27.0 (27A266a) Native SwiftUI macOS application, launched from Xcode in Debug Development signing with a regenerated Mac development provisioning profile The same App ID is used for the iPad and Mac targets Observed behavior: App Attest is enabled for the App ID in the Developer portal. The Mac entitlements source requests: com.apple.developer.devicecheck.appattest-environment = development We tried both a build-setting substitution and the literal development value, regenerated the profile, and rebuilt. The inspected Mac provisioning profile does not contain this entitlement. Xcode’s generated signing entitlements (.xcent) and the signed application also omit it. DCAppAttestService generates a fresh key and returns an attestation successfully. Our development server observes AAGUID 61707061747465737400000000000000 (production) and rejects it because it requires development evidence. The physical iPad development build produces development evidence and enrolls successfully against the same server. Relevant server diagnostic: client App Attest environment mismatch expected_environment=development observed_aaguid=61707061747465737400000000000000 The failure occurs at the environment gate, before certificate/signature verification. I am not claiming that the entire Mac attestation has already passed cryptographic verification. Questions: Is development/sandbox App Attest supported for native macOS 27 apps? If supported, which entitlement and provisioning configuration is required, and why is the requested environment omitted during signing? If production-mode evidence is expected for development-signed Mac apps, what is the recommended server environment policy? Is this a known issue with macOS 27.0.1 or Xcode 27.0? We would like to keep development attestation separate from production while retaining full cryptographic verification and using the same App ID for both platforms. I can provide sanitized entitlement and signing-output excerpts, together with a minimal reproducer. Which diagnostics would help establish why the development entitlement is missing?

中国银联开发的APP（Nihao China，苹果应用市场链接为：https://apps.apple.com/cn/app/id1187814659）国际版APP通过苹果联登进行登录，银联后台这边是通过正向代理访问的苹果服务器，之前一直正常。但是从9月23日凌晨03：40分以后，访问均被苹果截断，请求中出现 CONNECT 104 RST问题报错。 银联侧后台日志如下： 2026/09/2410：38：30 [错误] 21363#21363： *17559374 recv（） 失败（104： 连接重置），代理和上游读取时，客户端：19.154.22.71，服务器：localhost，请求：“CONNECT appleid.apple.com:443 HTTP/1.1”，主机：“appleid.apple.com" 想确认，苹果是不是升级了网络访问的安全策略导致我们我们的访问连接被截断。以及我们如何处理该问题？ 附：银联侧正向代理后的出口IP地址如下： 电信地址 106.39.14.241 106.39.14.245 106.39.14.246 106.39.14.248 117.133.178.242 117.133.178.243 117.133.178.244 117.133.178.247 联通地址 106.39.14.242 106.39.14.243 106.39.14.244 106.39.14.247 117.133.178.241 117.133.178.245 117.133.178.246 117.133.178.248

I’m designing a dedicated local PostgreSQL service account on macOS 26.3.1. No account has been created. Design requirements: no usable human password credential, no ordinary interactive login, shell /usr/bin/false, home /var/empty, no SSH credential, and no admin/wheel membership or Secure Token/FileVault volume-owner role. Any eventual service execution would be separately controlled. These are desired properties, not claims about established macOS behavior. I’m seeking a supported provisioning and verification procedure. Direct disabled creation: What supported Apple API/tool and attribute representation can create a local service account directly in a DisabledUser state? Can this be established during initial creation, without an externally available enabled password-authenticating intermediate state? Credential absence: Can creation occur without ever assigning or storing a usable human password credential or equivalent authentication secret? Please distinguish no password, an empty password, an unknown/generated password, disabled password authentication, and a disabled account. An empty password is unacceptable for this design. DisabledUser scope: What authentication paths does it prevent on macOS 26.3.1—password authentication, GUI/console login, SSH password authentication, and other Open Directory-backed authentication? How does this differ from system-controlled process execution under the UID, including launchd execution using UserName/GroupName? Nonauthenticating verification: What supported read-only attributes, policies, or APIs establish that the account is disabled and lacks a usable password credential, without attempting authentication or exposing hashes/secrets? Does inspecting the disabled marker establish only account state, or also credential absence? Secondary clarification: Is pwpolicy disableuser still recommended for local accounts? Is DisabledTags;SecureToken relevant only to token issuance, and can a controlled daemon run under a disabled UID without enabling human authentication? Source basis APPLE_DOCUMENTED: AuthenticationAuthority documentation identifies DisabledUser as indicating a disabled account. APPLE_DOCUMENTED: ODNode documentation provides record creation with attributes; the reviewed material does not establish the requested creation-time guarantee. LOCAL_MANUAL_DOCUMENTED: The installed pwpolicy(8) describes disableuser; its complete current authentication-path scope remains unresolved. APPLE_DOCUMENTED: Secure/bootstrap-token guidance discusses token issuance separately from account authentication. APPLE_DOCUMENTED, ARCHIVED: Daemon guidance describes selecting service identities through launch configuration. Not yet established: a safe credential-free creation sequence, the state of every intermediate step, the complete disabling scope, and sufficient nonauthenticating verification. A create-then-disable sequence would not meet the requirements unless every intermediate authentication state is characterized.

For macOS 26.7.1 (25G241), Xcode 27.0 (27A266a), and macOS SDK 27.0, we request the supported, exact Info.plist schema for NSDataAccessSecurityPolicy: its value type, literal key names and nesting, item types, and identity-selector grammar. Can the policy allow only the owning process signed with a specific Team ID and signing identifier, without allowing all applications signed by that Team? Are cdhash or designated-requirement selectors supported, and how do process and installer/package identities differ? Please clarify the relationship to user consent and Full Disk Access exceptions, and confirm whether this configuration is supported for the macOS build listed above. Please provide primary documentation or an authoritative schema, rather than a schema inferred from NSUpdateSecurityPolicy.

For an existing iOS generic-password Keychain item, what documented public API or query contract can establish that its returned SecAccessControl has no additional authentication, application-password, or operation-specific constraints? The item must remain WhenUnlockedThisDeviceOnly, in an exact access group and identity, and non-synchronizing. An unknown or unverified item must be refused without modifying, deleting, or replacing it. An attribute-only creation with no explicit access-control object can return a SecAccessControl when data and attributes are read. We observed this on an iOS 26.5 Simulator. The returned object compared different from a freshly created zero-flags object. We are not treating either that comparison or a successful no-UI read as proof of its complete constraints. The public interface we reviewed exposes creation and type identification; constraint inspection and serialization appear in private headers. Evaluating one operation also does not describe the item's complete policy. Is there a supported discriminator we have missed? If not, is there a documented creation-provenance and persistent-item-identity contract that establishes this property across relaunch, and what limitations apply to existing or recreated items? Please clarify the supported contract rather than private implementation details. We need to preserve refusal of unverified existing items while using the public Keychain APIs correctly.

Hello, I am experiencing a persistent Sign in with Apple issue for our production web application, Sai＊aus. When Sign in with Apple is initiated using our registered custom-domain return URL, Apple returns: invalid_request Invalid web redirect url. Configuration: Services ID: com.saiaus.app.auth Production domain: sai-aus.com Registered Return URL: https://sai-aus.com/__/auth/handler We have verified that the redirect_uri sent in the authorization request exactly matches the registered Return URL. As a comparison test, using the Firebase-hosted handler URL https://sai-aus.firebaseapp.com/__/auth/handler with the same Services ID proceeds successfully to the Apple Account sign-in screen. The failure occurs with the registered custom-domain handler. We previously contacted Apple Developer Support regarding this issue: Support Case: 102958526964 Support Case: 102960544416 Feedback Assistant: FB24784951 We submitted the issue through Feedback Assistant as directed and also provided follow-up information, but the issue remains unresolved. We tested the production flow again on October 4, 2026, and the same invalid_request / Invalid web redirect url. error is still reproducible. Could an Apple engineer please review FB24784951 and advise why the registered custom-domain Return URL is being rejected while the Firebase-hosted Return URL works? Thank you.

I opened Apple Connect and was setting up a new app and when I go into App Groups, I see this! AltStore?? Cydia?? I didn't put those there, and Im the only one on my team. AltStore group com rileytestut AltStore group.com.rileytestut.AltStore.44K72272WR CY- group com cydia Extender group.CY-931DA672-818E-11E8-AED3-DB7934DE71C9.com.cydia.Extender CY- group lolwtf group.CY-36A1A27E-C8FB-11E6-AC51-975482641AE2.lolwtf

In the process of updating several Apple devices to OS 27.0.1, I accidentally updated my main workstation from Sequoia to Golden Gate. I had intended to do this, but not this soon. Now I find that the Keychain Access App no longer takes my login password to unlock items. Unfortunately, the Passwords App does not allow me to see a number of things that are stored in the Keychain Access App: e.g. Secure Notes. But in this case the problem is an application password for an IRC client. I have no way of recovering my IRC account unless I can supply the password to Keychain Access.

Hello Apple engineers, We are investigating an unresolved native Sign in with Apple failure in Rankids. Feedback FB24763387 contains the private reproduction details and Accounts/AuthKit sysdiagnose. The native Apple sheet displays "Sign in not complete" after biometric authentication and before returning any authorization credential. Both Share My Email and Hide My Email fail. We reproduced it on an iPhone and an iPad, while the same account can use Sign in with Apple in unrelated apps. The diagnostic build is TestFlight 1.0.9 (5). Accounts/AuthKit diagnostics show successful biometric authentication followed by AKAuthenticationServerError -24000 / "Invalid client.". The app receives ASAuthorizationError 1001 after the failed sheet is manually dismissed; that cancellation is not the original failure. No identity token reaches our app, so no backend token exchange takes place. The App ID capability was checked as enabled/Primary. The diagnostic binary and installed-device logs show the expected app/team identifiers and the Default Sign in with Apple entitlement. The app uses Expo Apple Authentication; we have not yet reproduced this in a separate minimal native Xcode project and are not claiming a confirmed server-side root cause. Could an Apple engineer advise whether the existing private diagnostics are sufficient to investigate the client rejection, and what additional evidence would distinguish an app configuration issue from an Apple-side registration issue? The code-level request form requires a focused Xcode project; guidance on the appropriate route for investigating the affected app registration would be appreciated. The production app currently uses email/password sign-in while we investigate. Account identifiers and full diagnostic files will remain in the private support channels. Thank you.

I'm using the code below. It functions correctly on iOS 27.2 Beta 1 but crashes on iOS 27.2 Beta 2. API implemented here Xcode version - Version 27.2 beta (27B5019j) iOS Version - iOS 27.2 Beta 1 and Beta 2 behavior App Store region - Germany if (@available(iOS 27.2, *)) { [ATTrackingManager requestTrackingAuthorizationUsingExpandedInterface:YES additionalInformationAction:^{ NSLog(@"[ATT] Additional Information Clicked"); } completionHandler:^(ATTrackingManagerAuthorizationStatus status) { NSLog(@"[ATT] completion status: %ld", (long)status); }]; Resulted in a crash at runtime. No error at compile time. *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[ATTrackingManager requestTrackingAuthorizationUsingExpandedInterface:additionalInformationAction:completionHandler:]: unrecognized selector sent to class 0x28f3d0f80' *** First throw call stack: (0x1998ee8e0 0x19966c380 0x1999ee444 0x1998aa774 0x1998aaa30 0x1020a3a60 0x102fc8558 0x102fe1df0 0x103003dd8 0x102fd8340 0x102fd8280 0x1998a0614 0x19989187c 0x1998927e4 0x24643df24 0x19da6db54 0x1020a5264 0x1996e35b8) libc++abi: terminating due to uncaught exception of type NSException *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[ATTrackingManager requestTrackingAuthorizationUsingExpandedInterface:additionalInformationAction:completionHandler:]: unrecognized selector sent to class 0x28f3d0f80' *** First throw call stack: (0x1998ee8e0 0x19966c380 0x1999ee444 0x1998aa774 0x1998aaa30 0x1020a3a60 0x102fc8558 0x102fe1df0 0x103003dd8 0x102fd8340 0x102fd8280 0x1998a0614 0x19989187c 0x1998927e4 0x24643df24 0x19da6db54 0x1020a5264 0x1996e35b8) terminating due to uncaught exception of type NSException

I’m seeking DTS guidance on supported ScreenCaptureKit usage and diagnostics for an intermittent authorization failure, filed as FB24757092. Captured evidence (my incident) On macOS 26.6.2 (25G83), Apple silicon, an already-authorized custom Apple Development-signed AltTabDebug build encountered renewed Screen Recording prompts. Unified logs show root tccd exhausting file descriptors during authorization. Three failing tccd processes each reported 255 total descriptors, with 250 unique descriptors referring to the same app executable. SecStaticCodeCreateWithPath failed with error 100024 (UNIX[Too many open files]); tccd could not match the existing kTCCServiceScreenCapture code requirement, and replayd reported TCC Disallow / user denied for captureScreenshot. Later checks allowed the same running app again. This confirms resource exhaustion and authorization failures. It does not establish why descriptors accumulated, a persistent leak mechanism, a per-capture leak rate, or a deterministic reproducer. The reported load spike and roughly one-second display freeze have an uncertain causal relationship to these failures. I have not established reproduction on macOS 27 or descriptor exhaustion in an unmodified release build. No incident-time sysdiagnose was collected. Separate upstream observations The AltTab maintainer reported testing the signed release in /Applications on the same OS build: 446 screenshots produced 1,350 ScreenCapture authorization requests, with repeated code-signature validation; approximately 23 ms of root-tccd CPU per thumbnail was reported. These are the maintainer’s measurements, not independently repeated by me, and do not measure descriptor growth per capture. https://github.com/lwouis/alt-tab-macos/issues/6025 https://github.com/lwouis/alt-tab-macos/issues/6025#issuecomment-5640382131 Questions Is there a supported ScreenCaptureKit capture pattern, request concurrency/rate guidance, or recovery strategy to reduce repeated authorization work and avoid renewed prompts when code validation fails from transient resource exhaustion? How should an app distinguish a genuine permission denial from an unavailable/failed authorization service, without repeatedly requesting permission? Which logging profile, trace, or incident-time diagnostics should we collect to correlate capture submissions/completions with tccd descriptor lifetime and isolate the accumulation mechanism? FB24757092 contains the focused timeline, descriptor dumps, prompt screenshot, and separately attributed maintainer findings. Raw diagnostics and private system/account information are intentionally omitted here. I built a standalone Swift/AppKit probe that uses one retained SCContentFilter per batch, logs submissions and actual callbacks, bounds outstanding requests, stops new submissions on the first error, and discards images. On macOS 27.0 (26A428), its ad-hoc-signed build captured its own window successfully in 446-request captureScreenshot batches at concurrency 1 and 4. This validates the harness, not reproduction of the original failure. The code-level form requests a focused project demonstrating the issue; this probe does not yet reproduce exhaustion. Could DTS advise the next isolation step and whether a private support case is appropriate for the existing evidence?

Title: Does identifierForVendor (IDFV) change after transferring an app to another Apple Developer account? We are planning to transfer an existing App Store app from one Apple Developer account/team to another using App Transfer. The app currently uses: UIDevice.current.identifierForVendor as one of the identifiers sent to our backend. We would like to confirm the exact behavior of identifierForVendor after the app is transferred to the recipient developer account. Our scenario is: The app is currently published under Developer Team A. Existing users already have the app installed on their devices. We transfer the app to Developer Team B through App Store Connect. Developer Team B creates new certificates/provisioning profiles and publishes a new version of the same app. Existing users update the app normally from the App Store, without uninstalling it. Questions: After an existing user updates from the last version published by Team A to the first version published by Team B, will UIDevice.current.identifierForVendor remain the same, or will it be regenerated? Is the vendor used to calculate IDFV associated with: the App Store app record, the Bundle ID, the Team ID, the App ID Prefix, the developer organization/vendor, or some other value? Does App Transfer itself cause IDFV to change, or does the value only change under specific conditions such as changing the organization name or uninstalling all apps from the same vendor? If IDFV changes after App Transfer, does Apple provide any official migration or mapping mechanism that allows the backend to associate the old IDFV with the new IDFV? For example, Sign in with Apple provides a user migration mechanism when transferring an app between developer teams. Is there any equivalent mechanism for identifierForVendor? Is there any difference between: users who update the app directly after the transfer, and users who uninstall the old version and reinstall the app after the transfer? We have reviewed the documentation for identifierForVendor and App Transfer, but we could not find an explicit statement describing the IDFV behavior specifically for an App Transfer between two different developer teams. Our main concern is maintaining backend device associations for existing users after the transfer. We would appreciate an official clarification on whether IDFV continuity is guaranteed across App Transfer, and if not, what migration strategy Apple recommends.

I am trying to get my first app approved and keep getting denied. In my app, I allow for Sign in With Apple. This allows the user to use Hide my Email to give a temp/private email. That is fine and I accept it. One of the major features of my app requires that parent's confirm their real address in order to see information and communicate about their children. It's a sports/coaching app. Coaches create their roster and associate parents with players via email address. Those parents then login and see their list of players (children) and can chat with the team, get schedules, etc. Without the real email, I have no way to validate that parent should have access to that player's details. It has to be secure. And a parent won't know their Hide my Email address ahead of time in order to provide it to the coach. Apple keeps denying my app saying that I cannot ask for their real email. I have explained it and the reviewer never addresses my explanation. Just denies it with the same reason. What can I do?

I have a follow-up question about file-based Keychain ACLs, this time specifically about inspecting the authorization state after it has been configured. I’ve been looking through the public SecAccess / SecACL / SecTrustedApplication APIs. I can enumerate ACL entries and their authorizations, and SecACLCopyContents gives me the trusted applications associated with an ACL. What I haven’t been able to establish is whether the complete stored caller-matching condition can be read back through a supported API. In particular, SecTrustedApplicationCopyData returns opaque application-identifying data. Is that data intended to be a complete representation of the condition that the Keychain will use to recognize that trusted application? Or can the stored trusted-application condition contain additional code-signing requirements or other matching constraints that are not represented by SecTrustedApplicationCopyData? My higher-level requirement is to verify, after configuring a private key, that its effective authorization scope is no broader than an independently reviewed policy. Ideally I would like to compare: the authorized private-key operations; all trusted-application subjects and their complete matching conditions; prompt-related state; and partition-list constraints. Is there a public and supported API, or an Apple-provided tool with a supported machine-readable contract, that can enumerate the complete effective authorization state of a private key in a file-based Keychain? I’m deliberately not trying to infer this from the current executable’s path, designated requirement, hash, security dump-keychain output, or representative negative tests unless Apple considers one of those to be the supported way to establish the stored authorization state. I realise from the existing guidance, including TN3137 and the discussion around file-based Keychains, that this is legacy technology. If complete supported introspection simply isn’t available for this model, knowing that limitation would also answer my question. Thanks.

On macOS 27, App Attest attestations include a key access control property (the aclBlob, OID 1.2.840.113635.100.8.6) that Apple says reflects SIP and Full Security mode being enabled. Is this just a wrapper around the CSR check (csr_check / what csrutil status reads) at attestation time, or is the SIP state actually enforced by the Secure Enclave and bound to the attested key?

What supported public API and verification contract should a sandboxed macOS file manager use to preserve a copied file's quarantine/provenance metadata? We observe different results in App Sandbox versus Finder and an otherwise-matched non-sandbox diagnostic. We want to keep App Sandbox and all security protections enabled, not remove quarantine or invent undocumented flag masks. Environment: macOS 26.6.2 (25G83), Apple Silicon, local APFS. Optimized Foundation-only diagnostic, Apple Development signing, Hardened Runtime, launched directly as an executable. The sandbox variant has app-sandbox, user-selected read/write and app-scope bookmark entitlements. This is not a notarized distribution-build comparison. Reproduction: Use an existing regular JPEG with naturally present com.apple.quarantine metadata identifying Chrome, raw flags 0283 and a nonempty event field. Keep the original read-only. Record SHA-256, length, full raw extended attributes and fresh NSURL quarantinePropertiesKey observations. Keep access to a user-granted local test directory active. Copy to a new, absent destination in a fresh directory using each of these three arms: fclonefileat with CLONE_ACL | CLONE_NOFOLLOW_ANY | CLONE_RESOLVE_BENEATH (28). copyfile with COPYFILE_CLONE | COPYFILE_ACL; record COPYFILE_STATE_WAS_CLONED. FileManager.copyItem(at:to:). Observe source and destination without setting, removing or repairing metadata. Each arm waits at least 1.1 seconds before copying; the source quarantine timestamp is much older than call time. Repeat with fresh destinations. Also copy the same source through actual Finder Copy/Paste twice. Compare two signed variants made from the same compiled payload, with identical executable name, bundle ID, Development identity and Hardened Runtime. The only signed entitlement difference is app-sandbox=true versus its omission. The sandbox variant resolves the existing exact folder grant; the non-sandbox diagnostic uses that same fixed test directory directly. Results: Sandbox diagnostic: all six calls succeed and data hashes/lengths match. All six outputs change raw flags 0283 to 0082, agent Chrome to the diagnostic app, event field nonempty to empty, and timestamp. Public output lacks the source event identifier and adds LSQuarantineTypeSandboxed. Matched non-sandbox diagnostic: all six copies preserve the full observed raw quarantine record and public quarantine dictionary. copyfile reports WAS_CLONED=true in both contexts. Finder: both copies preserve the full observed raw quarantine record and public dictionary. Source bytes and declared preserved metadata remain unchanged. Other compared raw attributes, mode, flags, birth/modification times, owner/group and ACL match in these cases. We also reproduced timestamp-only differences with files naturally quarantined by the diagnostic itself. The foreign-agent control above shows that the difference is not limited to timestamp. The chosen source exposes no public origin/data URL, so their preservation is untested. We have not traced the responsible internal component, tested Gatekeeper effects, or established whether the transformation is security-equivalent. We do not claim the three APIs use independent implementations or that all possible public API combinations have been tested. Could you clarify: Is this transformation expected for copying from an App Sandbox process, or should we file it as a bug? What documented preservation behavior should a sandboxed file manager rely on? Is there a supported API or operation that preserves the source's quarantine/provenance metadata in this context without disabling App Sandbox or weakening security protections? If exact raw equality is intentionally not guaranteed, which supported public properties or behaviors should verification check? Is a quarantine-properties dictionary round-trip supported, and what information does it preserve or omit? We have not attempted a metadata repair. Separately, a pathname-based repair after cloning would require its own destination-identity/race safety review because the clone call does not return a creation-bound destination descriptor. We are asking for supported API semantics, not private implementation details or a security bypass. We can prepare a minimal sanitized standalone reproducer if needed. No user files, sandbox grants, private logs or diagnostic binaries are attached to this initial question.

On macOS 26.6.2 (build 25G83), arm64, I am using the Security framework through JXA, executed by a static /usr/bin/osascript helper launched from the Codex desktop application's local command environment. A dummy-only test attempts to add one generic-password item to the local file-based login keychain. SecItemAdd returns OSStatus 100001. The system's "security error 100001" command describes this as "UNIX[Operation not permitted]". The helper explicitly opens the login keychain and selects it using kSecUseKeychain for the add operation. Synchronizable and Data Protection Keychain options are false. It supplies an access object created by SecAccessCreate with an empty trusted-application array. What I have confirmed: Keychain open/status calls succeed and report unlocked, readable, and writable. I understand these flags do not establish permission for this individual operation. Attribute-only exact lookups report the dummy item as not found before and after each failed add. Granting narrowly scoped filesystem write permission for the login keychain file through the launching tool did not resolve the failure. I have not performed a comparison outside that restricted execution environment. I have not established whether the cause is the environment, API/ACL configuration, or an OS issue. Is this JXA/Security usage supported for a file-based keychain? Which documented diagnostics can distinguish process/sandbox restrictions from item ACL or authentication requirements? Are there relevant constraints on this query/access-object construction? I am seeking a supported implementation, not a way to disable or bypass security protections. I can provide a dummy-only reproducer without credentials or personal paths.

I’m trying to clarify the supported authorization semantics for a private key in a file-based Keychain. I’ve read the existing Apple guidance around SecAccess / trusted applications and the commonly documented codesign setup that combines a trusted-application ACL with an apple: partition list. I think I understand those pieces individually, but I haven’t been able to find a public contract for how they compose when both are present. My case has three legitimate users of the same private key: a project-owned, reviewed helper that performs a bounded private-key challenge; /usr/bin/codesign; /usr/bin/productbuild. I want to grant no broader access than those callers and their required signing operations, and I don’t want to infer authorization semantics merely because a particular configuration happens to work on one macOS release. So my main question is: When a private-key ACL contains both trusted-application restrictions and a partition list, are these independent conditions that must both be satisfied by the calling process? In particular, suppose the trusted-application ACL explicitly contains my non-Apple helper, while the partition list contains only apple:. Is the helper expected to be denied because it does not satisfy the partition condition, despite being explicitly trusted by the ACL? If so, is there a supported partition configuration for a key that must be usable by both a specifically trusted non-Apple helper and Apple signing tools such as codesign / productbuild, without broadening access to an application class? I’m specifically looking for the supported contract here. A successful experiment would be useful qualification evidence later, but I don’t want to use that experiment to infer undocumented authorization semantics. Thanks.

We recently completed an app transfer between two Apple Developer Program teams. Before releasing the first post-transfer version, we need to verify the update behavior from several specific historical versions signed by the previous team. Our main question is not limited to TestFlight: we would like to know Apple's recommended and supported method for reproducing this update path. Could you clarify the following? What is Apple's recommended and supported method for testing an update from a specific pre-transfer version to the first post-transfer release? Can an archived Ad Hoc IPA signed by the previous team be used as the starting version for this test? Can that IPA be updated by a post-transfer TestFlight, Development, or Ad Hoc build signed by the recipient team? Which of these methods most accurately reproduces an App Store update after an app transfer? For a manual Development or Ad Hoc update, is the previous-application-identifiers entitlement required? If it is required, how should the recipient team request a provisioning profile that authorizes this entitlement? Thank you.