Start with the distribution target

Record whether you ship an app, a Swift package, a separately distributed framework, or several of these together. A setting appropriate for a private app module can break an SDK consumed by another compiler. List embedded extensions and helper executables so the audit does not stop at the main application target.

Resolve the actual scheme, Release configuration and destination with xcodebuild. Review the resulting settings rather than searching only project.pbxproj: configuration files, target overrides and build automation can change the effective value. Save the relevant output privately with the build identifier.

xcodebuild -showBuildSettings -scheme Example -configuration Release

Review a small set of controls

Check Swift optimization and compilation mode, testability, dead-code stripping and debug-information format. Establish why each current value exists before changing it. Avoid a repository-wide replacement of Debug with Release or a script that strips every binary it finds. Embedded frameworks may have different constraints.

Separate optimized code generation from public debug exposure. A release can be optimized while retaining a private dSYM for diagnostics. Deleting diagnostic resources everywhere may make incidents harder to resolve without meaningfully changing what an experienced analyzer can infer from executable instructions.

Use a compatibility matrix

Select tests for the application features most likely to depend on names or dynamic loading: serialization, Objective-C bridging, plugins, storyboards and SDK callbacks. Compare outputs from the previous release profile with the candidate profile. For a numerical component, include boundary values and malformed input alongside ordinary examples.

Measure launch behavior and package size on representative release targets. A simulator run does not establish device signing or distribution behavior. If a target device or SDK is unavailable, record that gap explicitly rather than converting a successful local compilation into a compatibility claim.

Finish with the exact export

Inspect the signed export, not just intermediate build products. Confirm expected capabilities and native signature checks before creating the release receipt. CloneGuard can identify project hints and screen supported bytes, but it does not resolve Xcode settings or validate all Apple distribution requirements itself.

Keep the candidate build, settings report and diagnostic resources linked by a stable build identifier. A successful check should say exactly which artifact and tests it covered. It should not say that optimization made the Swift implementation impossible for REA or another analyzer to reconstruct.

Practical checklist

  • Record scheme, SDK, architecture and configuration.
  • Review dynamic-name and public ABI dependencies.
  • Run release tests before signing and export.
  • Store the final artifact and receipt separately.

Sources and further reading

Primary references support the technical details. Procedures here are guidance; only explicitly recorded project results describe tests we ran.

  1. Apple: Build settings reference
  2. Swift.org: Library Evolution in Swift

Prepared with AI assistance. How this library is produced. Suggest a correction; keep private code and credentials out of public issues.