Why must nested code be signed before the code that contains it, what does “nested code is modified or invalid” mean, and why is --deep discouraged for releases?

A bundle’s signature seals hashes of everything inside it, including the signatures of nested frameworks, extensions, helpers and the watch app. Signing is therefore inside-out: nested code first, then the code that contains it, last the app. If you sign the app and then re-sign a framework (or any file inside the bundle changes), the outer seal no longer matches and verification reports nested code is modified or invalid. The check signs a small bundle both ways: outer then inner fails with that message, inner then outer verifies (exit 0), and --deep also produces a valid result because it walks the nested code for you.

The reason people avoid --deep for releases is control: it applies one identity and one set of options to everything, while real apps need different entitlements per extension, the hardened runtime on helpers and preserved metadata, and a one-line mistake is hard to see in its output. Apple’s guidance has long been to sign each component explicitly. Xcode does the ordering when it builds and exports; the order bites when you add a custom script phase or CI step that touches the bundle after signing (stripping architectures from a vendored framework, swapping a plist, injecting a crash-reporter configuration). Do such work before the signing step, or sign again afterwards from the innermost out. Notarisation and App Store validation both reject incorrectly nested signatures. The check ran on a macOS bundle with an ad hoc identity; iOS bundles follow the same rule but need a real certificate and profile to install.