Hey there :wave: I'm trying to publish my app on t...

# compose-desktop

[Marco Gomiero]

Hey there 👋
I'm trying to publish my app on the mac App Store. I was able to publish it to testflight, but the app is crashing because it can't load the dylib of jdbc. I'm using sqlite with SQLDelight. I've found in the doc that you can use fromFiles in such cases. I've tried to add it in the gradle configuration, but the lib seems not to be inside the folder build/compose/binaries/main-release/app/FeedFlow.app/Contents/app. I got the dylib from the jar of the library (https://github.com/xerial/sqlite-jdbc/blob/master/src/main/resources/org/sqlite/native/Mac/aarch64/libsqlitejdbc.dylib)

What I'm doing wrong? Or what you suggest doing to have sqlite-jdbc working right on the app store?

[Michael Paus]

Can you run it locally via the Gradle task runReleaseDistributable?

[Marco Gomiero]

So, it starts failing locally only after adding the entitlements like required here.

With error 137, which afaik is for out-of-memory 🤔

Execution failed for task ':desktopApp:runReleaseDistributable'.
> Process 'command '/Users/mg/Workspace/KMP/feed-flow/desktopApp/build/release/main-release/app/FeedFlow.app/Contents/MacOS/FeedFlow'' finished with non-zero exit value 137

[Marco Gomiero]

I made some updates. As i saw in this thread, I've added the native lib in the final app package, but when running the app from testlight, it seems that the library sqlite-jdbc is extracting nevertheless the lib on the tmp folder. What am I missing? How to prevent the extraction?

(If I exclude the library at all (from app.cash.sqldelight:sqlite-driver) it fails with Caused by: java.lang.ClassNotFoundException: org.sqlite.core.NativeDB)

[Michael Paus]

Have you seen this? https://github.com/xerial/sqlite-jdbc/issues/383 It may be helpful. A key seems to be this: System.setProperty("org.sqlite.lib.path", PATHTOFILE);

[Marco Gomiero]

Thanks! Yes that was helpful and fixed the issue!

[Michael Paus]

Could you summarise the final extra steps here that are necessary to get a desktop application, which uses SQLDelight (or any other library which contains native parts), into the AppStore? This might be helpful for others because this information is missing in the official docs.

[Marco Gomiero]

yes, I will write an article about it soon!
(And share the configuration here, since the project is open source)

[Marco Gomiero]

"Soon" ended up to be be 4 months, but here we go
https://www.marcogomiero.com/posts/2024/compose-macos-app-store/

[Michael Paus]

Better late than never 😉.

[Michael Paus]

This is very helpful if you are developing for the Mac. I have one question though. Why don’t you always do what is necessary for the Mac App Store? As far as I can see this would work and would make the build config more consistent.

[Marco Gomiero]

Fair point. It will work. I'm keeping it separate only to not embedded two times the native libraries when I'm not deploying to the app store.

[Michael Paus]

For that purpose I am using a variant of the driver jar where I have stripped out ALL native libraries because with the default setup you will always carry them all with you. ProGuard also does not seem to be able to strip out the unused ones.

[Michael Paus]

I have just finished converting my desktop app to the scheme you have outlined concerning the treatment of native libraries. In retrospect I found a few things which I finally did differently from what you have proposed. The starting point is an application which uses more dependencies with native parts and not only SQLite.

1. I applied the same scheme to all platforms and not only the Mac. I did that to make the whole build more consistent and to be prepared for similar restrictions, like the ones for the AppStore, on other platforms too.
2. I created a variant of the respective JAR files where I stripped out the native parts completely, so that each JAR becomes platform agnostic.
3. I did not set the properties like you did.

System.setProperty("org.sqlite.lib.path", resourcesPath)
System.setProperty("org.sqlite.lib.name", "libsqlitejdbc.dylib")

You are relying on the existence of library specific properties here which other libraries may not provide. I also did not set the org.sqlite.lib.name because it is not necessary and because the naming conventions are different on each platform.

I found it to be better to only set this instead.

System.setProperty("java.library.path", "${System.getProperty("java.library.path")}${File.pathSeparator}${System.getProperty("compose.application.resources.dir")}")

I just added the compose.application.resources.dir to the already existing java.library.path. This is a general mechanism which most libraries support. This worked for me and I hope it will also work in the AppStore.

[Marco Gomiero]

Interesting. Thanks for sharing!

Yeah, in fact for another library I'm setting the path with another properties"

System.setProperty("jna.boot.library.path", resourcesPath)

maybe makes more sense to uniform it.