Comment by habosa | Hacker News Reader

Comment by habosa | Hacker News Reader

I am surprised at all of the app developer shaming in this thread. Is it really likely that every developer working on a popular BigCorp app is an idiot who imports 10MB libraries every time he/she faces the slightest challenge?

It's much more likely that app developers are optimizing for many things, including app size, but reducing app size has a bad cost/benefit ratio. Here are some decisions that may bloat your app:

  * Want your network calls to be fast and reliable?  Better use that cool new HTTP library rather than writing your own. 

  * Want to keep everything secure?  Rule #1 of hacker news is never roll your own crypto so better import the best lib out there.

  * Want to delight your users and their fancy QHD screens?  Time to include some high res images and animations.  Oh and you can't use vectors, they kill performance. 

  * Want to access new markets?  Time to translate your strings into 80 common languages.  Oh and some of these may require custom fonts to look right in your app. 

  * Want your Android game to have blazing fast graphics?  Import that native library, and don't forget multiple architectures.

The biggest app I ever worked on was Google Santa Tracker. It was about 60MB. We spent a lot of time optimizing the app size in this year's version. We managed to drop 10MB while adding a few new games to the app. I'm proud of it, but if I didn't have the freedom to pursue app size I certainly would have taken the extra bloat to ship the new content.

https://android-developers.googleblog.com/2017/03/getting-sa...

Is it really likely that every developer working on a popular BigCorp app....

Not to mention, rarely does app size register to clients, PMs, bizdev in terms of a worthy task. Only when you end up at the top of the app sizes list is time given to optimize.

We work to keep down app sizes and offer line item tasks for app size optimization on updates, noone finds it needed until they start to risk being near the top of the app list on a users device when they want to delete some apps.

In games, many toolkits/engines like Unity and Unreal in mobile also add quite a large chunk. Building your own engine is rarely an option anymore in terms of competitive launch. Many games built with Unity/Unreal even with moderate assets can reach 200-300MB easily and easily creep up further on updates.

For some reason reducing APK size talks have been a constant presence in the last three Google IO and WWDC as well.

If you need to advocate this, it tells a lot about how much app devs care about the issue.

Every popular mobile OS has standard libraries for making HTTP requests and doing crypto.

I can forgive games for sacrificing size in favor of high-res animations and a blazing fast graphics stack, but I don't think LinkedIn, for example, is in need of particularly fast graphics.

If you've had to look at a pcap from what the android standard libraries do for https chunked upload, you would cry. One tls packet for the per chunk header, one for the chunk of data, and one for the carriage return newline. I've thankfully forgotten if these managed to also be separate tcp packets.

Given that, I don't think it's unreasonable to consider using a library to do it better, although you have to weigh the increase in apk size. The standard crypto libraries on the phone are great if the features you need were released 5 years ago, but if you want consistent behavior across Android versions and manufacturers, you need to include that yourself too.

Except the standard library will be updated if this actually became a problem, whereas you might choose that the cost/benefet ratio to updating your library is not worth it.

To a first approximation, the standard library on deployed Android phones is never updated.

Yet the installed size of my facebook app on android is 350MB and since the total phone memory is 2 GB I have a storage problem (less than ideal free space). While facebook lite is not a smooth experience compared to the full app.

"Installed size" as reported by iOS can be deceptive, since it includes a cache.

Unlike Android, end users can't clear it, though backing up and restoring your phone does that...

Mobile platforms should really do something about vector graphics. Shipping raster image which has much larger size than vector image is stupid. Shipping 3-5 raster images is beyound stupid. Surely there could be a way to render images on demand or roll some simple vector format which would be fast to render (it's not like decompressing PNG is that easy, it takes processor time as well).

Android offers VectorDrawable for this purpose, and Android Studio will automatically convert SVGs for you. It works great for icons and other "material" stuff, anything where flat colors and simple paths are sufficient. I believe there is also a support library to use it on older OS versions but have no experience with that since we're happy with 5.0+ for our app. I highly recommend it over making all those PNGs for different screen densities.

I have seen projects that did not cared about app size. Or rather, app size was priority "super low", because critical and important issues were still open.

It seems that most users don't really care nor use all that many apps.

Reply on news.ycombinator.com