Since macOS Sierra and iOS 10, codesign refuses to sign a bundle if any file in it carries certain extended attributes. Apple documented the change in Technical Q&A QA1940. The word detritus is doing real work in that sentence: this is legacy HFS metadata that has no business being inside a signed bundle, and rather than silently discarding it the tool stops.
In practice one attribute causes almost all of these failures. com.apple.FinderInfo is a 32-byte blob that the Finder attaches to files it has looked at or moved. Resource forks (com.apple.ResourceFork) are the other historic offender, though they are rare on anything built this decade.
The path at the start of the message is the bundle codesign was working on, not necessarily the file carrying the attribute. That distinction matters: clearing attributes on the .app is usually enough, but when the build reintroduces them you need to know which file is the source.
Find what is actually dirty
Before clearing anything, list the attributes. Thirty seconds here saves you from fixing the same error every second build for a month.
# Every extended attribute in the bundle, recursively xattr -lr /Users/ci/build/MyApp.app # Just the filenames that have any xattr -r /Users/ci/build/MyApp.app | sort -u
The output names the file and the attribute. If it points at an asset catalog, a font, a bundled .framework, or a sound file, you have found the culprit: that file was almost certainly added to the repo from a Mac that touched it in the Finder first.
Clear it
# Recursively strip every extended attribute xattr -cr /Users/ci/build/MyApp.app # Or target one attribute if you want to be conservative xattr -rd com.apple.FinderInfo /Users/ci/build/MyApp.app xattr -rd com.apple.ResourceFork /Users/ci/build/MyApp.app
xattr -cr is the blunt instrument and it is the one most people reach for. It is safe on a build product, because nothing in a compiled bundle depends on extended attributes. It is less safe on your source tree, where quarantine flags and other attributes may be meaningful, so point it at the build directory rather than the repo root.
Where the attributes come from
- Show Package Contents
- Browsing inside a bundle in the Finder can stamp Finder info onto the files you look at. Apple calls this out explicitly in QA1940. Inspect bundles from Terminal instead.
- Files copied through Finder, AirDrop, or a zip
- Dragging an asset into the project from a Downloads folder brings whatever metadata came with it. Unzipping an archive created on another Mac does the same.
- Dropbox, iCloud Drive, and other sync clients
- Sync clients attach their own attributes to files they manage. A build directory inside a synced folder will keep producing this error indefinitely. Move the build out of the synced path.
- Committed .DS_Store files
- Not the attribute itself, but the same family of problem. A .DS_Store that ends up inside a resource folder gets copied into the bundle and signed alongside everything else. Add it to .gitignore and delete the ones already tracked.
- Restored caches on CI
- Some cache restore steps write attributes onto the files they extract. If the error appears only on runs that hit the cache, this is why.
# Purge tracked .DS_Store files once find . -name ".DS_Store" -print -delete git rm --cached $(git ls-files '*.DS_Store') 2>/dev/null || true echo ".DS_Store" >> .gitignore
Checking your work
Two commands: one confirms the bundle is clean, the other confirms it actually signs. Run both, because a clean xattr listing on the wrong path proves nothing.
# Should print nothing at all xattr -lr /Users/ci/build/MyApp.app # Should complete without the detritus error codesign --force --deep --sign "Apple Distribution: Acme Corp (ABCDE12345)" \ /Users/ci/build/MyApp.app codesign --verify --verbose=2 /Users/ci/build/MyApp.app
Related messages
- Under the older build system this error was wrapped in Command /usr/bin/codesign failed with exit code 1, with the detritus line a few lines above it in the log.
- "bundle format unrecognized, invalid, or unsuitable". A different structural complaint about the bundle, often a framework laid out incorrectly rather than stray metadata.
- "code object is not signed at all". Nested code that was never signed, rather than code that cannot be signed.
- On macOS, a bundle that signs cleanly here can still fail notarization for unrelated reasons, so a clean codesign is not the last checkpoint.