We are evaluating a separately App-Sandboxed GUI helper for one explicitly reviewed AIFF NAME edit on internal-disk APFS. The main app retains user-selected read-only access. The helper has only App Sandbox and user-selected read/write entitlements.
We would like the supported API and failure/reconciliation contract before implementing physical-file edits.
A local synthetic-fixture probe used macOS 27.2 (26B118), SDK 27.0, arm64, ad-hoc signing with Hardened Runtime, LaunchServices and the helper's own NSOpenPanel.
Captured stat fields, raw xattrs and bytes were unchanged after selection and an O_RDONLY read. Across a later O_RDWR open/fstat/close gate, com.apple.quarantine was added and ctime changed; bytes stayed identical and close returned 0. There was no content-write call. This describes one observed build/run, not a general OS mechanism. We have not tested copyfile, clonefile or replacement paths.
-
Existing-file conflicts. We read the later DTS explanation in thread 850377 about path-based link/rename substitution limits. Our use case is an ordinary editor replacing an existing user-selected file while another uncoordinated app might edit or replace it. What supported pattern and limits should we use to avoid silently overwriting unrelated updates, detect conflicts and retain truthful indeterminate outcomes? Is any supported replacement operation conditional on the previously reviewed destination object/content version, or should that guarantee be treated as unavailable under this concurrency model? We do not assume a post-operation identity check prevents an earlier effect.
-
Protected metadata. What preservation contract should this sandboxed helper rely on for quarantine/provenance, ACLs and unrelated xattrs through copy/clone, a native-field edit and replacement? The current copyfile/clonefile manuals describe metadata copying and exceptions, while FileManager replacement documents selected original metadata. If exact raw quarantine equality is not the supported invariant, which public properties or behaviors should verification check, including originally absent quarantine? We want to retain Apple's security semantics without stripping quarantine, normalizing undocumented flags or disabling App Sandbox.
-
Replacement access. After selecting an existing file in NSOpenPanel, is FileManager's itemReplacementDirectory plus replaceItemAt a supported safe-save route under that file selection? What additional consent, if any, is required for temporary-file creation and namespace publication? We do not assume parent-directory access or propose adding selected-source write rights to the main app.
Relevant references:
No user media, paths, saved grants, private logs or binaries are attached. We are seeking supported semantics and refusal boundaries before further implementation or experiments.