https://kotlinlang.org
Join Slack
I'm very dissapointed with `Proguard` in `Compose Desktop`. First I developed a normal project with ...
# compose-desktop
p
I'm very dissapointed with 
Proguard
in 
Compose Desktop
. First I developed a normal project with some minor functionalities, using 
retrofit
, 
room
, etc... and It was absolutely IMPOSSIBLE to enable proguard on the release. Doing it produced a crash so I was forced to disable it and finish my production app without obfuscation. Now I developed a much more simple app, without 
retrofit
, without 
room
etc... a very simple one. Just 
viewmodel
, 
corutines
, and a few things. It's very simple. Well, it's impossible too to make it work with 
proguard
obfuscation enabled. I really like 
Compose Desktop
and I hope I will be able to release games in 
Compose Desktop
, which is one of my primary objectives, but without obfuscation I can't see 
Compose Desktop
as a trully production ready environment. Why? Because it can be super easily decompiled, as it haves 
java
under the hood and I checked that I can see almost all the source code of my release apps without 
proguard
enabled. Is there any work in progress for making proguard really compatible with Compose Desktop?
I tryed searching in google for proguard rules for viewmodel, corutines, room, retrofit etc... and it was hard to find some, because these rules are set automatically by gradle on Android, so they are often not published. Also nothing assures that these Android rules will work on Compose Desktop. I tryed with every rule I found, hundreds of lines of rules, and the projects still failed. I also tryed only obfuscating my package, using a keep rule over a negation of my package, but it didn't work. If it were possible to keep everything untouched but our package, then maybe the issue can be solved, but it's not possible as I tested.
If someone in jetbrains or Proguard is reading this, please, give me any light about the future of obfuscation in Compose Desktop
r
On Android rules are bundled with the libraries themselves. Gradle doesn't have its own set of rules for random libraries. Here is for instance one of Room's rules files: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:room/room-runtime/proguard-rules.pro
p
sorry for my bad explanation, I mean that the rules are set automatically when compiling with android studio on Android
r
Also obfuscation still allow for decompilation. It's just more tedious to understand the output 🤷‍♂️
p
well, it's not the same to understand a class with 500 lines full of a1.b1() b1.c1+d1, than to understand a normal class with names
it's 100 times easier without obfuscation
so obfuscation is a total requisite when you develop on java/kotlin, as is really easy to see the code
r
🤷‍♂️
p
if google or jetbrains want people using their technologies in production, they should offer a way to hide the code
as they do in Android
r
The main benefit I see for proguard on Android is making the binaries smaller. Obfuscation will hardly stop anyone who truly cares about understanding your app.
But yeah it should be easy to setup
p
I don't think that, maybe you are a super expert in understanding obfuscated code
but a normal person will stop trying after watching a class with 500 lines full of obfuscated variables and functions
obfuscation is totally necessary
j
ProGuard is already compatible, but you're using things which are highly dynamic and require figuring out the appropriate rules to ensure what's needed is kept and that it's done so in a way compliant with the dynamism of each library.
p
well, I tryed, I ensure you I tryed, a lot, and asked for help here and in other channels, I finally give up, and I'm not the only one I found here which is directly disabling proguard as it breaks his release products
I'm not sure how many hours I dedicated to it, but a lot
If only proguard gives us the possibility to just obfuscate one package, our package, and leave untouched everything else, maybe the issue can be solved simply with that, but not possible
j
You can absolutely do that
The class specification part of the keep rule allows negation. So you'd keep everything except a specific package.
This was what we did for our Android app back in like 2013ish when apps were still small enough that all we needed was to hide some IP
p
As I told you on the OP, I tryed that negation rule
didn't worked at all
don't ask me why, but it doesn't work
maybe it's an issue with proguard on Compose Desktop, maybe it's something has stopped working sometime
but it doesn't work
I got exactly the same crashes, 231 warnings and issues with and without that negation rule over my package and the keep word
j
Does it work on the ProGuard playground? Or do you have a link to a bug you filed about it?
p
I don't know proguard playground
j
You'll still get warnings for missing type references even if you're targeting only a single package, as the entirely of classes are processed
p
I didn't fill any bug anywhere
j
If you only want to run on one package you can put that into a library, run ProGuard or R8 over that, and then pull it into your app with ProGuard disabled. It will be somewhat like an SDK then
👆 2
p
that doesn't seems a valid solution to me, if I understand you, you are telling me to take my apps/games/etc.. and transform them into a library, and then add it to a empty project that will take my real app as a library, with all the things that implies, for example, I even don't understand how can I use all my dependencies doing that without breaking proguard again, my code requires all the dependencies that are making proguard explode
seems a ugly workaround even if someone makes it to work
but thanks
I think whould be better to simply give us an easy way to use proguard, like we do on Android
and not this current nightmare we have
j
No, that is not what I suggested. I said to take the one package you do want to obfuscate and move it to a library.
p
what? it's my entire package, my entire source code
g
Is it really an issue of Compose? Proguard is working with JVM applications before Compose or even Android existed. It's not so simple, but it is also not something impossible to do. but it really hard to discuss without understanding what is actually doesn't work for you
k
In general such tools as Proguard are less popular on desktop because no one cares about the app size. It matters for mobile apps usually. the obfuscation is not convinient as well, because, to be real, desktop's apps are not so popular as android's. Usually JVM apps are server backends. They don't need to be obfuscated or minimizied. AGP configures all proguard's stuff by its own. for desktop you are suppose to do it by your own
p
Konstantin, I really enjoy Compose Desktop, I like it a lot, it allows me to develop desktop applications at the same time I can easily por them to other platforms (mobile, etc... even web)
maybe Compose Desktop apps are not so popular as android or servers, but Desktop apps are so popular in general, you can see an entire world of possibilites out there, like Steam for games, Windows Store for normal apps or games, etc...
if Compose Desktop keeps being grown, it will be a very good
It must be improved, yes, but it is already very good
I hope it will not be abandonned and will continue being maintained, it's wonderful to be able to do apps for desktop using more or less the same things you use in mobile
it is so great to be able to build an app for Mac/Windows/Linux at once
with all the benefits and power of compose
probably, giving the developers some help with things like code obfuscation will increase the possibility that more companies or indie devs start releasing desktop apps with Compose Desktop
I'll continue learning and it will be my main objective even with these issues, I really like it and hope it will have a great future
203 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by