How can they be so bloated? Even dictionary app can go beyond 50MB is unbelievable. What are they doing with that? Is Call of Duty embedded in the source code?
They could spend $20 worth of developer time doing it, or they could pocket the $20. Either way, millions of people will continue using their app. It doesn't effect their bottom line.
Images for every screen size. Native executables for every architecture (optionally slimmed to arch specific apks if from Google Play). Translations for every string for every language (string resources), which by the way can't be compressed (or shouldn't be anyway) [1]; although if you don't need your strings to be native resources, you can store them other ways.
Lots of those things are optimized at download time. As a developer you upload an special format called Bundle that has all the code, assest, languages, etc for your app. But at the moment of download for the client it just downloads whats necessary for their devices
Most of it is usually just images. Sometimes designers release them as SVG, but the image is embedded into the file, sort of like a rar in a zip file.
Modern design doesn't really care for size either. There's a reason we did flat design in the past - we'd have fine control over how to stretch a button. Now we have things like glows, animations, 3D stuff, which doesn't compress well at all. As engineers, we've had to push against one glowing effect which add 2 MB.
There's also SDKs for everything, and these SDKs tend to add 10-20 MB here and there.
> How can they be so bloated? Even dictionary app can go beyond 50MB is unbelievable. What are they doing with that? Is Call of Duty embedded in the source code?
1. Big size impress management. 2. It's easier to blame SDK xyz for any issue than try to write something optimized and then debate with subskilled coworkers that are specialised in pushunderthebusing
I thought this was relevant mostly for line of code or similar metrics used to evaluate the size of projects (build sizes not being one of them). Or are you trying to imply that artifically inflating the perceived size of a project can indirectly and consistently affect the build sizes as well?
I really have no idea how companies handle these kind of decisions. It just seem plausible that a semi-technical manager that have to greenlight a project could use the app size as a parameter.
There is no need to artifically inflate the size. I can imagine how a 10x smaller than competitor app could be seen as a sign of a problem more than a positive.
I just pulled up the apps info on my phone and sorted the apps by size. There are 128 apps installed on my phone and 67 are < 100MB. The median size of all the apps is 91MB, although I'm not sure thats fair because the app sizes seem to included data stored within them too. Example: The photo app is 225MB but 2.5GB (as denoted in the sorted-by-size app list) with all the stored data.
I like to read _mangas_, and we have [kotatsu](https://f-droid.org/en/packages/org.koitharu.kotatsu/) for that, as an example, it's very light (<10MB); for what i think it depends on how much an app is optimized, many nowadays have videos and images inside of the package so the final app is huge, also many dependencies makes the app more heavy.
16 comments
[ 3.5 ms ] story [ 43.2 ms ] threadhttps://f-droid.org/en/packages/io.github.saveastxt/
[1] https://developer.android.com/topic/performance/reduce-apk-s...
Modern design doesn't really care for size either. There's a reason we did flat design in the past - we'd have fine control over how to stretch a button. Now we have things like glows, animations, 3D stuff, which doesn't compress well at all. As engineers, we've had to push against one glowing effect which add 2 MB.
There's also SDKs for everything, and these SDKs tend to add 10-20 MB here and there.
I haven't looked at installed package size in a while - and I use an app store known for lightweight apps!
1. Big size impress management. 2. It's easier to blame SDK xyz for any issue than try to write something optimized and then debate with subskilled coworkers that are specialised in pushunderthebusing
I thought this was relevant mostly for line of code or similar metrics used to evaluate the size of projects (build sizes not being one of them). Or are you trying to imply that artifically inflating the perceived size of a project can indirectly and consistently affect the build sizes as well?
Here's an example of a deep dive into Candy Crush on iOS/Android app size: https://www.emergetools.com/deep-dives/candy-crush-saga
P.S. If you think Android is bad, just check out iOS ;)