Unable to notarize Electron-based application. All notarization attempts fail with "The signature of the binary is invalid" for main executable and Electron Framework, despite passing local codesign verification.
ENVIRONMENT:
- macOS: 24.6.0 (Sequoia)
- Hardware: Apple M4 Max (arm64)
- electron-builder: 26.0.12
- Electron: 36.9.5 (also tested 37.10.2, 38.2.0)
- Certificate: Developer ID Application: AS LIVE MEDIA SP Z O O
- Team ID: 2KJ532SU3G
- Certificate validity: Oct 7 2025 - Oct 8 2030
PROBLEM: Every notarization submission fails with identical error for two binaries:
- Contents/MacOS/PresentClic Desktop
- Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework
Error message: "The signature of the binary is invalid." Architectures affected: Both x86_64 and arm64
CRITICAL CONTRADICTION: ✅ Local verification PASSES: $ codesign --verify --deep --strict "PresentClic Desktop.app" Result: valid on disk, satisfies Designated Requirement
❌ Apple notarization service FAILS: Error: "The signature of the binary is invalid"
LATEST SUBMISSION ID: 11e1a452-4ea7-4562-ac8e-5e76c39eeb6c
Local verification output shows all components validated:
- Electron Framework: validated ✅
- All helper apps: validated ✅
- All frameworks: validated ✅
- Main executable: valid on disk ✅
- Authority chain: Developer ID Application → Developer ID CA → Apple Root CA ✅
- Timestamp: Present ✅
- Runtime Version: 15.4.0 ✅
CONFIGURATION: Entitlements (build/entitlements.mac.plist):
- com.apple.security.cs.allow-jit: true
- com.apple.security.cs.allow-unsigned-executable-memory: true
- com.apple.security.cs.disable-library-validation: true
- com.apple.security.cs.allow-dyld-environment-variables: true
- com.apple.security.automation.apple-events: true
- Standard device/network/file entitlements
Build configuration:
- hardenedRuntime: true
- gatekeeperAssess: false (tested both true and false)
- entitlements and entitlementsInherit: properly configured
TROUBLESHOOTING STEPS ATTEMPTED (ALL FAILED):
- ✅ Updated electron-builder from 24.13.3 to 26.0.12
- ✅ Downgraded Electron 38 → 37 → 36
- ✅ Tested x86_64 and arm64 separately
- ✅ Regenerated certificate via Xcode (new cert generated 23/11/2025)
- ✅ Configured App Store Connect API for notarization
- ✅ Tested multiple entitlements combinations
- ✅ Manual component-by-component re-signing
- ✅ Removed all metadata files (._ files)
- ✅ Tested both ZIP and DMG formats
- ✅ Automatic electron-builder notarization
- ✅ Manual notarization via xcrun notarytool
- ✅ Custom afterSign hooks for re-signing
- ✅ gatekeeperAssess true and false
- ✅ Clean builds (removed dist/ directory)
ALL attempts result in identical failure. Local codesign verification ALWAYS passes.
QUESTIONS:
- Why does local codesign --verify pass but Apple notarization service fails?
- Is there a known issue with Electron Framework notarization on macOS Sequoia +
Apple Silicon? 3. Are there undocumented requirements for Electron apps that could cause this? 4. Could this be a bug in the notarization service for this specific configuration?
ADDITIONAL CONTEXT:
- Multiple notarization attempts over 24+ hours
- Different certificates, configurations, architectures - all fail identically
- No similar reports found in forums or GitHub issues
- Application functions correctly when Gatekeeper is bypassed
- This is blocking production distribution to macOS users
This appears to be either:
- A bug in Apple notarization service for Electron apps
- An incompatibility between electron-builder 26 + Electron 36/37 + macOS Sequoia +
Apple Silicon
The fact that local verification passes but notarization fails suggests the issue is with the notarization service validation logic, not the actual code signatures.
REQUEST: Need guidance on resolving this issue. Standard documentation and troubleshooting steps have not resolved the problem.
Thank you for any assistance. Staszek Pliszko
Why does local codesign --verify pass but Apple notarization service fails?
I’ve seen this happen for a couple of reasons:
- Case sensitivity
- Packaging
To test the first:
- Create a case sensitive APFS disk image.
- Use the Finder to copy your app to it.
- Run your
codesign --verifytest against that copy.
On the packaging front, it’s common for apps using third-party tooling to not follow the guidelines in Placing content in a bundle. When that happens, the app can end up with a code signature that relies on extended attributes. And when that happens you can run into problems during notarisation because of the various ways that those extended attributes are packaged.
To test this:
- Build your app to a disk image.
- Use
xattrto check entire app bundle for extended attributes starting with thecom.apple.cs.prefix.
Finally, I want to address two other things that are unlikely to be the cause of this issue but you should fix anyway.
com.apple.security.cs.allow-jit … com.apple.security.cs.allow-unsigned-executable-memory
This is a mistake, because latter is a superset of the former.
com.apple.security.cs.disable-library-validation
This is likely to cause you problems with Gatekeeper. Unless your app needs to load native code created by other developers — typically I only see this when an app supports in-process plug-ins — you should remove this.
For more on this, see Resolving Gatekeeper Problems Caused by Dangling Load Command Paths.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"