Installed Xcode ProductBuildVersion 27A9275, SwiftBuild 25000.0.222.
Synthetic static Swift framework and three arithmetic XCTest cases only.
No real app, account, health data or code-signing identity is needed.
A Seatbelt profile allows an exclusively owned child of the normal macOS
per-user temporary directory, public SDK/toolchain reads and necessary build
services, while denying private-home data and writes elsewhere. Network is denied.
The process receives TMPDIR, TMP and TEMP set to that owned child. Fresh
DerivedData and result-bundle paths also point inside it. A generic iOS Simulator
build-for-testing stops at builtin-infoPlistUtility: mkdtemp tries to create
swbuild.tmp.* directly in the per-user temporary parent and returns EPERM.
The documented -userdefault=value argument syntax accepts
-SWBBuildServiceEnvironmentOverrides='{ TMPDIR = "<owned-child>/"; TMP = "<owned-child>/"; TEMP = "<owned-child>/"; }'
but a changed synthetic trial still selects the parent. Acceptance is not proof
of the runtime dictionary type or transport adoption.
A standalone process under the same profile, using installed Foundation,
reports getenv("TMPDIR") as the owned child while both
FileManager.default.temporaryDirectory and NSTemporaryDirectory return the parent.
The installed SwiftBuild Path.temporaryDirectory implementation calls
NSFileManager.defaultManager temporaryDirectory. The out-of-process initializer
requires a string-to-string dictionary, then applies it to the child environment.
Question for Apple: what supported per-invocation control makes built-in tasks
use an explicitly owned temporary child on this version, and what supported
no-build diagnostic proves its effective adoption? Is this Foundation behavior
expected under Seatbelt? We cannot grant access to the shared parent or private
home, change trust/keychain access, inject code, or modify installed libraries.
CoreSimulator's
separate runtime-availability error is not attributed to this temporary-path issue.