25.7 · What a build leaves behind: archives, binaries, dependencies and tests

The command line shows what the release pipeline really produces. Reading an archive, a binary and a result bundle turns “it works on my machine” into evidence.

Mental model. Every stage leaves an artefact you can open: an archive with a plist, a Mach-O with a build version and a UUID, a lockfile, an xctestrun and a result bundle.

Archive and binary

What is inside the archive, the IPA and the executable, and how a dSYM is matched.

  1. What is inside an .xcarchive and an .ipa, what does exportArchive add, and what does it need to succeed? 25.7.1 · L3
    An .xcarchive is a folder: an Info.plist (the app’s bundle ID, versions, architectures, and the signing identity and team that were used)…
  2. How do you inspect the binary you are about to ship: the minimum OS, platform and SDK, architectures, linked frameworks and the UUID that ties it to a dSYM? 25.7.2 · L3
    The binary is evidence, so read it. vtool -show-build prints the LC_BUILD_VERSION load command: the platform, minos (the deployment target the linker recorded)…

Repeatable inputs and tests

Pinned dependencies and splitting the build from the test run.

  1. How do you make Swift Package dependencies reproducible on CI: what Package.resolved pins, when versions move, and what the force-resolved flag does? 25.7.3 · L3
    A package dependency like from: "1.0.0" is a range; Package.resolved records the exact version (and revision) chosen. The check shows the rules with a local…
  2. How do build-for-testing and test-without-building split a test run, what is an xctestrun file, and how do you read results from the .xcresult bundle? 25.7.4 · L5
    xcodebuild build-for-testing compiles the app and the test bundles and writes an .xctestrun file next to the products; test-without-building -xctestrun … then…

More in App Store & release engineering