Has anyone been successful with using Proguard on ...

# compose-desktop

[Mike Dawson]

Has anyone been successful with using Proguard on a compose desktop release? I have checked the docs here ( _https://github.com/JetBrains/compose-multiplatform/tree/master/tutorials/Native_distributions_and_local_execution#minification--obfuscation_) and looked at the example project ( https://github.com/JetBrains/compose-multiplatform/tree/master/gradle-plugins/compose/src/test/test-projects/application/proguard ).

It seems like on JVM we don't get the automatic consumption of proguard rules from dependencies (when I manually add proguard rules for OkHttp, that come automatically with Android, my issue count goes down).

My app is weighing in around 70MB (on Android after obfuscation it's 10.5, approx 40MB before obfuscation), so definitely want to get this working if possible.

[Mike Dawson]

Good news: after adding various proguard rules (mostly dontwarn that seem to be related to compileOnly dependencies, almost certainly not needed because it ran fine without them) it cuts the final conveyor .deb package size from 160MB to 80MB.

Bad news: have to deal with class not found stuff,

Worse news: Seems like the mapping.txt is missing which makes the above even more fun

[Mike Dawson]

Proguard cuts the conveyor distributable size down from 160MB to 95MB (using not very aggressive settings). I haven't done proper measurements, but the app definitely feels a fair bit faster (e.g. as is the case on Android comparing the debug version and the release version)

[Adam Brown]

in theory, with K2 would we not need Progaurd? Could it perform dead code striping and other optimizations on it's own?

[Stefan Oltmann]

I needed to disable ProGuard for Ashampoo Photos once because of issues with commons-compress. The result was double the size of the installation and slower execution speed. Originally I introduced ProGuard only for obfuscation, but now I feel it’s a must have even for performance.

[Stefan Oltmann]

Someone in this channel posted a Gist about his very advanced ProGuard settings after a lot of finetuning. I think you need to scroll up a bit to find it.

I hadn’t the patience to deal with that and aside the default rules for ktor & serializaion (can be copy pasted from the GitHub project readmes) I have a rather simple

-keep !com.ashampoo.photos.*

That is far from optimal, but already has significant gains.

[Stefan Oltmann]

I definitely agree on that it’s easier for Android due to the automatic consumption. My Android app has a proper configuration and I believe I don’t even added own rules. Works out of the box. Would be nice to see that in Desktop one day.

[Stefan Oltmann]

I added DeepJavaLibrary to Ashampoo Photos for Desktop and without ProGuard it’s whopping 600 MB zipped while with ProGuard it’s only 250 MB zipped. We sometimes seem to have really huge libs.

I remember how Apache commons had those nice fine grained dependencies while Google came up with this Guava monster, which had everything cramped into a single library and stating „just use ProGuard“ in the readme.

For my old Android Java app this was the point where ProGuard became a hard requirement because Guava alone had more than 65k methods - this was the limit for a single DEX back in the day. 👀

[Mike Dawson]

I think the tool itself (e.g. Proguard, R8, K2?) isn't the issue. The issue is making sure code cooperates with being obfuscated. As long as there is use of reflection (which on JVM includes service providers), then there will need to be keep rules for those specific classes.

[Mike Dawson]

Also: developer hardware skews heavily high-end. Many "normal" users have much less powerful machines.

[Mike Dawson]

... before we get to automatic consumption - just documenting required proguard rules would be a start.

[Mike Dawson]

I found Proguard will even remove the Main Disaptcher unless you add extra (undocumented) rules: https://github.com/Kotlin/kotlinx.coroutines/issues/4025