In a synthetic reproduction of a DeviceSupport-style backup on macOS 26.7.1 with Xcode 26.6 on Apple silicon, a source object has no com.apple.provenance, while a newly created destination object acquires that private extended attribute. File contents, modes, ACLs, and the source's other extended-attribute names can be verified independently. The backup acceptance contract requires a future restore to reproduce the original governed metadata. Is destination creation expected to add this attribute? For a faithful restore to a fresh APFS destination, should restoration software omit it, remove it after creation, preserve it, or allow macOS to regenerate it? Which supported API or documented postconditions establish restoration fidelity when the source lacked the attribute? Could the attribute affect DeviceSupport symbol usability or access behavior? We are seeking Apple-supported backup and restoration procedures and security postconditions, not an interpretation of private metadata. No real DeviceSupport files, raw private attribute values, production paths, credentials, datasets, or personal information are included.

On macOS 26.7.1 with Xcode 26.6 on Apple silicon, a small set of ordinary development source/resource files and one project directory carry the private extended attribute com.apple.macl. We need to create a new APFS compilation-input tree, not a filesystem backup. The proposed implementation opens source and destination objects using descriptor-relative no-follow traversal and calls fcopyfile(sourceFD, destinationFD, NULL, COPYFILE_DATA), then independently verifies exact content hashes and applies an explicit destination mode and ACL policy. It does not request COPYFILE_XATTR, COPYFILE_ACL, or COPYFILE_STAT. Is omitting com.apple.macl supported for this data-only compilation export? Could preserving it transfer stale or inappropriate access authority to the destination? Which supported API or documented postconditions should establish the destination's correct security state? Is there an Apple-recommended procedure for exporting ordinary development source content without transferring private mandatory-access metadata? We are seeking an API and security contract, not an interpretation of the attribute's private bytes. No production paths, source code, private attribute values, credentials, datasets, or personal information are included.

On macOS 26.7.1 with Xcode 26.6 on Apple silicon, several directories in a development tree carry the private extended-attribute names com.apple.fileprovider.dir#N and com.apple.fileprovider.fpfs#P. On this host, the supported xattr_flags_from_name decoder returns XATTR_FLAG_NEVER_PRESERVE for the first exact name and XATTR_FLAG_NO_EXPORT for the second exact name. Apple's public API defines those flag meanings; the literal name encoding and the attributes' private values are not treated as a public semantic contract. We want a self-contained APFS compilation-input tree using descriptor-based COPYFILE_DATA for regular files, with independent inventory and hash verification and no private-xattr copying. For this compilation-only export, does Apple support deliberate non-preservation when xattr_flags_from_name returns XATTR_FLAG_NEVER_PRESERVE, and when it returns XATTR_FLAG_NO_EXPORT for a governed SHARE operation? Separately, what public, non-hydrating API can establish that every required file is already fully materialized and that export will not trigger provider downloads? Does enumeratorForMaterializedItems establish that state for a closed descendant tree, or must each item be checked by another supported API? Can reading or hashing an item itself cause materialization? We are asking about documented APIs, supported export behavior, and security postconditions. We are not asking to decode or preserve private attribute values. No production paths, source code, credentials, datasets, or personal information are included.

Environment Mac mini with Apple M4 macOS 26.7.2 (build 25G332) Xcode 26.6 CoreSimulatorService 1051.55 External USB SSD formatted as APFS, mounted read/write, with ownership enabled Source simulator: iPhone 17 Pro running iOS 26.5, shut down Issue I am attempting to preserve a shutdown simulator using the supported simctl clone operation, with the destination CoreSimulator device set located on an external APFS SSD. Command form: xcrun simctl clone <source-UDID> "<preserved-device-name>" "/Volumes/<external-volume>/<device-set-path>" The destination directory is owned by the logged-in user and has ordinary writable POSIX permissions. The volume is mounted read/write with ownership enabled. No restrictive ACL entries or file flags were found on the destination directories. Observed result simctl reports: NSPOSIXErrorDomain Code=22: Device was allocated but was stuck in creation state. CoreSimulator records the preceding data-clone failure as: NSCocoaErrorDomain Code=513 Underlying NSPOSIXErrorDomain Code=1 Operation not permitted The temporary destination simulator entered the Creating state and CoreSimulator automatically rolled it back. At the same timestamp, unified logging attributes the rejected external-volume write to com.apple.CoreSimulator.CoreSimulatorService, rather than to simctl. The TCC and sandbox sequence shows: A check for kTCCServiceSystemPolicyAllFiles. A check for kTCCServiceSystemPolicyRemovableVolumes. Removable-volume access requiring a TCC prompt. Prompting being denied because the requesting CoreSimulatorService is an Apple platform binary. Launch Services being unable to create an application record for the CoreSimulatorService XPC bundle. No consent prompt was displayed. CoreSimulatorService's Info.plist contains an NSRemovableVolumesUsageDescription string specifically describing access when a simulator device set is configured on external storage. This is a development-tool/service issue; no application project or third-party framework is involved. Expected result CoreSimulatorService should either present or arrange the supported removable-volume consent workflow, or use a documented user-controlled Files & Folders permission that allows an external device set. Questions What is the supported procedure for granting SystemPolicyRemovableVolumes access to com.apple.CoreSimulator.CoreSimulatorService when the Apple platform XPC service cannot display the consent prompt? Should CoreSimulatorService appear in System Settings > Privacy & Security > Files & Folders with a Removable Volumes switch? Is cloning into an external APFS CoreSimulator device set supported with Xcode 26.6 on macOS 26.7.2? Is there a supported way to initiate the operation so consent is attributed to Xcode or another user-facing Apple process? Is the Launch Services application-record failure expected, or is this a known CoreSimulator/TCC issue with an available fix? I have not edited the TCC database, reset privacy decisions, granted broad Full Disk Access, disabled security controls, changed permissions, removed extended attributes, manually copied protected simulator records, or retried using an unsupported filesystem workaround. I can provide focused, redacted CoreSimulator, sandboxd, and tccd excerpts privately if an Apple engineer requests them.