Make XCFramework generation fail fast and reproducible

[HituziANDO]

Problem

The Xcode build phase runs multiple archive commands without fail-fast shell settings or per-step validation. A failed archive can be followed by successful commands, allowing an incomplete or stale XCFramework to appear successful.

Scope

• Move XCFramework generation into a version-controlled standalone script.
• Use set -euo pipefail and quote every path.
• Build into a fresh, narrowly scoped temporary/output directory.
• Remove GUI-opening behavior from the build.
• Validate slices, architectures, Info.plist values, privacy manifests, and Swift interfaces.

Acceptance criteria

• Any failed archive or validation step returns a non-zero exit status.
• A previous artifact cannot mask a failed build.
• The same script runs locally and in CI.
• The final XCFramework contains every supported platform slice and required manifest.

Tests

• Exercise a successful build and an intentionally failing archive to verify exit behavior.

Relevant files

• Framework/SwiftyUpdateKit.xcodeproj/project.pbxproj
• Framework/SwiftyUpdateKit.xcframework/
• Framework/PrivacyInfo.xcprivacy

[HituziANDO]

This failed for real while preparing 1.5.1. Recording the details so the work does not have to rediscover them.

What happened

./build.sh exited 0 and printed ** BUILD SUCCEEDED **, but produced no XCFramework. The actual error was buried in the log:

A library with the identifier 'ios-arm64' already exists.
** BUILD SUCCEEDED **

mv: rename Output/Release-xcframework/SwiftyUpdateKit.xcframework/ to ./SwiftyUpdateKit.xcframework/: No such file or directory

Because build.sh runs rm -rf $XCFRAMEWORK before the build, the committed 1.5.0 artifact was deleted and never replaced. It had to be restored with git checkout.

Cause

The Mac Catalyst archive in the MakeFramework build phase passed its destination as:

-destination='platform=macOS,arch=x86_64,variant=Mac Catalyst'

xcodebuild does not accept the -destination=value form, so the argument was ignored. That invocation is also the only one without -sdk, so it archived against the default iOS device SDK and produced arm64-apple-ios instead of arm64-apple-ios-macabi. -create-xcframework then received two libraries claiming ios-arm64.

Fixed in 0844c50 by using -destination 'generic/platform=macOS,variant=Mac Catalyst', which restores the ios-arm64_x86_64-maccatalyst slice with both architectures.

Still open, and relevant to this issue

• The iOS device and simulator archives use the same -destination= form. They currently produce correct output only because -sdk iphoneos / -sdk iphonesimulator drives the platform. Both should move to proper destination syntax.
• The build phase reports success regardless of what its commands return, which is the failure mode this issue describes. set -euo pipefail alone would have caught it.
• rm -rf on the committed artifact runs before anything is known to succeed. Building into a temporary directory and swapping only on success would avoid destroying a good artifact.
• The generated XCFramework should be validated after creation. Checking that all four expected slice identifiers are present would have failed this build immediately.
• open ${XCFRAMEWORK_DIR} at the end of the phase opens Finder during every build.

Related

A second problem surfaced in the same release: the lint-staged globs matched the generated headers inside the XCFramework, so committing a regenerated artifact reformatted them and invalidated the bundle signature. Fixed separately in #40.