Using nucleos within an KMP application submitted to the apple app-store and how to deal with the dylib signing

[EugenMayer]

What is the plan with nucleus and submitting an app to the appstore that needs

1. every dylib to be universal (via lipo)
2. every dylib to be signed

Point 1:

I can build nucleus under arm64 and x64 and than extract the dylib from the jar, thant create a new dylib via lipo ot have a universal library. How is nucleus than loading the library, should the library be name - should it be a -arm64 / -x86 as both being universal (simple to kmps skiko) or can we just use a single dylib?

Point 2:
We would need to have the dylib outside the jar in our lib where it gets signed by our process so it can be loaded in the sanbox mode.
Is there any similar way as with skiko setting skiko.library.path so the dylibs are loaded from outside the jar (where there are universal and signed).
I searched the issue queue and found #317 as being probably related, but i'am not sure about that entirly.

Any help would be appreciated.

[mipastgt]

Isn't that question made obsolete by the fact that x86 has reached its end of life?

[EugenMayer]

Not yet, apps are still required to be universal (i think final EOL is 2027?) But besides that, signing is an issue nevertheless.

But as far as i can see, the Nucleus load does first search in java.library.path before using the jar, so putting the dylibs there (notification and launcher) might be the way to go, right?

[mipastgt]

I actually meant the EOL of Compose on Intel Macs. See: https://kotlinlang.org/docs/multiplatform/compose-compatibility-and-versioning.html and the signing is done by nucleus. Pure ARM apps are allowed in the app-store if you set the minimum system version to 12.

[EugenMayer]

Please let us not drag this discussion if universal is still needed or not and how to circumvent it - it wis not relevant to this issuea as an essential facto

Even though i have put

• libnucleus_notification.dylib
• libnucleus_launcher_macos.dylib

into my lib folder and thus java.library.path

the dylibs are till loaded from the jar:

java.lang.UnsatisfiedLinkError: /Users/au/Library/Containers/de.kontextwork.goedit/Data/Library/Caches/nucleus/native/darwin-aarch64/1936059183-119472/libnucleus_notification.dylib:

I expected that with https://github.com/NucleusFramework/Nucleus/blob/main/plugin-build/plugin/src/sandboxShim/java/dev/nucleusframework/sandbox/NucleusSandboxLoader.java this is the way this should be implemented

Any hints on that?

[mipastgt]

Have you ever tried to just let Nucleus do its job without fiddling with the libraries yourself? The process is described for the CI/CD pipeline very well here: https://nucleusframework.dev/en/docs/packaging/ci-cd/

[EugenMayer]

In the end, the current way Nucleus uses to ship native libraries will not work for the Apple App Store in any way.

The reason is, that dylibs that are bundled within a jar need to be unpacked to a non-bundle folder during runtime. This happens automatically. Loading them from that folder, even if those are signed dylibs, is not allowed, and the apple appstore sandbox will fail.

To fix this, you need to

1. unpack all dylibs from the jar (and optionally remove those from the jars) and put it an a lib folder
2. combine those arch specific dylibs into universal dylibs (if you want universal) (for each like launcher, taskbar, notification)
3. sign those dylibs during your signing process
4. Make sure that your java.library.path references this lib folder so Nucleus Loader will actually use those dylibs during the runtime

[mipastgt]

If you think so, you should make this a bug report and not a discussion.