A random question What's that one reason your comp...

# random

[Niraj Patidar]

A random question
What's that one reason your company is not adopting compose?
I'll go first. For us, apk size matters a lot, and we try to optimize it as much as possible, in KBs. Writing compose code increases significant amount of apk size, which is verified by google team as well. Thread

[Stefan Oltmann]

Why are these few KB so important?
People have LTE connections or fast WiFi and phones have 64 GB of memory or more.
It’s not like you add 20 MB to your APK size or something like that.

[Zyle Moore]

A couple of the thing mine has said
• We don't have bandwidth to convert it
• We have Swift experts, not Kotlin experts
• We looked into it, and we found it was technically infeasible
• We have other priorities that we need to complete before considering a total rewrite
• We have plans committed for the next quarter/year, and converting would require us to rewrite the new stuff we haven't finished yet
Not great reasons IMO, but they don't pay me enough to make those decisions

[Pavlos]

• We have Swift experts, not Kotlin experts
◦ Way easier for them to write in Jetpack Compose instead of XML.

[darkmoon_uk]

Unless it's for some specific technical reason, I cannot understand basing this decision on the meagre increase in APK size.
@Niraj Patidar Realistically, is there any evidence that your target market cares as much about the download size, as your company seems to?

[darkmoon_uk]

I have been in a situation where we had to reject Compose on performance grounds - we were developing for an OEM Android 'appliance' with the cheapest chipset that unfortunately did reveal a marked performance degradation with Compose. That one hurt - is there some comparable reasoning going on with the APK size?

[joseph_ivie]

Compose Web doesn't create good enough outputs (way too big, no SSR possible), and we write lots of Android/iOS/Web code.
We DID adopt KMP though, and we just wrote our own UI framework called KiteUI. It's still being refined, but is used in production and has worked out pretty well for us. It uses native view hierarchies under the hood.
We're considering making a Compose backend for it though - Desktop support would be nice, Compose Desktop seems to reasonable.

[Niraj Patidar]

For our India-only audience, every single MB hurts. At our DAU scale, even a tiny 1% drop-off is a massive hit to the business. There are majorly two reasons
Can't Install
• Storage : User has no space. Download fails.
• Data : User's daily data cap is low. Our app is too big to download. (In India, most people are on Mobile Data pack as it's cheaper and more accessible, and it comes with 1.5GB/2GB/3GB daily data caps)
Context Loss
• While it's downloading, the user gets distracted by notifications or just moves on. We lose them because they lost the context from the ad that brought them in.
In the past there have been significant hit's to our DAU due to increased APK size, hence we optimize for those extra KBs as well.

@Stefan Oltmann // @darkmoon_uk

[Stefan Oltmann]

Interesting insight. Now I understand.

[gildor]

Sorry, but I'm still skeptical that Compose would be the reason and that potential size increase is such a bug deal on practice.

Keep app size is important, but I'm still very skeptical that it is meaningful reason and that it will be your biggest size reduction challenge

[gildor]

Also, as I see, your app actually using compose, i see it in class files

[gildor]

I feel that focus on code shringking is more important than that, just by looking on your classes.dex, because definitely not every kb matter there

[darkmoon_uk]

Yeah, that doesn't really add up to me either - what happens when your competitors App starts getting more attention because it has a nicer UI and better features - are your users going to say "I'll stick with NP's App, because it takes up 20MB less on my device". I think not.

[gildor]

Size is still important though, I just feel that over-focus on some potential increase, which brings other advantages, is not the best way to go if you actually do not work in all other areas

[gildor]

Of course there are other considerations for decision to use or not to use compose, but boil it all down to "app size" is all extreme oversimplification, or really missing the point

[Niraj Patidar]

We've SDUI functionality which is built over the compose, and we used to work on compose a lot but once we deep dived on why compose PRs had this much increase in apk size, we try to do it on views rather than compose.

[gildor]

In this case it's fair enough, but again, I feel that it quite a bit of synthetic measurement, I definitely see room for optimization by glance view on your app apk. And obviously declaring UI in code creates more classes, which increase code size, but at the same time overall impact way harder to measure, concidering other inheritet advantages of compose.
And optimize images, review third party libraries and code shrinking optimizations could give you way bigger size reduction on practice