App Startup Issues after Upgrade to MacOS Sequoia

[Lmsshepard]

Java8 Springboot Maven built App (IntelliJ with Fvarrui javapackager plugin) will not start now that I have upgraded to MacOS Sequoia. Prior to upgrading to Sequoia I did not bother to code sign app or get it notarized. Now, having upgraded to Sequoia, code signing and notarization by Apple is required. I have added the appropriate setting to the pom.xml file within the javapackager plugin section to code sign and notarize. Although there are a couple errors, the App gets submitted to Apple, notarized and stapled fine. However, when I click the App, it fails to launch. I have read issue#448 and tried the various suggestions, but none work.

When I do NOT specify "macStartup" or a custom launcher (i.e. native ARM64 or Universal ARM64), I am able to click on the universalJavaApplicationStub to launch the App. Any other launcher will not work when either clicking the App itself to launch or one of the other script (i.e. native ARM64 or Universal ARM64). Another thing to note is the when using the default - universalJavaApplicationStub the build info steps indicate that the universalJavaApplicationStub replaced the code sign without error. When trying either of the other 2, the replace code sign fails.

Lastly, as mentioned above when using the default exe script (universalJavaApplicationStub) the code sign replace works fine, however, the App code sign replace fails. Regardless of this failure, the app builds and is submitted for Notarization and Stapling and both pass.

[Lmsshepard]

I intended this to be addressed by Fvarrui who authored the javapackager. I am attaching pertinent files.

SysConsoleOutput.docx
Launch Error.docx
Build Output.docx
Info.plist.txt
pom.xml.txt

[Lmsshepard]

[Lmsshepard]

Adding additional information / template:

Short description of the issue/suggestion:
After upgrading to MacOS Sequoia and being required to code sign and notarize my app, cannot launch app even though code sign and notarization pass

Please tell us about your environment:
MacBookPro
Chip Apple M2 Max
32 GB
JavaPackager version: 1.7.6
OS version: macOS Sequoia 15.0.1
JDK version: jdk-1.8
Build tool: Maven

Steps to reproduce the issue:
DMG Maven Build of Spring Boot /Java (version 8) application with JavaPackager using default universalJavaApplicationStub. Code signing and Notarization / Stapling PASS and App installs in Application folder, however cannot launch App. Although code sign and notarization pass, it is interesting that in the build output, prior to it submitting to Apple, there is a error stating that the App code sign could not be replaced.

What is the expected behavior?
App launches when double clicking the application icon

What have you tried to resolve / workaround the issue?

1. customLauncher = universalJavaApplicationStub.arm64 (macStartup = UNIVERSAL or macStartup = ARM64). Build output shows error with universalJavaApplicationStub.arm64 code sign replacement. However App builds and passes code sign and notarization/staling. Still cannot launch App.
2. customLauncher = nativeJavaApplicationStub.arm64Activity (with macStartup = ARM64). Build output shows error with universalJavaApplicationStub.arm64 code sign replacement. However App builds and passes code sign and notarization/staling. Still cannot launch App.
3. Install via package rather than DMG - same result
4. Can launch App by opening up the app Content/MacOS folder and clicking directly on the universalJavaApplicationStub. Note requires that you allow it to run within the Security and Privacy settings.

Attachments:
See previous comments where I have attached the following:

1. pom.xml
2. info.plist
3. maven App build debug output
4. System Console output (after trying to launch app)

[fvarrui]

Hi @Lmsshepard!
I'm very sorry to reply so late 😥 . I hope I can spend some time researching about your issue and I'll try to give you an answer ASAP.
Thanks for your patience!!

[Lmsshepard]

Hello - thanks for replying and letting me know you are a bit behind. I have since created and extremely SIMPLE program to demonstrate the issue I am having. I created, under the same java8 / maven-build program configuration detailed in the posts above, a SIMPLE HELLO WORLD program to demonstrate the issue that I am having. The exact same results occur. I have attached all pertinent information for you to review. I appreciate your time and timely response as we have been stuck on this issue (and a related JRE bundle issue that I will post separately as to not to confuse this issue) for 3 months now and it is holding up our production. THANKS IN ADVANCE FOR YOUR DEDICATION AND TIME!

TerminalSignAndNotarizationChecks.txt

Terminal Launch Attempt - Error.txt

ConsoleLaunchError - Test2 Filter.txt

Test2 Build Output.txt

Info.plist.txt

pom.xml.txt

entitlements.plist.txt

[Lmsshepard]

I also would like to remind you that, as mentioned in the initial post, I am able to go into the apps Contents/MacOS folder and click on the universalJavaApplicationStub to launch the app that way. Hopefully that is a clue.... Thanks.

[fvarrui]

Hi @Lmsshepard!
I've seen in your logs that you are packaging with JP 1.7.3.
Not sure if this will help, but could you try to package your app using 1.7.6?
I can't remember if there's a change in JP that can fix your issue, but let's try it.

I'll keep researching about this.

Every time Apple updates their OS is a mess for JP 😞

[fvarrui]

I've also seen that you are not packaging a Java runtime with your app ... could you try to bundle a JRE using jrePath?

Maybe we need to set a new entitlement in order to run a Java app on Sequoia?

[fvarrui]

I've just read your issue on Apple forums.
I hope they can throw some light on this.

[fvarrui]

Please, have a look into this issue: #448

[Lmsshepard]

Hi, I tried version 1.7.6, but unfortunately I have the same result. I was bundling the jre with the application initially and there were issues upon startup using the bundled jre. To simplify the issue request, I was focusing on just the startup issue first. Let me know if you want all the logs etc... from the launch attempt with the bundled jre. I also have read mixed messages regarding entitlements. I actually am unsure which to claim so have tried some suggestions, but obviously still mo luck.

[commi]

Can you run

syspolicy_check distribution <bundlename>.app --verbose (available in 15)

This helped us to get a javapackager built app up and running on macOS 15. The symptoms were different, so i have no fix, but this new helped.

Other than that, we used a custom jrePath with a macOS-JRE from Adoption for the appropriate arch and built separate bundles for each arch, to avoid that can of worms for now:). You can try a x86_64 built, and see if that runs via Rosetta, to narrow down on the problem.

[Lmsshepard]

Hi - below is the output from the syspolicy_check:

% syspolicy_check distribution Test2.app --verbose
Checking distribution readiness on Test2.app
Passed codesign --verify -R="notarized" --check-notarization
Passed xptool
Passed Gatekeeper scan
App passed all pre-distribution checks and is ready for distribution.

[Lmsshepard]

Regarding your other comment:

"Other than that, we used a custom jrePath with a macOS-JRE from Adoption for the appropriate arch and built separate bundles for each arch, to avoid that can of worms for now:). You can try a x86_64 built, and see if that runs via Rosetta, to narrow down on the problem"

I am not sure what you are asking me. I have tried to bundle with a jrePath prior to this posting. I run into the same exact issue as mentioned already. I took that out for now so as not to confuse things. Do you want me to add it back in and show you the output? I can do that if so..... I am not sure what you mean by trying a x86_64 built, and seeing if that runs via Rosetta..... I am not familiar with Rosetta and my architecture is ARM64. Let me know next steps. Thanks.

[commi]

for us the syspolicy_check showed problems with the bundle structure, which resulted in similar error messages on launch, but that dies not seems to be the case for you.

regarding JRE: We found that MacOS on Arm behaves differently when launching Arm-binaries vs when launching x86-binaries, and that it did not always launch an universal binary in Arm-mode. And that it seems to be more picky what the bundle-structure is, in Arm-mode. So to narrow it down you could try with x86_64 universalJavaApplicationStub and x86_64 JRE. There are no steps involved on launch, Mac will just use Rosetta in the background when the binary has no Arm-code.

And: when you launch the default universalJavaApplicationStub directly (which works), what arch has the spawned Java-process (should be visible in Activity Monitor)?
Because the script itself has no 'architecture' and there are JRE available with Arm/Intel and universal binaries. (we use Adoptium, not universal, but for Intel /Arm in separate builds, that's why i mentioned it)

[Lmsshepard]

Hi, just wanted to point you to the following issue entered on Apple Developer. It sounds just like my issue. https://developer.apple.com/forums/thread/765950

[Lmsshepard]

Hello, after hours trying to troubleshoot this issue I think I can point you to where to look for the problem may be. As mentioned earlier, I am building with Java8 and trying to bundle java8 with my application. When I do that Application won't launch - I get the error mentioned above when I double click the App. If I do NOT bundle a jre, the App launches fine! I really want to bundke the jre. Additionally, I mentioned in above posts that by clicking the universalJavaApplicationStub directly, the App can launch, but after examining the System Console, I can see that it is not using the bundled jre, but a different jre it found on my machine. I am running 1.7.6 version of your javapackager. I cannot rule out some codesign issue, although running all codesign checks on the command line pass ( although command line codesign checks against the app pass, as mentioned in initial posts, the build ouput in intellij does output errors trying to replace signiture in all java dylibs). Notaruzation passes as well... I appreciate your help.

[Lmsshepard]

Hi, I decided to change my Hello World build to be a java 23 version instead to see if there where differences in behavior from java 8.

When packaging with the fvarrui javapackager and bundling setting bundle jre to true, app will not launch. The javapackager output shows codesign errors "replacing existing signature" for all java libs. Also see same signing error for the app itself. Despite these errors, notarzation passes. But app will not launch. Note that I tried codesigning one of the java libs manually at the terminal by copying and pasting the exact javapackager command that was output to the screen, and from the terminal I have have success signing that same java lib within the app structure that the javapackager created. Can you figure out why it fails when the packager executes it?

If I do not bundle the jre, the App builds and notarizes without error and launches fine.