Pin the snapshot environment on the targets, and file the package-integration finding

[kyleve]

Two small follow-ups from investigating how this repo's Tuist package integration differs from the arrangement Tuist actually intends.

1. Pin the snapshot environment on the targets, not only the scheme

SNAPSHOT_EXPECTED_* and TZ were set on the StuffSnapshotTests scheme alone. But Tuist also autogenerates schemes for these targets — WhereUISnapshotTests gets its own, and the Periscope/SwiftDataInspector snapshot bundles get grouped into PeriscopeTools and SwiftDataInspector by name suffix — and none of those carried the pins.

So running one image bundle from the Xcode UI ran it unpinned. That doesn't fail loudly: the runner's fail-fast simulator guard never fires, and TZ-dependent references (widget day labels, log-viewer timestamps) silently compare against images recorded in a different timezone.

Generated scheme	SNAPSHOT_EXPECTED entries before	after
WhereUISnapshotTests	0	3
PeriscopeTools (grouped)	0	3
SwiftDataInspector (grouped)	0	3
StuffSnapshotTests (aggregate)	3	3
Stuff-iOS-Tests	0	0

Values are hoisted into one snapshotEnvironment constant and set in both places. That's deliberate, not redundant: the target-level copy pins the autogenerated schemes, the scheme-level copy pins the CI invocation, and setting only one leaves the other quietly unpinned. Counts were measured against a from-scratch generate, since a stale scheme file could otherwise have faked the result.

One side effect worth knowing: the grouped schemes now run their module's unit tests under the pinned TZ too, because Xcode scheme environment variables apply to the whole test action rather than per target. I ran the PeriscopeTools scheme (unit + snapshot together) to confirm that's harmless.

2. File the package-integration finding

Project.swift uses Package.local(path:), which emits an XCLocalSwiftPackageReference and hands the package to Xcode's SPM integration — everything static per consumer, Tuist never sees the targets, PackageSettings inert (which is why an earlier attempt to set productTypes did nothing). The arrangement Tuist intends is to declare the local package as a dependency of a Tuist/Package.swift and consume products via .external(name:), so Tuist generates the targets and owns their product types.

I prototyped it. The mechanism works; it's blocked on repo layout. Tuist can't vendor a local package whose directory is the project directory:

Fatal error: Duplicate values for key: '/Users/kve/Development/Stuff4'

Confirmed that's the specific cause by pointing Tuist/Package.swift at a throwaway probe package elsewhere — it vendored fine and advanced to graph construction. Projects that use this arrangement successfully avoid the collision purely by layout: package at the repo root, Tuist manifests in a subdirectory. Stuff has both at the root.

Only one escape route exists, and the filed item records why: the package can't move into a subdirectory, because SwiftPM rejects target paths outside the package root (target 'Outside' in package 'pkg' is outside the package root, verified with a minimal repro). So the Tuist manifests would have to move, rewriting every source glob plus ./ide, profile, CI, and the docs.

It also records that the Where app can stay statically linked through all of this — PackageSettings has a baseProductType, so products opt into .framework individually. Worth stating explicitly, since the change reads as "ship ten dylibs" and it doesn't have to be.

Filed rather than acted on: the problems that motivated the investigation are already resolved, so this is real but unurgent cleanup whose cost is a repo-layout move and should be its own decision.

Verification

Full StuffSnapshotTests scheme green with zero reference images modified; PeriscopeTools grouped scheme green; Stuff-iOS-Tests unaffected; ./swiftformat --lint clean. The prototype was fully reverted — no Tuist/ directory or Package.swift change is included here.