GeezerVison is showing github.com — Mac release build fails with code signing issue · Issue #1507 · processing/processing4
Mac release build fails with code signing issue #1507DescriptionMost appropriate sub-area of Processing 4?
Build process
Processing version
4.5.3
Operating system
macOS
Bug description
Release level builds fail on macOS at the notarization step (see last release build run output) Testing locally, when you run:
./gradlew app:packageDistributionForCurrentOS
And then examine Processing.app with the codesign tool:
codesign --verify --deep --strict --verbose=2 <path-to-processing>
The output says "a sealed resource is missing or invalid" and that the resources for pde.icns, pdez.icns, and pdex.icns have been added since the app was signed.
Steps to reproduce this
-
Build on mac with ./gradlew app:packageDistributionForCurrentOS
-
Run codesign --verify --deep --strict --verbose=2 <path-to-processing> on the .app created in the build process
snippet
// Paste your code below :)
void setup() {
}
void draw() {
}Additional context
With thanks to Claude and StackOverflow, I've learned that Jetpack Compose's default macOS app signing is not compatible with fileAssociation() so we either need to:
- add a step to the process that re-signs the macOS app after the files have been associated, but before they are sent to the notary OR
- separate how Windows, Linux, and Mac handle file associations so we can keep using the default Jetpack Compose app signing
I have a tentative solution that looks like option 2. I'll share a draft—I only have access to a Mac for development and can't test Windows & Linux on my own.
Would you like to work on the issue?
Yes, I’d like to help with this Reacted by Raphaël de Courville ActivitySableRaf commented on Apr 21, 2026 Thanks @kjhollen for investigating this! 💙
Could you share the link to the StackOverflow discussion? I wasn’t able to find it.
Not sure if this is directly relevant, but sharing for reference: It looks like support for fileAssociation() was implemented in JetPack Compose (see JetBrains/compose-multiplatform/issues/773 ) in 2024. That particular issue doesn’t mention code signing though. kjhollen commented on Apr 21, 2026 @SableRaf StackOverflow was more for helping me (partially) understand the Jetpack compose build system, but it was Claude/Copilot that suggested the fileAssociation issue. But, it seems strange that this wouldn't be listed as an issue, if true—probably a hallucination? I'll see if I can do some more digging today. kjhollen commented on Apr 21, 2026 Okay, to explain further—it looks like we have a custom signing pipeline for macOS because we also unpack jars and sign the native libraries inside them before everything is bundled into Processing.app (which is above and beyond what Jetpack Compose usually does). So with that setup, we can't rely on the normal fileAssociation path for mac because it happens after our custom signing phase. Here's what Claude had to say when I asked if we could just move our signResources step to later in the process:
Yes, but not by just moving the existing task as-is.
Why:
- The current build.gradle.kts signs files in the staged resources tree, not the final .app bundle.
- fileAssociation artifacts are injected during createDistributable/jpackage, after that staged-resource phase.
- So “run signResources later” only helps if it signs the final app image, not the old resources directory.
Practical way to do it:
- Remove the early hook build.gradle.kts.
- Add a new post-image signing task that depends on createDistributable and signs:
Processing.app
- Make build.gradle.kts depend on that post-image signing task.
So the answer is: yes, you can move signing to after fileAssociation materialization, but it should be a post-createDistributable app-sign step (effectively “final image signing”), not the current signResources implementation.
Another alternative is to just keep the pathways for Linux, Windows, and Mac file association separate—I have a version of this working that just needs more testing, especially on Linux & Windows. What do you think @catilac @SableRaf @Stefterv? Stefterv commented on Apr 21, 2026 I would recommend to quickly test an empty project w/o the custom signing and see if it is still broken and if it is an issue within the Jetpack Compose bundler.
For windows it should be fine as file association is handled by the registers adjustments and for Linux idk, I think it will be included in the generated .desktop files kjhollen commented on Apr 27, 2026 I think that Copilot/Claude oversimplified when it initially told me the issue was inherent to fileAssociation and mac app signing. I agree that testing the Jetpack Compose bundler with a simple app is a good reality check. I've tried searching StackOverflow for related issues on Mac as well as the Compose Multiplatform issue tracker (they're no longer using GitHub) but didn't find any.
Even if the problem is on the Compose Multiplatform side, it may take a while before the issue would be fixed and a new release would be issued. I think it's a good idea to patch our build system in the meantime so that we can issue releases again if we need to, and I have something ready for review. catilac commented on Jun 30, 2026
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|