In case it helps anyone, I have written up a post on applying Proguard on Compose/Desktop here: <htt...

# compose-desktop

[Mike Dawson]

In case it helps anyone, I have written up a post on applying Proguard on Compose/Desktop here: https://medium.com/@mike_21858/using-proguard-with-jetpack-compose-desktop-size-reduction-performance-gains-and-pain-481a014c6b0a

[Michael Paus]

You are always talking about “obfuscation” but this is not the relevant feature for the size reduction. You can mainly achieve the same without it. Here is my ProGuard configuration.

proguard {
    version.set("7.4.0")
    isEnabled.set(true)
    optimize.set(false)
    obfuscate.set(false)
    configurationFiles.from(project.file("<http://compose-desktop.pro|compose-desktop.pro>"))
}

The main point is to enable ProGuard. I then switch off obfuscation and optimization because I found that their benefit is small on desktop and they are causing their own problems which are just not worth the effort.

To further shrink your code it would be much better to repack the sqlite library so that it just contains the binary for the respective platform you are building for. (I did that and it works nicely. I wonder why ProGuard can’t do that itself.)

Yet another option would be to vote to get this issue fixed which just wastes more than 20 MB on ARM macs. https://github.com/JetBrains/compose-multiplatform/issues/3859

[Mike Dawson]

Enabling proguard without obfuscation is an interesting option, maybe something that should be mentioned in the docs. I just tested that, in my case, it adds 12MB (vs using obfuscation). At the moment, I'm not supporting MacOS.

[Michael Paus]

Yes, it adds a little more code (percentagewise) but it saves you from all the problems which may come with obfuscation itself. (Same for optimization.)

[Mike Dawson]

problems that "may" come with obfuscation? There were plenty of problems. I filed at least 4 issues for missing rules / bugs (even KTOR client serialization fails on JVM, when using obfuscation, even if you apply the rules you find in the project that are used on Android)

[Michael Paus]

Not all such problems are related to the obfuscation. ProGuard is still stripping your binary from code which it thinks isn’t used but this thinking is not always correct for all the known reasons.

[Mike Dawson]

True - removing unused code would be what achieves a lot (most) of the size reduction, but I'm not sure if the size of the binary of the used code would be reduced... so not sure what that means when it comes to performance of the code that remains

[Michael Paus]

I did not notice any performance differences. A modern desktop JVM can deal with that. I am bundling my desktop apps with Java 21.

[Mike Dawson]

Thanks for the observation, FYI I updated the article to mention the possibility of not enabling obfuscation (which I don't think is suggested on the official docs)

[Mike Dawson]

Performance measurement of the difference would be interesting, but that's for another day...

[Mike Dawson]

In the meantime, would be good if the examples etc. are updated so that using proguard (at least in some form) becomes defacto norm, libraries get documented/tested when Proguard is applied, etc.

[Michael Paus]

As far as I know it is enabled by default for all release builds. So, any testing should of course be done only on release builds. Otherwise you are comparing apples with oranges.

[Mike Dawson]

Right... so the 171MB I saw was the size of the .deb that was created by conveyor with default settings, so it seems like conveyor by default was choosing the non-release version

[Michael Paus]

Conveyor has its own build system. I don’t know whether it used ProGuard at all. When I am talking about defaults then I am talking about the JetBrains build of course.

[mikehearn]

Conveyor uses the JARs as produced by the build system. You can feed it any JARs, perhaps Gradle is giving it non-obfuscated JARs, this seems likely, but you can always override that.

[mikehearn]

When configured to use native library extraction it can and will strip out any shared libraries that are for the wrong CPU/OS combination, so you don't need any extra work to get rid of those.

[mikehearn]

This can reduce the size of the download significantly.