ITMS-90035 tells you a sealed resource is missing or invalid, but it does not always make clear which file broke the signature. The good news is that you do not have to guess: a single codesign command names the exact file that was added, removed, or modified after signing. Here is how to find it and what usually put it there.
Short answer
ITMS-90035, "a sealed resource is missing or invalid", means a file inside your signed app bundle changed after it was signed. To find the exact file, run codesign with verbose verification on the .app, which prints a line naming the modified, added, or missing resource. Per Apple's guidance on the Invalid Signature rejection, the cause is something altering the bundle after the signing step. Common offenders are a stray .DS_Store, an Info.plist edited by a build script, a file generated at runtime, or an extra file in an embedded framework, which is why hybrid frameworks trigger it most.
What you should know
- The seal covers every file: signing records a hash of each resource, so any later change invalidates it.
- codesign names the file: verbose verification prints the exact modified, added, or missing resource.
- CodeResources is the manifest: the bundle's _CodeSignature/CodeResources lists every sealed file and hash.
- Hybrid frameworks are common culprits: copying web assets, plugins, or frameworks after signing breaks the seal.
- The fix is a clean re-sign: correct the step that changed the bundle, then rebuild and re-sign.
How do you find the exact missing or modified resource?
Run verbose verification against the app bundle. The codesign tool checks every sealed file and, when one does not match, prints exactly which file and how it failed:
codesign --verify --verbose=4 MyApp.app
When the seal is broken, the output names the resource and the reason, for example:
MyApp.app: a sealed resource is missing or invalid
file modified: .../MyApp.app/Frameworks/SomeKit.framework/Info.plist
The keywords to read are file modified, file added, and file missing. Each points at the exact path, so you go straight to the file rather than searching blind. You can also open the bundle's _CodeSignature/CodeResources, a plist that lists every sealed file with its hash, to see what the signature expected.
What kinds of files break the seal?
Anything that changes the bundle after signing. The table lists the usual offenders and how to handle each.
| File that breaks the seal | Why it happens | Fix |
|---|---|---|
| A .DS_Store inside the bundle | Finder added it, or a copy step included it | Remove it and exclude it from copy phases |
| A modified Info.plist | A build script edited it after signing | Stop the post-sign edit |
| A file generated at runtime in Resources | The app wrote it on first launch | Write generated files outside the app bundle |
| An extra or unsigned file in a framework | Copied in after the framework was signed | Keep frameworks pristine and set them to Embed and Sign |
| A non-standard framework layout | The bundle structure is not what codesign expects | Use a standard framework bundle structure |
A quick way to catch the most common one is to search the bundle for stray metadata files:
find MyApp.app -name '.DS_Store'
Why do hybrid frameworks trigger it most?
Because their build steps move files around after the app is signed. Cordova and Capacitor copy web assets and plugins into the bundle, Flutter ships its engine and an App.framework, and React Native bundles its own frameworks, and any step that writes into the .app after the signing phase changes a sealed resource. A framework that was signed separately and then had a file added, or an asset folder rewritten by a packaging script, produces the same missing-or-invalid result. The artwork and code are usually fine; it is the order of operations in the build that breaks the seal.
How do you fix it once you find the file?
Correct what changed the bundle, then re-sign cleanly. If the named file should not be there, such as a .DS_Store or a leftover artifact, remove it and stop the step that added it. If it is a file your app generates at runtime, move that output outside the bundle so it is not part of the signed contents. If it is inside a framework, set the framework to Embed and Sign so Xcode signs it during the build, and avoid editing it afterward. Then clean the build folder, rebuild the Release target, and export through Xcode's Organizer so Xcode re-signs the whole bundle from a clean state rather than you patching it by hand.
What to watch out for
The trap is re-signing the broken bundle by hand to make the error go away. That hides the cause and often creates new mismatches between the app and its nested frameworks, so fix the step that modified the bundle instead. Watch for build phases that run after signing and for tools that touch the .app during packaging, since those are the usual source. 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 and confirms the binary is properly signed, alongside its other checks. The limit is that the scan reports the signing state; codesign is the tool that names the specific file, and Xcode is where you correct it.
What to take away
- ITMS-90035 means a file in your signed bundle changed after signing; run codesign with verbose verification to name the exact file.
- Read the file modified, file added, or file missing line, and check _CodeSignature/CodeResources for what the seal expected.
- Common culprits are a stray .DS_Store, a post-sign Info.plist edit, a runtime-generated file, or an extra file in a framework, which is why hybrid builds hit it most.
- Fix the step that changed the bundle, set frameworks to Embed and Sign, rebuild and re-sign through Xcode, and confirm with a pre-submission scan such as PTKD.com.
