Draw the actual pipeline

Write down each step that can change the bundle: compilation, stripping, resource generation, embedded framework processing, packaging, signing, export and any notarization or ticket-stapling work applicable to the distribution channel. Assign one owner to the final artifact rather than letting several jobs mutate the same directory.

A safe review begins with a copy of an owned fixture. Avoid experiments on the sole signed release. If an external hardening tool changes bytes after signing, move that step earlier or use the legitimate packaging workflow to produce and sign a new artifact. Do not assume a runnable executable still has a valid distribution signature.

Preserve capabilities while changing code

Review entitlements and required capabilities before any rebuild. Unnecessary development settings deserve investigation, but removing entitlements indiscriminately can break keychain sharing, extensions or other expected functionality. A hardening change should have an explicit compatibility test and rollback point.

Do not invent a signing identity or replace the organization signature with an ad-hoc one merely to satisfy a local command. A local toolchain signature can be useful for fixture testing, but it does not establish the identity or distribution eligibility expected by customers.

Run checks with distinct meanings

For a macOS app, signature verification, entitlement inspection and Gatekeeper assessment cover different aspects of the release. Their commands below are read-only examples for an application you own. Interpret failures using the actual distribution context, and retain command results with the build identifier.

codesign --verify --deep --strict --verbose=2 Example.app
codesign -d --entitlements :- Example.app
spctl --assess --type execute --verbose=2 Example.app

Freeze and record the final package

Finish required notarization, export or ticket handling before deciding which download bytes are final. Recheck the exact artifact the customer will receive, including its installation and launch path. A validated app inside a later modified installer does not validate the installer as a whole.

Use CloneGuard to manifest the final regular package or another supported symlink-free artifact. Keep the receipt outside that artifact tree. If a later process changes a file, create a deliberately new release record after validation rather than updating the receipt silently to make a verification failure disappear.

The receipt confirms byte identity relative to the trusted record. It does not replace the Apple signature, notarization service, store validation or runtime testing. Keep those outcomes separate in release notes so an integrity result cannot be mistaken for proof of resistance to reverse engineering.

Practical checklist

  • List every byte-changing build step.
  • Transform before legitimate signing.
  • Inspect final entitlements and distribution checks.
  • Manifest the artifact customers actually receive.

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: Notarizing macOS software before distribution
  2. Apple: Build settings reference

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