How do I fix 'Invalid Code Signature' in Xcode 16?

An Invalid Code Signature error means the seal Xcode put on your app no longer matches what is inside it. Something changed the bundle after it was signed, or an embedded framework was not signed the way Apple expects. It reads like a certificate problem, but it is usually a packaging problem. Here is what breaks the seal and how to put it back.

Short answer

An Invalid Code Signature, often reported as ITMS-90035 "a sealed resource is missing or has been modified", means the app's signature no longer matches its contents. The usual causes are a bundle changed after signing, such as a build script or a stray file, or an embedded framework that is not signed correctly. Per Apple's guidance on the Invalid Signature rejection, the fix is to clean the build, set embedded frameworks to Embed and Sign, sign with a distribution certificate and a valid App Store profile, and never alter the .app after Xcode signs it. Updating an outdated third-party framework signature resolves a common Xcode 16 case.

What you should know

• The signature seals the whole bundle: any change after signing invalidates it.
• A modified bundle is the top cause: a build script or a stray file editing the .app breaks the seal.
• Embedded frameworks must be signed: set them to Embed and Sign in the target.
• Old framework signatures fail: a framework signed with an outdated version is rejected and must be updated.
• Use a distribution certificate: a development or ad-hoc certificate produces an invalid App Store signature.

What does "Invalid Code Signature" actually mean?

It means the cryptographic seal on your app does not match the files it covers. When Xcode signs your app, it records a hash of every resource in the bundle, so the system can verify nothing changed. If a file is added, removed, or modified after that step, the seal no longer matches and the build is rejected, often with the message that a sealed resource is missing or has been modified. This is why the error points at packaging rather than at your certificate: the certificate may be perfectly valid while the contents it signed were altered underneath it. That is the most useful thing to internalize under pressure, because it means the work is to find what touched the bundle, or which nested object is signed wrong, not to reissue a certificate that was never the problem.

What are the common causes?

A handful of issues account for most of these rejections. The table pairs each cause with its fix.

How do you fix it, step by step?

Rebuild cleanly and let Xcode handle the signing:

1. Clean the build folder and delete DerivedData, then rebuild the Release target, since stale artifacts carry old signatures.
2. Set every embedded framework to Embed and Sign in the target's General settings, so each one is signed during the build.
3. Confirm signing identity: use Automatically manage signing, or a distribution certificate with a valid App Store provisioning profile, not a development or ad-hoc identity.
4. Remove anything that modifies the bundle after signing, including custom build phases that copy files in and stray files like .DS_Store inside copied resource folders.
5. Export through Xcode's Organizer with Distribute App, so Xcode re-signs the archive consistently rather than you editing it by hand.

Why do third-party frameworks trigger it?

Because a framework is its own signed object inside your app, and it has to be signed correctly too. If an embedded framework is set to Do Not Embed, or shipped pre-signed with an outdated signature version, the seal on your app fails when Apple validates the nested code. Setting the framework to Embed and Sign tells Xcode to sign it during your build, and updating a third-party framework to a current release replaces an old signature that is no longer accepted. Frameworks pulled in through CocoaPods or Swift Package Manager are usually handled for you, but a manually dragged-in framework is the one to check first. A quick way to narrow it down is to inspect the .app or .ipa contents and confirm each item under the Frameworks folder is present and signed, since a missing or duplicated framework there is a frequent source of the sealed-resource message.

What to watch out for

The quiet culprit is a build script that touches the .app after the signing phase. Anything that copies a file in, rewrites Info.plist, or leaves a .DS_Store inside a resource folder changes the sealed contents and invalidates the signature, even though your code and certificate are fine. Resist the urge to re-sign the bundle by hand with codesign to paper over it, because that usually hides the real cause and creates new mismatches; fix the step that modified the bundle instead. Code signing is part of build integrity, so a pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS to confirm the binary is properly signed, alongside the other binary checks it runs. The limit is that a scan reports the state; Xcode is still where you correct the signing.

What to take away

• Invalid Code Signature means the app's seal no longer matches its contents, usually because the bundle was modified after signing.
• Set embedded frameworks to Embed and Sign, sign with a distribution certificate and a valid App Store profile, and clean stale build artifacts.
• Remove any build step or stray file that alters the .app after signing, and export through Xcode's Organizer so Xcode re-signs consistently.
• Update outdated third-party frameworks, since an old signature version is a common Xcode 16 cause, and confirm the signed build with a pre-submission scan such as PTKD.com.