
App sizes are out of control - trevor-e
https://trevore.com/blog/posts/app-sizes-are-out-of-control/
======
vladdanilov
The situation is messy. Take Facebook.app. The reported size on the App Store
is 377MB, the distributed .ipa is 241MB. But it is a universal app which
includes fat binaries arm_v7 and arm64 and all the graphics 1x, 2x and 3x. App
Thinning halves that size for end users. Yet the App Store reports the full
size.

There's more. App Store also provides some sort of delta updates [1], which
save a lot bandwidth, but failing to report it properly again [2].

App Thinning does not work for standalone image assets. It means you are
forced to use Asset Catalogs where all PNG files are stored as LZFSE
(previously zip) compressed BGRA bitmaps. It's good. But optimized PNG files
can be 30-50% smaller on average. I'm fighting this [3] but not sure if
there's a simple solution.

[1]
[https://developer.apple.com/library/content/qa/qa1779/_index...](https://developer.apple.com/library/content/qa/qa1779/_index.html)

[2]
[https://twitter.com/rjonesy/status/878051126704254976](https://twitter.com/rjonesy/status/878051126704254976)

[3]
[https://twitter.com/vmdanilov/status/892015508203216896](https://twitter.com/vmdanilov/status/892015508203216896)

~~~
mfabbri77
I was wondering why not use SVG (or any other vector file format) files and
render all the graphic on the device, instead of including tons of PNG at
various resolutions.

~~~
LocalH
Because the experience is subpar when that is done. It is impossible to create
a vector image that will result in clean, unblurred strokes at arbitrary small
pixel sizes. Don't even suggest using TrueType-style hinting, I don't think
any designer would want to touch that with a 10 foot pole.

~~~
verdy_p
I would have said exactly the opposite: blurred strokes belong to bitmaps, you
are still thinking that pixels are square over a regular area that can opnly
be rotated by multiples of 90 degrees.

SVG graphics are clean, result in NO blur at all. They don't even need any
Truetype-style hinting. You've probably looked only at early non-conforming
implementations using bad approximations. But precise rendering algorithms for
SVG are specified and fully tested (this is not the case for bitmaps whose
support is much more problementic: see what happens to photos and videos when
editing them! Never twice the same result, and lot of losses and artefacts
everywhere, including bad undesired effects, and notably the moiré effects
which are much worse and do not reproduce what natural scaling would do in
your eyes, that are not fitted to a perfect rectangular grid).

So no, it's perfectly possible to create a vector image that results in
unblurred strokes at arbitrary pixel sizes. What you want is a geometric
transform to exhibit more some details: it is in fact impossible to do that
with bitmaps except by sending variants tuned for multiple resolutions: you do
that for a limited number of resolution and assume it is enough, but this is
not the case, so you add more, and finally you have enormous images that are
widely redundant with each other, and better represented by converting their
2D model to 3D and an adaptive 3D-to2D projection. you'll do that easily with
vector graphics, not with bitmaps (or their extensions called "mipmaps" which
are only approximations not really scalable because they're still all based on
discretely sampled planes).

~~~
dungle6
> SVG graphics are clean, result in NO blur at all. They don't even need any
> Truetype-style hinting. You've probably looked only at early non-conforming
> implementations using bad approximations.

This huge wall of text but apparently you don't understand the subject matter
all that deeply. Why wouldn't SVG need hinting? Truetype needs hinting and
it's a vector format as well.

~~~
ygra
(Philippe always posts walls of text, even on the SVG mailing list; seems to
be their thing.)

Hinting as done in TrueType is probably overkill for most purposes. But icons
are often not displayed in _arbitrary_ sizes, but rather in one of a few
known-in-advance sizes. It's not hard to tweak the paths and shapes to fit to
the pixel grid for all those. Also, as you approach higher pixel densities, it
becomes much less important; basically you may just have to make sure that the
smallest sizes fit on whole pixels and that's it.

Long ago I've automated asset generation in different sizes from SVG for an
Android app I worked on and even without caring (much¹) about a pixel grid the
results were good enough not to need tweaking.

_______________

¹ When hand-writing SVGs I tend to care about integer coordinates simply to
not lose my mind.

------
jarjoura
Those numbers are mostly unfair. For some reason in the iOS 10 App Store,
Apple started listing the complete fat (both 32-bit and 64-bit archs)
submitted .ipa size. If you want to easily test that, clear your cellular data
usage, update one of those apps (or install) and then go back to settings and
see the actual bytes transferred.

Also, most everyone is using Swift in some small part, so that automatically
includes the standard library. Then you have some companies who switched to
Realm DB away from CoreData. Or then there's a whole subset of companies that
have decided they want to go all in on Javascript and have brought in the
whole React Native stack with it.

These apps in that list are also built by teams of 100s of engineers working
at full speed. In reality, each one is its own little OS full of its own UI
frameworks, testing frameworks, and nontrivial code.

Trust me when I say that everyone is plenty aware of how big their footprint
is getting, and no one is happy about it. Apple won't even let you submit to
the store if the actual single architecture binary is over 60MB.

~~~
mtl_usr
I'm as far to mobile development as I can be but is there no shared libraries
on those platforms ?

Other than the environment provided ones, isn't it possible to bundle some
dynamically loaded libraries that can be shared by multiple apps ? Makes
absolutely no sense for each application to implement it's own web
browser/runtime.

Can't believe we are constantly reinventing the wheel again.

~~~
babesh
For iOS, there are the shared libraries provided by the OS. UIKit, PhotoKit,
etc...

Shared libraries beyond that would bring the hell of version incompatibility.
One need only look at Apple’s evolution of Swift where there still isn’t
binary compatibility?

Most people don’t want to crack open their phone and set paths so that their
app has a version of Python that works with it.

Also shared libraries can be giant security holes. See the bug in AFNetworking
that affected many thousands of apps. Imagine an errant app shipping a
backdoor into a shared networking library.

~~~
pandalicious
It's pretty telling that Linux distros are pretty much the only end-user
platforms where binary distribution and packaging is built around shared
libraries. Pretty much everyone else (Windows/OS X/iOS/Android/etc) generally
expect binaries to include their own bundled versions of 3rd party libraries.
Lots of people have looked at this problem and most have opted against the
shared library approach.

~~~
marcosdumay
That's because Linux distros are more centralized that the Apple's walled
garden. They just lack the walls, but are as much a garden as you can get.

Unless those platforms start distributing a huge number of libraries your
software may decide do depend on, shared libraries won't take off on them.

------
habosa
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...](https://android-developers.googleblog.com/2017/03/getting-santa-
tracker-into-shape.html?m=1)

~~~
kijin
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.

~~~
toast0
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.

~~~
xg15
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.

~~~
toast0
To a first approximation, the standard library on deployed Android phones is
_never_ updated.

------
ghostly_s
There were a few articles with actual content on this topic covered on Daring
Fireball in recent months. Not sure what this blog blurb is adding to the
conversation.

1\. [https://sensortower.com/blog/ios-app-size-
growth](https://sensortower.com/blog/ios-app-size-growth)

2\. [http://blog.timac.org/?p=1707](http://blog.timac.org/?p=1707)

3\. [https://blog.halide.cam/one-weird-trick-to-lose-
size-c0a4013...](https://blog.halide.cam/one-weird-trick-to-lose-
size-c0a4013de331)

~~~
Xorlev
It's a blog, the content doesn't have to be novel. That said, the author would
improve the post by replicating your context links.

~~~
trevor-e
Yea, I wasn't trying to think too hard about the subject, I know there are
many excellent posts out there already (like those linked above) that go into
detail. I only wanted to show some actual download numbers to demonstrate how
absurd it has become. Linking those other articles is a great idea, thanks for
the feedback!

------
Apocryphon
It's pretty rich how these companies are well known for the rigor they apply
to interviewing candidates on technical subjects, yet actually drop the ball
in production with poor engineering like this. Where does that rigor go after
the interviews are done?

Are there any examples of well-known apps from large organizations that aren't
excessively large in size?

~~~
jamieomatthews
I work on Amazon Prime Photos iOS app. It's currently 60mb in size, and a good
chunk of that is the Swift runtime.

Even the main Amazon shopping app is less than 100mb.

~~~
hengheng
I'll bite. In what ways can you use up 100MByte with a fancy reimplementation
of an online shop _? That should be enough for a text to speech engine, or a
3d engine with quite a few assets.

_ I am being deliberately ignorant, having no idea what functionality one
might add, but I'm actually genuinely curious. All that I see is a small
databse and a lot of assets that are being downloaded on the fly.

~~~
acdha
I don't know the division of work between the app and server but don't forget
that the app includes some level of voice recognition, and has not just a bar-
code scanner but enough of a computer vision system that I can pretty reliably
look up products simply by taking a picture of them.

------
gok
Awesomely, this blog post of less than 200 words and one screenshot loads over
1.41 MB for me.

Software expands to fill all available resources.

~~~
trevor-e
Sorry for the extra bandwidth, forgot to optimize the images.

~~~
chubot
Well that's your answer to your question. You forgot to optimize the images,
because with your test environment, you don't notice it.

If you were testing over a dial-up connection, you would notice it.

Same with app writers. They forgot to optimize their app because they're
testing it on the latest and greatest phones on their home network (or a
corporate network which is blazing fast). If they tested on a low-end phone,
and actually performed the update themselves over a slow cell network, they'd
probably notice it.

Many common tools aren't set up for common-sense optimization. Ideally
resizing images would be an automatic step, and you wouldn't have to remember.
But that's not the case.

I'm sure that there are plenty of iPhone apps with 2 MB images from a camera,
when a 256 KB image would do.

~~~
CaptSpify
I used to work at a shop that ran a 1.5 mbps dsl line, and a ~5 year old,
cheap, slow computer. If their code worked on that, it would work on any of
our customer's machines.

I wish devs would still test like that. Sure, your app works fine in downtown
SF on the newest phone, but try using it in Nowherseville, TN, on a phone that
is more than a couple years old. I bet a lot of user frustration comes from
dealing with that.

~~~
deathanatos
> _Sure, your app works fine in downtown SF on the newest phone, but try using
> it in Nowherseville, TN_

Granting that you heavily imply a 4G connection, the choice of "Nowherseville,
TN" is extremely interesting: Chattanooga, TN — which as a Tennessean I feel
is essentially "Nowheresville" to most non-Tennesseans — has Internet service
multiple orders of magnitude better than most of the Bay Area[1]…

[1]: [https://www.washingtonpost.com/news/the-
switch/wp/2013/09/17...](https://www.washingtonpost.com/news/the-
switch/wp/2013/09/17/how-chattanooga-beat-google-fiber-by-half-a-decade/)

~~~
CaptSpify
I can agree that may be a bad example, but I think the point is fairly clear.

I do not, however, mean to imply a 4g connection. Many people don't even get
that.

------
jmduke
Worth pointing out: The author of this article works at Kayak, which has an
iOS app of 176MB.

[https://itunes.apple.com/us/app/kayak-flights-hotels-
cars/id...](https://itunes.apple.com/us/app/kayak-flights-hotels-
cars/id305204535?mt=8)

(As far as I can tell, the answer to "why is LinkedIn.app so large?" is not
"because LinkedIn's iOS team sucks", but "because LinkedIn's iOS team works
under a number of constraints, including app size, and app size is not a
particularly powerful constraint to optimize for.")

------
dallamaneni
I have been replacing traditional apps with PWA's or mobile websites wherever
possible (on Android). They hardly take up any space and also seem to behave
well (drains less battery) compared to traditional apps.

I could replace the following with PWAs:

\- Twitter

\- Uber

\- Lyft

\- Google news

\- Instagram

\- Flipboard

\- Shopping sites like Walmart, Wish

and many more.

Facebook and Amazon have no PWA's but have mobile websites. (Facebook mobile
web works well with Opera. On other browsers it annoyingly redirects to play
store to install messenger)

~~~
Twirrim
PWAs? Public Welfare Assistance schemes?

~~~
neogodless
Progressive Web Apps - basically HTML5 web sites that work well on a phone,
and take advantage of some newer browser features to make a web page more
"app-like." Not sure if there's a distinction to be made between PWA and
Single Page Applications (SPA), but in either case, you can use Service
Workers, local storage, offline mode etc as well as "app" features like
notifications and a homepage shortcut. The experience ends up being very much
like that of an app, without a huge install.

~~~
Apocryphon
So sounds like the promise of web-based "apps" from pre-app store iOS to WebOS
to Firefox OS... finally about to be realized thanks to official Google
backing. RIP to all the minor players who came before and failed.

------
custos
I have a cheap phone, and due to this I can only have like 6 apps installed at
a time.

I'm constantly removing Facebook/Messenger for situations like when I had to
download Ticketmaster app for a concert ticket.

And with all these apps disallowing you from moving them to SD card, I can't
even really use my 32GB SD card for them.

~~~
asah
protip: switch to browser-based FB. it's perfectly reasonable.

~~~
colanderman
And, you can still access messages by selecting "Request desktop version" from
the Chrome menu.

~~~
lbebber
Or [http://mbasic.facebook.com](http://mbasic.facebook.com)

~~~
mavhc
This is faster than the app for me. My main problems with the app are a) it
was pre installed so can't be moved to SD card, b) not only does the app
include a snapchat clone I don't use, but it stores 100s MBs of user data too,
c) it tells me I have messages, but that requires more 100s MBs to read in
another app with another 100 features I don't use.

------
ajross
Folks: there's a built-in technology on your phone that allows you to load and
run an app on-demand over the internet without dedicating any internal storage
at all! It allows clean integration with many of the "native" features you
expect like camera and notification and timers and stuff. And it's based on
completely open standards with multiple, competing open source
implementations.

No, seriously: uninstall that junk and just run stuff in the browser. It works
much better than you think, the biggest annoyance being all the nag screens
sites throw at you to get you to install their apps.

~~~
kalleboo
What is it that keeps online web apps from turning into the bloated monsters
that Electron apps are on the desktop?

~~~
Zarel
They don't need to bundle their own copy of Chromium and Node, presumably.

------
DamnInteresting
One of my first jobs was as a technician at a tech support call center. For a
while around 1997-1998, a good 1/3 of our calls were customers who ordered a
new system with a hard drive over 2.1GB, but Windows/DOS could only make
partitions as large as 2.1GB. Customers wondered why they got a smaller hard
disk than they ordered, not realizing the extra space was that Drive D under
My Computer.

Fast forward to today, where my MacBook keeps nagging me that my "hard disk"
(actually an SSD) is "full" because I only have 3GB of free space. In 20
years, what was once considered the maximum is now considered negligible.

Optimization is important, but regardless, software size is going to keep
growing. Wringing hands over it doesn't help much.

~~~
fireflash38
This misses a large point of the article:

It's not the _storage_ size that is problematic as much as the _transfer_
size. Websites and developers really need to be aware how long it will take
for someone to even get your product. If a website doesn't load in X seconds,
you're losing Y customers. If your app takes an hour to download, your
customer has probably already moved on in frustration.

~~~
cakedoggie
Yes, this guy doesn't seem to care at all about it, beyond writing a blog
post. If he did, he would remove those huge apps and find alternatives.

~~~
chii
Perhaps the lament is that because nobody else cares, you can't actually find
an app that is small to replace with!

~~~
cakedoggie
There are lots of apps smaller and better than some of these. Consider the
running app? Or using facebook in Safari.

------
pmoriarty
I remember when apps used to take less than 4k of memory, because 4k was all
the RAM in your computer.

Then I remember downloading a 3 MB mp3 on my 9600 baud modem and being amazed
at how much space was taken up by music that sounded realistic and not like
just a bunch of beeps out of speakers that could only make beeps.

Then came the old joke about EMACS standing for "Eight Megs and Constantly
Swapping".

Then I remember noticing that commercial software like games filled up a full
CD's worth of space (back when software was distributed by physical CD's).
After that it was common to ship software as multiple CD's, then multiple
DVDs.

Now, is software even shipped on DVDs anymore? I just download everything,
and, yeah, apps are still bloating, same as ever.

~~~
Krunkel
Right? I just got a new phone that has 128 Gb of internal storage. 334 Mb app?
no problem.

~~~
MBCook
When it only has the functionality of a 20Mb app... it's a problem.

When EVERY app does the same thing? It's a problem.

~~~
Krunkel
From that perspective, you have a very valid point.

~~~
MBCook
It's really crazy. Overcast (my favorite podcast app) is under 10 MB because
Marco cares about things like that.

Here's some of what's listed in the update list on my iPhone:

Chipotle is 92. The kindle app is 171 (perhaps the fonts?). The Amazon app
(which is mostly a web view anyway) is 127.

Robocall blocker? 22. Verizon app? 160. An app for tracking streaks of
achieving task? 65.

Slack is 123.

Clips? The Apple app for making little movies that includes a fair bit of art?
Only 55. That makes sense.

Authy? To show 2-factor codes? 65!

Outside of games (which have a lot of assets) app sizes seem to have
absolutely no correlation to what they actually do.

------
noahmbarr
Short a major customer outcry, Apple is largely incentivized to not fix this—

(1) They substantial profits from memory upsells on their product lines (2)
Larger apps take more horsepower to run— so older models become less effective
sooner!

~~~
cprecioso
But it also adds to _their_ bandwidth and storage bills

~~~
FRex
It's probably a drop in an ocean compared to their other services.

------
twsted
Most of the time it's the same reason why web pages are MBs in size today:
lazy developers that uses a new library for every feature they need, without a
deeper analysis of costs and benefits.

~~~
jaclaz
Not only, there is IMHO also a "technological supremacy" bias.

Quite obviously most developers will have:

1) VERY powerful hardware

2) VERY fast (and unlimited) internet connection

It's not like (they should do it as part of quality assurance or similar) they
take a car, drive in some remote countryside, possibly in the middle of
nowhere, stay there a couple days and try accessing their website (or running
their app) on the lowest/cheaper entry level hardware on a metered connection.

It's easy when you have a T1 or faster connection on a recent top-hardware to
forget how a lot of other people have slower devices, with less memory and
limited bandwith and metered connection.

~~~
thehardsphere
This absolutely.

I wouldn't be surprised if half of the outrage about file sizes simply comes
from the fact that there are people who remember what software was like before
all of this "technological supremacy" was a thing. People joining the
workforce today didn't grow up with the experience of installing something off
of seven floppy disks, which would have been considered an _emormous_ program
before the CD-ROM drive was common. They also don't know how much _better_
those programs run, because they had to do so with 8 MB of memory or less and
nowhere near 1 GB of hard drive space.

It's pure decadence.

~~~
jaclaz
OT but not much, and JFYI, I started using an alternate unit of measure for
web page sizes, the Doom:

[https://twitter.com/xbs/status/626781529054834688](https://twitter.com/xbs/status/626781529054834688)

[https://pbs.twimg.com/media/CLLGenwWgAAZAVv.png](https://pbs.twimg.com/media/CLLGenwWgAAZAVv.png)

Like: Hey, nice home page it is only 3 Dooms ...

~~~
katastic
I've watched entire episodes of anime in RM format in highschool that were
smaller than the majority of apps these days. Not just smaller, but like... a
4X smaller or more.

------
laurencei
The problem is it's not really in Apples interest to get app sizes smaller.

Larger apps means you have more "need" to upgrade your phone to the latest
version with more space, power, speed etc.

~~~
s73ver
Except they have been working on it, by repackaging apps to strip out unneeded
assets.

And it is in Apple's interest to have smaller apps, because then people will
be able to download more apps. They'll be willing to try more apps, because
there will be less of a barrier between seeing the download button and being
up and running.

~~~
MBCook
Plus Apple likes shipping lower end/cheaper devices to people who won't buy
the high end.

When your low end configuration is hard to use because Facebook takes up 29%
of the storage... that's a problem. Customers get mad.

When they can't update Facebook because it wants more space and the device is
full and now the user is locked out from their friends... customers get mad.

When updating a handful of apps uses up 70% of their monthly data... users get
mad.

And ALL of that effects apple's bottom line.

------
iamben
As someone with 16gb of space on my phone (before the OS), this has become
really noticeable. It's a breath of fresh air when you install an app (like
the habit tracker I installed the other day) and it's only 2mb...

It's worse knowing something like Facebook will cache a whole bunch of images,
friend pictures and everything else.

------
davexunit
Is anyone else worried about the massive amounts of bundled third-party
libraries that come with each app from a security, rather than a size,
perspective? What happens when such a library receives a security patch? AFAIK
it's up to each developer to keep all bundled libraries up-to-date, which
means that, realistically, everyone is shipping lots of vulnerable stuff and
they don't even know it.

"This shirt is dry clean only, which means it's dirty."

~~~
nrhk
Yes that's exactly what it means, React has 630 dependencies so 630ish
separate libraries and components. You might even stop updating a component
since the new versions change the interface and end up breaking sections of
your codebase.

The idea is that because it's all open sourced, all the vulnerabilities will
be found and patched. But more often than not you just end up missing the
small notification from the maintainers telling you to update.

------
peapicker
This is definitely getting to be a major problem. I've removed several apps
for this reason as well.

Code bloat = lost users

~~~
sly010
I think the way it works in the real world unfortunately is:

code bloat => "your phone is full" => "oh, my phone is too old" => new iphone
=> free space => code bloat

That said, I also delete bulky apps before I start deleting media.

~~~
digikata
Yup, and also bulky apps that insist on a two week rolling release schedule...

------
gregoriol
I tweeted some frustation about this a few days ago
([https://twitter.com/GregoryOriol/status/889859849353383937](https://twitter.com/GregoryOriol/status/889859849353383937)).

What is surprising me, is that in the Facebook iOS app, there is a
"FBSharedFramework.framework" that has a binary file of 215MB. What the fuck
is this? How a single binary can get that big?

~~~
LeoNatan25
Facebook is THE mother lode of terrible engineering. They have turned it into
an "art". You can see it across their end user offerings, as well as their
open source ones. What is perplexing is that they have some of the most
talented engineers out there. I'm guessing those people are using the
resources of the company to research and do what is interesting to them, while
clowns run the actual projects.

~~~
kalleboo
And here's a source to prove it:
[http://quellish.tumblr.com/post/126712999812/how-on-earth-
th...](http://quellish.tumblr.com/post/126712999812/how-on-earth-the-facebook-
ios-application-is-so)

> "In the case of the Facebook application, there are more than 18,000
> classses in the application"

18,000 classes. Absolutely ridiculous.

------
antfarm
LEGO's app for their new robotic toy is 1.03 GB.
[https://itunes.apple.com/de/app/lego-
boost/id1217385613](https://itunes.apple.com/de/app/lego-boost/id1217385613)

------
saosebastiao
The Phillips Sonicare Kids app, which is nothing more than a simple game for
kids to track brushing their teeth, is 245MB.

I guess the good thing is that it gave me an opportunity to teach my kid about
tradeoffs. "Ok, so if you really want this app, we're gonna have to delete 4
of your other games on the iPad." Even a 5 year old could reason his way out
of that one.

------
FraKtus
We released 2 apps on iOS and Android. One is 0.8 MB and the second just at
1.8 MB. Obviously we have not a lot of graphics embedded. We use mostly C and
2 cross platform projects SFML and Nuklear for the GUI. The GUI is more in the
gaming style but for us it fits the bill and we render at 60 FPS on most
devices including the iPad mini original of my daughter.

------
cakedoggie
People don't care about app sizes, otherwise it would be an issue.

Look at this poster, he doesn't care. He isn't going to remove any of those
apps. There are runner apps that are a lot smaller, but he doesn't care about
the size of the app enough to guide what he downloads.

Empty blog posts are empty.

"Why is there so much traffic, someone should do something, I hate driving
these days."

~~~
mikulas_florek
How do you know people do not care? There are billions of people with phones
without enough space and slow or almost nonexistent internet access. They are
just not vocal about it.

------
pascalxus
the solution is, everyone should uninstall these apps. if everyone did that, i
bet you they would fix the problem reallly fast.

This is why i uninstalled pokemon go -> it used up to much data and to much
battery. Uninstall -> problem solved. unfortunetly, the vast majority of
people don't care about app sizes, or how much data they use, etc.

------
coldcode
Our app downloaded is just under 100MB. Biggest part? Google Maps For Business
at 30MB. Why do we use this monstrosity? We signed some marketing deal with
Google. We have a replacement using Apple Maps thats about 2MB. But the
beancounters won't let us use it because of the $. Not every size problem is
some programmers fault.

------
cybrjoe
I was comparison shopping something this week and wanted to check Best Buy, so
I went to the app store. 100+ MB and needed to be on wifi to download. What in
the Best Buy app could be over 100 MB?

On another note, I just went to check some of my apps and iOS 11 got rid of
the size from that view. You now need to dive into each app to see the size.

~~~
jhoechtl
Why didnt you go staight to their web site? Its well usable on a mobile
browser.

------
crazygringo
It's not just the install size, but apps which accumulate and seemingly never
delete data.

For a while I tried to get by with a 16GB iPhone SE thinking I keep everything
in the cloud, so why would I ever need 64GB? Well every couple of months I'd
have to delete and re-install NYTimes and reddit and some magazine apps
because they just grew and grew and grew in storage until I had 0 space left.
Like they simply cache everything you've ever looked at.

It's dumb, because other apps are intelligent -- they'll automatically purge
cache data when storage gets too low. But not NYTimes. Not reddit. It seems
pretty inexcusable, really.

------
real-hacker
Another question has to be asked: do they have the motivation to reduce the
size of apps?

Earlier this year, Wechat released a revolutionary (kinda) feature called
'Miniapp', it supports releasing apps within Wechat itself (a bunch of xml/js
files). All major Internet companies published their own miniapp in Wechat,
which include s the most-used feature of their full app, and only takes less
than 1MB of space. Guess what? the miniapps are not adopted by most users, it
became just a fad.

This means most users are not sensitive to the disk space used by an app. Apps
know this, and thus don't have motivation to reduce the size.

~~~
yorwba
I'm not sure how your anecdote is supposed to show that users don't care about
disk space used by an app, as opposed to not liking one particular attempt to
reduce it. WeChat also includes a feature to manage storage space on a per-
chat basis, and I have used it before when I ran out of space.

Thing is, some Android users (like me) are at the limit of their internal
storage and some apps can't be moved to an external SD card for some reason.
Before installing a new app (or indeed just an update), I have to decide which
of the hellishly bloated apps on my phone I can delete to free up space.

------
real-hacker
A major culprit of the bloat is the monolithic 3rd-party libraries/frameworks.
You have to import the whole thing, even if what you need is just one simple
function. Of course, you have the option of carefully studying the code, and
hand-pick the part of code you need, but most developers will not do this, due
to poor ROI.

One way to solve this problem, is to promote modular library structures, and
package management tools (pod, npm) should support importing fine-grained
submodules, even single features of a library/framework, whenever possible.

~~~
katastic
Everyone keeps saying this, and it's probably true. What I don't get is... why
the hell these libraries everyone is using don't support MODULAR compilation.
Why are they including stuff people aren't using?

I'm not an app developer. But I've known about libraries that section off
lesser used code as "addons" since... well... since I started programming.
This seems so fundamental I don't understand why everyone isn't doing it.
Especially considering the gains are far greater in the mobile and web world
than desktop.

------
TeeWEE
Normal apps are around 10 to 20mb, which is still big. But the reason for this
is support for different screen resolutions. Images of different sizes are
bundled with the app, even though the phone only needs on of them.

Vector graphics will solve this, but is not mainstream yet.

The facebook android app is 88MB (zipped), i did check the APK of why its so
big:

90mb of code 30mb of assetes (javascript, metadata, librtc, big json files
(animations)) 30mb of resources (images)

~~~
whowouldathunk
> Vector graphics will solve this, but is not mainstream yet.

Then you're trading off battery life vs. space. Vector graphics can be far
more expensive to render than bitmaps.

~~~
lcnmrn
Why vectors can't be pre-rendered and cached?

~~~
whowouldathunk
That's what a bitmap asset is.

~~~
marcosdumay
Except that a cache is disposable, and disposed often in practice.

------
Rjevski
Analytics and ads/tracking is one of the reasons. They're always
writing/including more code to track every single click and pixel.

------
userbinator
No discussion of bloat is complete with a mention of the demoscene, where sub-
MB applications generate immensely complex graphics:

[https://news.ycombinator.com/item?id=11848097](https://news.ycombinator.com/item?id=11848097)

[https://news.ycombinator.com/item?id=3843427](https://news.ycombinator.com/item?id=3843427)

[https://en.wikipedia.org/wiki/.kkrieger](https://en.wikipedia.org/wiki/.kkrieger)

(I'm aware that these sizes do not include the OS and its libraries, but apps
on a mobile device also have a similarly rich environment of libraries they
can use.)

------
msoad
One word: Swift

It's making app bundle sizes explode in size

~~~
mikeash
The lack of a stable ABI means that the Swift runtime libraries have to be
bundled into the apps, which accounts for around 10MB of bloat. Unfortunately,
10MB is almost unnoticeable on the scale of bloated apps these days. Does
Swift do anything else to make apps bigger?

------
akulbe
I have a limited understanding of how this works, but could it be that app
devs are leaving debug stuff in the builds, and not removing that when it gets
pushed to production?

Please, educate me. I'm all ears. :)

~~~
tjl
Often, it's really bad design. For instance, Facebook's app has 18k classes.
In other cases, it's a lot of big 3rd party libraries.

------
jorgemf
With text-only webs over 5MB I wouldn't expect less from mobile apps.

------
rootlocus
Six apps, six embedded web browsers.

~~~
anonacct37
Does that add up to much in terms of app size? I was under the impression most
embedded web browsers used platform web view components?

~~~
potatolicious
You're right - there should be minimal (if any) size bloat because of the use
of browsers on iOS.

You're not allowed to include your own browser, and can only use the
platform's web view, which is not duplicated on a per-app basis.

There are many culprits for app bloat, but using a browser is most certainly
not one of them.

~~~
rootlocus
I'm sincerely curious what would be the worst offenders for app bloat.

~~~
potatolicious
It varies, but for most apps I'd wager it's library bloat, but in my
experience doing iOS dev here are the common culprits:

\- For games assets are a big issue. Some do not compress their assets, and
unfortunately most image-authoring tools make it easy to output PNGs that are
_much_ larger than they can be. I think a lot of people by default assume
bloat comes from images/icons/etc, but IMO this is a red herring for most non-
game apps.

\- Library bloat. Even simple apps pull in a large number of external
dependencies, which contribute dramatically to app bloat. There's also a lot
of code pulled in that replicate platform-provided functionality (see: the
bajillions of layout libraries out there), which may be simpler to use than
the stock Apple components, but add to your bundle size.

One of the common problems is that iOS open source dependencies are typically
all-or-nothing - you end up pulling in a very large library even if you're
only using a small slice of its functionality.

I think most disassemblies of iOS app bundles show that library bloat is
typically a _far_ larger problem than asset bloat.

In any case, I think the future will be something like Android Instant Apps -
where apps are sliced up such that necessary bits can be downloaded on-demand.
This gets users into apps faster, and saves space.

~~~
AstralStorm
Congratulations, now you cannot use any app on an intermittent or slow network
connection.

This "cure" is worse than the disease.

~~~
potatolicious
How so? The scenario being modeled here is a user who wants to use an app but
does not already have it.

The status quo is that they must download a 150MB bundle before being able to
proceed.

The proposed app slicing will allow them to download maybe 10-20MB before
being able to proceed, with additional components (up to the 150MB total)
downloaded on-demand.

If the user is on an intermittent or slow connection this is still a
significant improvement over the status quo: the user gets into the app much
more quickly.

Additionally, if the user only uses a small slice of the app's functionality
(which is the 90% use case), additional downloading can be deferred until the
user connects to wifi, at which point the rest of the app can be downloaded
over a fast and reliable connection, all seamlessly without the user having to
worry about it.

------
bathtub
There was a time when people used more and more websites because they were fed
up with desktop apps. Hopefully we see the same soon again.

------
fledder
275MB for LinkedIn is the complaint, to one-up that...I recently got an update
for Hearthstone on iOS of 2.3GB. It adds one pack of cards.

------
post_break
Pretty soon these will start to hit Apple's limit on downloads over cellular
(something I still can't believe exists in 2017).

~~~
istajeer
You're typing from a first world country where there are not huge cellular
costs or speed limitations. If you go to other countries, even say, Botswana,
the option to download over a gig in apps every (other) week isn't cheap.
Bandwidth costs.

~~~
mtl_usr
Don't worry, you can get to third world carrier really quickly by taking a
Greyhound bus to Canada.

------
jimbobjim
The reason the LinkedIn app is so big is the number of frameworks they use. 87
frameworks accounting for 248MB of the 277. The swift runtime takes up about
20MB, and something called VoyagerFeed takes up over 190. All the images
actually only make up about 12MB. There's also about 0.5MB for each
localisation.

~~~
iamatworknow
>something called VoyagerFeed takes up over 190

"LinkedIn’s new flagship app, nicknamed “Voyager,” is a complete architectural
and design overhaul available for iOS and Android, as well as an online mobile
experience, in the coming weeks."
[https://thenextweb.com/apps/2015/10/14/linkedin-
voyager/](https://thenextweb.com/apps/2015/10/14/linkedin-voyager/)

Sounds like "VoyagerFeed" may be part of their own codebase.

------
kmfrk
I hope someone might take it upon themselves to make a Wall of Shame to let me
know which apps I should just uninstall if I rarely use them.

Although the updates aren't always huge, Slack has been an atrocious app on
Windows and iOS for performance and indexing. Absurd that the biggest
companies have, well, the biggest apps.

------
miguelrochefort
Things will only get worse. The application paradigm is unsustainable.

[https://medium.com/@miguelrochefort/the-application-
paradigm...](https://medium.com/@miguelrochefort/the-application-paradigm-is-
unsustainable-4071f392d2af)

~~~
gue5t
You're entirely right, but "it is difficult to get a man to understand
something, when his salary depends on his not understanding it" certainly
applies to the entire "tech" industry, and the app factory in particular.

I expect this realization will only become widespread when open-source folks
actually fix their software's deep-seated usability problems. The way to do
that is _not_ by hiring UX designers or appifying it; it's by thinking deeply
about how humans interact with computers and blowing away the conventions that
make computers and software unforgiving, hard to explore, and opaque to the
uninitiated.

~~~
kec
...So by hiring / lucking into someone whose job it is to look at UX. Like a
designer.

------
draegtun
When i see articles like this it always reminds me of Carl Sassenrath's _Fight
Software Complexity Pollution_ \-
[http://www.rebol.com/article/0497.html](http://www.rebol.com/article/0497.html)

------
foepys
Once upon a time I deleted music and videos from my phone to make room for
newer music and videos but nowadays I catch myself removing apps. Not because
of the space they are using but because of the app size itself. A once removed
app is unlikely to be reinstalled.

------
cipriancaba
Not sure that Apple has any interest into reporting smaller sizes.. They have
interested in having lower download sizes (less strain on their servers) and
users buying the bigger and better memory storage.. Along with the iCloud
subscription of course..

~~~
tjl
They're working at making smaller apps on people's iPhones. They strip out all
the graphics that don't apply to the given phone that's downloading on, plus
bitcode is compiled for the specific architecture, so you don't have multiple
architectures installed that you don't need.

------
Zigurd
Pile on the frameworks to speed development and to make mobile development
more familiar-feeling for non-mobile coders. Instrument every user
interaction. Use a cross-platform SDK. Squeeze every penny out of every ad
network. Whoops! Bloated.

------
hamandcheese
People here seem to be blaming over eager use of third party libraries for a
lot of bloat. Is there no such thing as dead code elimination for apps that
would eliminate the unused portions of your dependencies?

------
r0ze-at-hn
The only real solution I can think of would be if apple actually incentivized
app creators to reduce their size. They are actively harming the Apple
ecosystem by preventing users from having a large number of apps which hurts
Apple.

* Charge owners a fee for apps over a certain size "a processing fee" or whatnot

* Charge owners a fee based on the download costs. Under XMB and it is free. The more you cost apple to transfer your app to their customer the larger the fee.

* Penalize large apps in the app store search results or give bonus to smaller apps.

Or rather than straight up bonus's / penalize apps based on size go after
specific things that cause bloat

* Apps that don't use pngcrush on their png's

* Shipping wav files and not acc

* ...

Maybe Apple doesn't even need to actually implement any of these, but just
threaten to.

------
apl002
There are more native capabilities now on devices which require more SDKs to
leverage this functionality for cool stuff. The size of some of these SDKs are
huge and bloat the size of your app.

------
slaymaker1907
And supposedly we don't need PWAs according to Apple...

~~~
nrhk
Jobs wanted PWAs before they were around. The devs for the first version of
the iPhone were told to write web apps until we realized the dev environment
just wasn't up to snuff.

We're finally getting back to that original vision.

------
mahyarm
Swift induces large binary sizes through the language itself. You'd be
surprised what a simple optional if let creates in assembly, or how it uses
template specialization with pretty much every typed collection interaction or
some other standard library interaction. That plus the 10-20+MB that the swift
standard lib adds contributes a good chunk. Once ABI stability comes in and a
bunch of in progress size optimizations come in, binary sizes will decrease
quite a bit for swift using apps.

Apple also encrypts then compresses, which means the binaries you download in
the app store are incompressible.

If apple wants to decrease IPA download size worldwide, they would let
developers not encrypt their app and just sign them. That would be very
relevant for developers of popular free apps. I'm guessing they encrypt then
compress so they wont have to re-encrypt the binaries on the users phones once
they uncompress an app.

Also all the SV big-co have A/B testing practices with weekly release cycles
that induces large line counts in their apps.

I think everyone copied the facebook mobile dev style, which simulates what
you can do in webdev. In webdev there is no cost to adding another team for
another feature that lives in some section of the greater app, since it's just
another webpage. You can create many a/b tests and rollback things nearly
instantly. With the weekly cycle everything is under a feature flag and you'll
see a bunch of half developed features sitting in the delivered binary turned
off via feature flag. This induces code size and creates these kinds of issues
you see today.

Also large apps start requiring management structures that I call hallways and
elevators. A single indie app can make a equivalent of a 1 room hut of an app,
which doesn't require any hallways, elevators, floors, boiler rooms, parking
structures or stairs. If you look at the layout plan of a highrise, you'll
start to realize a lot of the floor space is taken up by the elevator and
hallways.

Once apps become as large as a highrise, then they start requiring code
structures that help manage the chaos, such as reporting systems, rollback
systems, well defined tree structures and so on. That and the shear amount of
rooms they have create apps larger than they look.

------
tehlike
I'm pretty surprised nobody mentioned proguard. Almost noone enables that,
unless they have to, and that's part of the problem.

------
svenfaw
What blogging engine is this? Real nice and clean.

~~~
jspash
There is a reference to django.css in the source, assuming you meant the
style. As the blogging engine wouldn't necessarily dictate the cleanliness of
the look.

------
Raynak
My phone currently only manages 2 non-default apps. If it could actually
install to SD like it promises I'd be happy.

------
randyrand
It would be cool if users could specify a max size for an app, and then the
app tries to meet that size or be deleted.

------
titanas
Many apps are loaded with lots of A/B test, increasing the binary size ..
because A/B testing

------
wingworks
Interestingly LinkedIn reports on the Play Store as only 20MB. Though once
installed it uses 111MB.

------
ourcat
Just wait until they start adding 100Mb+ (Core)ML data models after iOS 11
(with A9+ chips).

------
samdung
Im just guessing this is to corner of a good amount of disk space so the app
does not stop working from lack of space.

An analogy is when downloading a torrent; the torrent blocks a chunk of space
on your disk equivalent to the size of the file being downloaded. As the file
is being downloaded it replaces junk in the blocked chunk.

Again all this is my speculation.

------
aussieguy123
Why isn't rsync used to update apps, instead of passing archives around?

------
isseu
Why swift runtime is not included as part of ios ecosystem?

------
romulof
Didn't Apple implement delta updates for apps?

------
stormcode
Advertising APIs.

------
kutkloon7
I never understand where this increasing size comes from. For videos or hi-res
photographs, I understand.

There is however no reason that code, either compiled to a binary format or in
a textual format, uses so much data. Heck, the memoirs of Casanova spans 3000
pages, and is 6,5 MB. People don't understand how incredibly large a megabyte
is for simple code.

Surely the 275 MB isn't all useful data (I wonder what compression ratios you
get on 'apps'), and it should be possible to cut it down to a few MB.

~~~
rlv-dan
Could it be that whenever coders today need some fairly trivial functionality,
they tend to go out and find a library that contains it. So you end up with
lots and lots of libraries where only a tiny bits of them are used. Just a
hypothesis though.

~~~
potatolicious
I think this is likely the biggest culprit. Another user pointed out an
analysis of the Facebook app:

[http://blog.timac.org/?p=1707](http://blog.timac.org/?p=1707)

Most of it is actual code - not assets. For some types of apps (see: games)
assets _do_ take up a significant portion of total size, but for most everyday
apps bloat by code over-inclusion is likely a bigger problem than asset-bloat.

I wonder if it's possible to get major open-source libs to move towards more
fine-grained build targets and internal dependency management, so that devs
don't pull in a gigantic binary when they're only using a small slice of the
functionality.

~~~
Swizec
> I wonder if it's possible to get major open-source libs to move towards more
> fine-grained build targets and internal dependency management, so that devs
> don't pull in a gigantic binary when they're only using a small slice of the
> functionality.

Fwiw, this is already a trend in JavaScript land. Libraries are moving towards
many small packages so you can import only the parts you need either manually
or using a tool like Webpack to throw away what isn't used.

~~~
cyphar
I don't think that's the right solution to the problem. Nobody wants
libleftpad.so, and as someone who works on a distribution the very concept is
horrific (making distribution packages for every three-line package does not
make anyone happy).

What I think GP was arguing for is that you have libstring.so which you can
strip down to just having leftpad or w/e with Kconfig or similar
configurations (preferably at link time not build time -- otherwise you still
have the same problem).

~~~
jamescostian
JavaScript people do not create libleftpad.so, they create libleftpad.o
(metaphorically speaking), which will not clutter up your distribution, it
will just clutter up some apps. I'd rather see 50 little files like
libleftpad.o than 5 gigantic libraries.

But I agree with what you're saying in the second paragraph, which actually
sounds just like what my GP meant by using "Webpack to throw away what isn't
used". Having unused parts of larger libraries cut out would be a much cooler
solution than just telling everyone to eschew kitchen sinks in favor of many
tiny, bespoke items. Especially since finding the right small libraries is
much harder than finding a kitchen sink that just works and has a sizable
community behind it

~~~
marcosdumay
> I'd rather see 50 little files like libleftpad.o than 5 gigantic libraries.

And then you'll have to use software written in 50 different styles, with 50
different type and error conventions, with pieces that couple together or not
at random.

~~~
politician
> And then you'll have to use software written in 50 different styles, with 50
> different type and error conventions, with pieces that couple together or
> not at random.

All of which matters not one hoot to folks _using_ the software.

------
ringaroundthetx
In several interviews I've been questioned about the importance of my
contributions throughout my entire career because the apps sizes were so small
(typically 8 - 12 mb)

When asked it was clear they'd already made up their mind, and discussions
about optimizations, how the app actually did anything, MVC, MVP or SVGs
didn't change that.

And thats how you have large apps!

~~~
flukus
To paraphrase Bill Gates, that's like measuring an aircraft designers skill
based on the final weight of the aircraft.

Any idiot can create something bloated and complex, creating something small
and simple requires much more effort.

~~~
rimliu
But when you think about it, final weight of the aircraft does say something?
I guess an amateur could design something like Cesna and have it flying, but
designing An-225 is a different matter.

~~~
flukus
This is more like people building a Vesna but having it turn out the weight of
a 747.

------
necessity
Don't download them? Out of those apps the only one you actually need is Uber,
everything else can be replaced with a web browser. I don't download anything
larger than 5MB unless I absolutely need it.

------
adamnemecek
I wonder is this is due to lack of generics in objc.

~~~
swolchok
Objective-C has had generics for years. Here's mention of how they are
imported into Swift:
[https://developer.apple.com/library/content/documentation/Sw...](https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithObjective-
CAPIs.html#//apple_ref/doc/uid/TP40014216-CH4-ID173)

~~~
adamnemecek
I'm aware, they are nowhere near comparable.

------
dineshswamy
I m building a product that would bring the size of the apps way down

