Related to the above, but different question. What...

# compose-desktop

[Colton Idle]

Related to the above, but different question. What's the proper command for ./gradlew deskJar but for a "release" (aka proguard).

I ran ./gradlew proguardReleaseJars but it completes in like 300ms and it seems like there's no size difference. Meanwhile if I run packageDmg and packageReleaseDmg there is a difference in time to run, and about 15MB difference in size. (I ask because I am trying to use conveyor and it requires to run desktopJar before running conveyor make site which is why I'd like to run the "release" variant of desktopJar)

[Colton Idle]

@Alexander Maryanovsky sorry for the ping here.

But my tl;dr is.

Is ./gradlew proguardReleaseJars the "proguard" variant of ./gradlew desktopJar task?

[Alexander Maryanovsky]

I don’t know the answer to that. Maybe @mikehearn knows?

[mikehearn]

Unfortunately not. I'm personally more interested in code streaming solutions than static analysis. Mostly people just want faster downloads, so fetching jar packages on demand over the internet might work better than trying to do dead code elimination. Not sure. Otherwise it might be better to make native-image work as that has more sophisticated tools for identifying used code

[mikehearn]

Still, if you figure it out we could integrate it into the (conveyor) samples

[Colton Idle]

darn. getting tree shaking working in a small sample would be great.

I'm able to at least show that an unmodified template from kmp.jetbrains.com results in

./gradlew packageDmg results in 63.9MB .dmg file
./gradlew packageReleaseDmg results in 51.5MB .dmg file

but ./gradlew proguardReleaseJars && conveyor make site --overwrite results in a example-1.0.0-mac-aarch64.zip of 71.5 MB
unzipped is 121.6 MB 🤯

[Colton Idle]

something just seems wrong with either proguardReleaseJars, or conveyor I guess. Or maybe I'm just missing something fundamental here.

But something just seems fishy

[Colton Idle]

again. im a noob desktop dev. long-time android dev. so proguard is a default for me. but maybe people dont typically use tree shaking in desktop/jvm apps really

[mikehearn]

Well, desktops tend to have more bandwidth. So there's a question of dev cost involved. It's possible the DMG vs ZIP size difference is due to different compression algorithms, perhaps.

[mikehearn]

Or, more likely, it's because Conveyor includes Sparkle

[Colton Idle]

ah. keep forgetting that sparkle is added.

[mikehearn]

You'd want to do a du diff analysis between the extracted contents to work out what's bigger

[Colton Idle]

let me try to see what the dmg installs as when i drag it to my app folder

[Colton Idle]

but ill look into du (TIL)

[Colton Idle]

alright. example.app from example.dmg does clock in at 109.4 MB which at least is closer to 121.6 MB
so i guess dmg is some kind of zip/compression format thingy. so it wasn't really fair to compare the extracted zip (from conveyor) with the dmg from just the regular compose desktop gradle task

[mikehearn]

It's fair! You just have to look at where the extra size comes from. If DMG uses a stronger codec than ZIP that's a point for the DMG format (and it can... but the problem is some desktop users are nowadays CPU limited not bandwidth limited, i.e. with a fast server it can download faster than the CPU can extract it, so we don't necessarily want huge compression levels)

[Alexander Maryanovsky]

These are peanuts, tbh. Unless you have a specific constrained use-case, 100mb or 200mb is not worth worrying about.

[Colton Idle]

maybe ive been mobile dev for too long 😄 None of my android apps are over 10MB

So when I see the possibility of serving 70MB instead of 120MB... it definitely sticks out at me.

ill try to see if i can easily decompile my mac app and see if my code is getting properly obfuscated. I always thought with conveyor that my stuff wasn't actually getting proguarded... but now it seems like it might be. so if i can at least verify some baseline level of obfuscation, then my company should let me ship this thing. which would be a win!

[mikehearn]

You're using parts of Android on desktop, so yeah it'll be bigger as you're shipping part of the OS with your app. If you made a native Mac app it'd be 10MB too.

[Alexander Maryanovsky]

On android, the JVM and rendering engine are already there. On the desktop they’re part of your app.

[Colton Idle]

yeah. i get that theres a price to pay there. im fine with a 50MB or 100MB baseline jvm desktop app if that's what it is.

the issue I was trying to get to the root of was that somehow conveyor was generating a much larger app compared to the ./gradlew packageReleaseDmg which just felt wrong. but looks like i was comparing compressed vs uncompressed "apps"

[Colton Idle]

i.e.
.dmg vs .app

[Colton Idle]

Alright. some more digging today. I think part of my issue with this is that

./gradlew desktopJar goes into composeApp/build/libs

while

./gradlew proguardReleaseJars goes into composeApp/build/compose/tmp/main-release/proguard