Hi all, I’m trying to notarize a Flutter macOS app built in CI (GitHub Actions). The app builds and signs fine locally—codesign --verify --deep --strict and spctl --assess both pass. However, Apple’s notarization service consistently rejects the app with errors like: The binary is not signed with a valid Developer ID certificate: file_picker.framework The binary is not signed with a valid Developer ID certificate: file_saver.framework The binary is not signed with a valid Developer ID certificate: url_launcher_macos.framework What I’ve tried: Explicitly re-signing all frameworks with my Developer ID Application certificate and --timestamp Removing existing signatures before re-signing Ensuring correct entitlements and bundle identifier Matching the app bundle name and identifier in all places Using both codesign --deep and manual signing of each binary Local validation always passes, but notarization fails in CI Certificate: I am using a “Developer ID Application” certificate (not a “Mac Developer” or “Apple Development” certificate). The output of codesign -dvv for the problematic frameworks shows: Authority=Developer ID Application: [My Name/Team] ([Team ID]) So I believe I am not making the common mistake of using the wrong certificate type. CI Environment: GitHub Actions, macos-latest runner Flutter 3.27.2, stable channel All secrets (cert, Apple ID, app-specific password, team ID) are set up Questions: Has anyone encountered this with Flutter plugins or CI builds? Are there known issues with signing Flutter plugin frameworks for notarization? Is there a way to get more detailed feedback from Apple’s notarization service? Any advice or pointers would be greatly appreciated. I’m happy to provide logs, scripts, or a minimal project if needed. Thanks!
It’s really hard to read your post. Please take a look at Quinn’s Top Ten DevForums Tips, which has lots of suggestions for how to work effectively on the forums.
Anyway, what I can see is this:
Are there known issues with signing Flutter plugin frameworks for notarization?
I think you might have more luck asking that via the support channel for the third-party tool you’re using.
However, my experience is that third-party tooling tends to bend the bundle placement rules outlined in Placing Content in a Bundle, and that causes all sorts of weird problems.
Using both codesign --deep
I strongly recommend against using --deep when signing code. See --deep Considered Harmful.
As to what you should do, you can find my general advice in:
Beyond that, it’s hard to offer specific advice without more details. You wrote:
I’m happy to provide logs, scripts, or a minimal project if needed.
If you create a minimal submission, use that reproduce the error, and then post links to the file you submitted and the resulting notary log, I’d be happy to take a look.
Tip 14 in the above-mentioned tips post explains how to post URLs in the clear.
Fetching the Notary Log explains how to get your notary log.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"