HN Gopher Feed (2017-08-01) - page 1 of 10 ___________________________________________________________________
App sizes are out of control
398 points by trevor-e
https://trevore.com/blog/posts/app-sizes-are-out-of-control/ngopher.com___________________________________________________________________
iamben - 6 hours ago
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.
Apocryphon - 6 hours ago
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 - 5 hours ago
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 - 5 hours ago
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 - 2 hours ago
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.
Nightshaxx - 5 hours ago
I believe it does have a text to speech engine......the
Android app has one.
swrobel - 2 hours ago
Those apps are standouts but generally Amazon iOS apps are
appalling. Alexa is 78MB of pure UX hell.
abc_lisper - 2 hours ago
Wait. Do you have to include the runtime with the app? That
seems backwards.
Azkar - 5 hours ago
It's hard to move fast and have a well engineered product.
s73ver - 1 hours ago
90% of the time, the organizations that say stuff like this
just don't have any discipline. You can move plenty fast with a
well engineered product.
LeoNatan25 - 4 hours ago
Then don't move fast. It's as simple as that. Move at the pace
that you can sustain a reasonably engineered app.
richardwhiuk - 4 hours ago
At which point everyone who moves fast will beat you.
marcosdumay - 2 hours ago
Will them?Amazon differential is not the quality of their
app. Unless they create something really impressive some
day, they can only lose customers by moving faster
there.Besides, none of those are small startups anymore.
All of them have something to lose.
maccard - 5 hours ago
Not exactly large organisation, but the slack app is 80MB. For
reference, discord is 17.
mschuster91 - 5 hours ago
> Are there any examples of well-known apps from large
organizations that aren't excessively large in size?This is
nothing new. Look how much memory your typical Java desktop app,
or worse, your average Java server app, uses. As soon as you have
enterprises involved where it's regular occurrence for devs to be
outfitted with the shiniest and beefiest (as perks or per
standard company policy) developers won't care about resource
usage until it's so excessive it either slows down their machines
or accounting knocks on the door and asks who ordered dozens of
x1.32xlarge machines...Seriously, another huge problem is assets.
In ye olde PC days, you included ONE version of an image and that
was it (okay maybe a 16x16 favicon for the small start menu and a
32x32 one for desktop)... these days with loads of different
combinations of resolution and DPI, and across multiple platforms
(if you're doing a Cordova build and don't split the assets
before packaging), stuff can and will grow.
Chyzwar - 1 hours ago
I do not think you worked in Enterprise. Getting new tech
approved is difficult, provisioning a VM takes weeks. Most
enterprise lag at least 2 years behind everyone else.Enterprise
apps are slow because developers lack shiny new tech. You are
forced to build yet another Spring App that takes minutes to
start and gigabytes of memory. You also need to use MQ to
interface with other systems and log/audit almost everything.
richardwhiuk - 4 hours ago
It's not that Devs don't care. It's because every metric anyone
has ever gathered says that users don't care.
jcelerier - 4 hours ago
> It's because every metric anyone has ever gathered says
that users don't care.A lot of people go to wal-mart. Doesn't
mean that it's a good thing overall for mankind
emodendroket - 2 hours ago
If you're looking for apps to be developed "for the good of
mankind," without consideration of profitability, then
you're going to have to have a different model than the
pursuit of profit.
vkou - 5 hours ago
Because the customers are the ones who are paying for that
inefficiency, not the company.You can bet that those companies'
infrastructure is optimized to hell and back.
marcosdumay - 2 hours ago
You know, I'm not currently an Uber customer because their app
is too big and I don't have enough spare space on my
phone.There were a few times already that I thought about using
them, but couldn't install it right at the time.
s73ver - 1 hours ago
I have to imagine the vast majority either don't care, or
have other reasons for not having the app on there (like the
company itself, for one).
emodendroket - 2 hours ago
OK, so that's one. How many people even look? I have no
idea what size the applications on my phone are.
marcosdumay - 1 hours ago
I never really looked (not into Uber). I just tried
installing it, and it failed due to lack of space... And,
well, I can take a cab when I need it.
Apocryphon - 2 hours ago
Do you have a lot of space on your phone, or just not use a
lot of apps or media? People might not have the same
situation as you.
Aqua_Geek - 3 hours ago
> You can bet that those companies' infrastructure is optimized
to hell and back.You'd be surprised. (Source: I work at a
unicorn.)
[deleted]
pmoriarty - 7 hours ago
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 - 2 hours ago
Right? I just got a new phone that has 128 Gb of internal
storage. 334 Mb app? no problem.
MBCook - 1 hours ago
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 - 1 hours ago
From that perspective, you have a very valid point.
MBCook - 1 hours ago
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.
romulof - 6 hours ago
Didn't Apple implement delta updates for apps?
dallamaneni - 6 hours ago
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, Wishand 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)
speg - 6 hours ago
I've been doing this too; but annoyingly I usually am in Private
Browsing mode and when I go to launch one of these apps it
doesn't work because I'm no longer logged in.
Twirrim - 6 hours ago
PWAs? Public Welfare Assistance schemes?
hutattedonmyarm - 6 hours ago
Progressive Web Apps
groby_b - 6 hours ago
Pretty^W Progressive Web Apps
(https://developers.google.com/web/progressive-web-
apps/)Essentially, apps on the web that feel and behave like a
native app.
neogodless - 5 hours ago
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 - 5 hours ago
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.
djKianoosh - 5 hours ago
... without a huge install if you watch the weight of the
initial page load and optimize for that. ;)
[deleted]
spcelzrd - 6 hours ago
Progressive Web ApplicationsIt's the new name for a home screen
bookmark.
jessaustin - 6 hours ago
https://developers.google.com/web/progressive-web-apps/
rayiner - 5 hours ago
But those websites suck down enormous amounts of data each time
they load.
allannienhuis - 5 hours ago
Not if they use caching (whether service worker based or not)
aggressively.
s73ver - 1 hours ago
If an organization isn't taking the time and effort to make
sure their app isn't bloated full of stuff, what makes you
think they'll do that?
[deleted]
Theodores - 5 hours ago
Well here is an application that defies your approach: the
Android clock. 17Mb update to that just now, vanilla android.
Plus Google do some diff. style updates so that is probably a lot
more and for a clock. Presumably it has 17Mb of updated alarms in
surround sound and presumably these are needed however I can't
see any other obvious bloat potential as the clock should use
Android UX.How can a clock need the equivalent of a box of
floppies? Windows 3 and 3.1 together comes to the same Mb and
that comes with a clock.
013a - 6 hours ago
I think that's a fine solution, but its looking at the wrong
problem.Consider an app like Discord [1], which is built using
React Native and is thus a "native" app with some additional
cruft like a JS runtime. It clocks in at a relatively small 30mb.
Not bad.Then consider Slack [2]. For nearly intents and purposes
it does the same exact thing. Discord has far more functionality
than Slack. Yet, it is 129mb.Tweetbot [3]? 12mb. Twitter [4]?
204mb.The issue has little to do with the technologies used. PWA,
React Native, full native, it doesn't matter. The issue is truly
that these large companies have horrible, bloated engineering
teams and that bloat comes through in the size of the apps
produced. It is Conway's Law in action.[1]
https://itunes.apple.com/us/app/discord-chat-for-
gamers/id98...[2] https://itunes.apple.com/us/app/slack-business-
communication...[3] https://itunes.apple.com/us/app/tweetbot-4
-for-twitter/id101...[4]
https://itunes.apple.com/us/app/twitter/id333903271?mt=8
Kiro - 5 hours ago
What exactly is the difference between a PWA and a mobile
website?
ocdtrekkie - 5 hours ago
Branding, obviously. :)
fledder - 3 hours ago
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 - 7 hours ago
Pretty soon these will start to hit Apple's limit on downloads over
cellular (something I still can't believe exists in 2017).
istajeer - 7 hours ago
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 - 5 hours ago
Don't worry, you can get to third world carrier really quickly
by taking a Greyhound bus to Canada.
SketchySeaBeast - 7 hours ago
As a Canadian, to get 2.5 GB of data from a larger cell phone
company costs me over $100 / month (there are smaller companies
that will reduce that, but still, it's little data for quite a
bit of money). I'm very happy I can force things to download
only over WiFi.
tushar-r - 7 hours ago
>(something I still can't believe exists in 2017Something that
I'm very happy about in 2017 :-) Data is expensive in many
places, and wifi/broadband is typically cheaper.
post_break - 4 hours ago
"It works for me so you shouldn't need the option" mentality at
heart. I have unlimited data so why should I be under a
ridiculous limit?
mikeash - 6 hours ago
It should definitely exist, but Apple's one-size-fits-all
approach is pretty dumb. It ought to be configurable. The 100MB
limit is way too big for someone on a really limited cellular
plan, and way too small for someone on a high-end plan.
post_break - 4 hours ago
It should be as simple as a toggle to turn it off.
peapicker - 7 hours ago
This is definitely getting to be a major problem. I've removed
several apps for this reason as well.Code bloat = lost users
sly010 - 7 hours ago
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 bloatThat said, I also delete bulky
apps before I start deleting media.
digikata - 1 hours ago
Yup, and also bulky apps that insist on a two week rolling
release schedule...
tomjen3 - 7 hours ago
I think it is unlikely that most people care and the improved
analytics and development speed is probably worth it. My android
is connected to wifi almost 24/7, so it doesn't matter how long
it takes up update.
fulafel - 7 hours ago
Most people have small flash and can't fit many apps this size
in the space that is left over from the OS and photos/media.
Globz - 7 hours ago
Yeah it is a problem, and so far the way most companies fixed
this issue is by releasing a 'lite' version which of course is
probably not feature complete but will be significantly faster to
update and load.If you are on a good network you probably won't
ever notice such bloat until you run out of disk space or bust
your download limit (Canada)If I find an app to be too big for my
taste I normally fall back to the web version if it exist at all
but even then its hit or miss because sometimes the web app is
pure complete garbage or worse than the app itself.
akulbe - 2 hours ago
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. :)
saosebastiao - 7 hours ago
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.
[deleted]
ringaroundthetx - 3 hours ago
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!
ajross - 7 hours ago
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.
H4CK3RM4N - 10 minutes ago
Facebook in particular likes to break their web apps to push you
to use the native one. If you ever need to use Facebook in the
browser try mbasic.facebook.com(it even includes their
messenger).Also, relevant xkcd: https://xkcd.com/1367/
s73ver - 1 hours ago
"It works much better than you think"It still doesn't work as
well as a native app.
linopolus - 6 hours ago
the biggest annoyance being that these are even less integrated
and fine tuned to the environment than all those bloaty corporate
apps. The best apps still are made by small indy developers,
feeling right at home in their OS. Take for example Instapaper,
Fantastical, Outbank, Due, Reeder.. You just can't make web apps
so polished, so well integrated into the OS..
mikeash - 6 hours ago
I'm afraid it's exactly as bad as I think. I use web sites
instead of apps whenever I reasonably can, but most stuff I use
frequently is much better as an app.
samdung - 6 hours ago
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.
bathtub - 1 hours ago
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.
randyrand - 3 hours ago
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.
rootlocus - 7 hours ago
Six apps, six embedded web browsers.
WA - 7 hours ago
Apparently, Crosswalk [1] for Android adds "only" about 20MB.I
just compiled a Cordova-based Android-app without Crosswalk, but
also without images. Just JavaScript, HTML and CSS and a few
plugins and the APK is < 3MB. Was quite surprised by that.[1]:
https://crosswalk-project.org/
eerikkivistik - 7 hours ago
I think a few more years and we can finally stop bundling
browsers. It's not like anyone wants to bundle a browser inside
their app for fun. That being said, Crosswalk really solved
some serious issues for my product so cheers to them.
prophesi - 6 hours ago
Yeah, I used it a year or two ago, and it was nice for making
sure the experience was the same across all Android devices.
Glad to see the built-in Webview is getting place.
jamix - 7 hours ago
Facebook did flirt with HTML5 but ditched it in the end. So
that's not really true.
sidlls - 7 hours ago
They went off the deep end with their "engineering" of the app
(see: https://www.reddit.com/r/programming/comments/3m5n2n/face
boo...).It's really amusing to me when "engineers" start
talking about the "scale" of the UI. It's a client. Thin vs.
Fat aside, if it's that fat it's almost certainly a bloated
mess of redundancy and what is called "overengineering" (which
is actually underengineering--that is, a deficiency of the
application of engineering and architecture principles to the
design of the application).
Sir_Cmpwn - 7 hours ago
Are these slides available anywhere? The backup link is down,
too.
sidlls - 6 hours ago
I don't know. I just did a search for "facebook ios can't
handle our scale" because I remembered reading this some
time ago.
saosebastiao - 6 hours ago
I had a friend who quit working for Facebook about a month
before that slideshow was published, and it was hilarious to
see her mock it so mercilessly. She estimated a good 40% was
completely dead code, and another 20% was partially dead code
(e.g. code for notifying people of "pokes" without any
mechanism to view them). She also had some choice words for
the engineer who published the slides, but those can mainly
be pieced together from the general mockery on Reddit and
hacker news.
anonacct37 - 7 hours ago
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 - 7 hours ago
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 - 7 hours ago
I'm sincerely curious what would be the worst offenders for
app bloat.
potatolicious - 7 hours ago
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.
pier25 - 7 hours ago
Nope. Only Crosswalk embeds a browser engine in Android and the
project has been cancelled.Cordova uses the system WebView.
gok - 7 hours ago
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.
jstimpfle - 3 hours ago
For those who don't know, this is Parkinson's law :-)
vanderZwan - 7 hours ago
For the few among us who haven't read "The Website Obesity
Crisis", this is as good an excuse as any to link it
again:http://idlewords.com/talks/website_obesity.htm
trevor-e - 7 hours ago
Sorry for the extra bandwidth, forgot to optimize the images.
progval - 5 hours ago
Images do not seem to be the biggest culprit (unless you
already fixed them). I see 200kB of images and 600kB of
javascript (most of which comes from disqus)
chubot - 6 hours ago
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 - 3 hours ago
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.
Apocryphon - 5 hours ago
Sure, but the apps the blog talks about aren't two-man teams.
And some of these firms were already touted as dogfooding
their apps under resource constraints-
https://thenextweb.com/facebook/2015/10/27/facebook-
starts-2...They should be doing better than this.
jmduke - 2 hours ago
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...(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.")
ghostly_s - 7 hours ago
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-growth2. http://blog.timac.org/?p=17073.
https://blog.halide.cam/one-weird-trick-to-lose-size-c0a4013...
[deleted]
sehugg - 5 hours ago
That second link about the FB app is hilarious. As an example,
there are 3 copies of a 3.6 MB binary file used as part of an
optical flow algorithm (likely for 360-degree videos)So it's not
just that there's a bit of sloppy (or pragmatically careless)
packaging, but there's just a lot of stuff in these apps.
Xorlev - 7 hours ago
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 - 7 hours ago
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!
jimbobjim - 5 hours ago
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 - 5 hours ago
>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/Sounds
like "VoyagerFeed" may be part of their own codebase.
msoad - 7 hours ago
One word: SwiftIt's making app bundle sizes explode in size
ge0rg - 7 hours ago
Could you please elaborate, or provide examples?I can see how
high-res pictures embedded in the app can add dozens of
megabytes, and maybe a different runtime that you have to bundle
for compat reasons, but multiple hundreds of MB?
mikeash - 6 hours ago
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?
galad87 - 6 hours ago
Swift libs are ~ 10 MB, still 265 MB to go.
coldcode - 40 minutes ago
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.
pascalxus - 6 hours ago
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.
noahmbarr - 7 hours ago
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 - 7 hours ago
But it also adds to their bandwidth and storage bills
FRex - 6 hours ago
It's probably a drop in an ocean compared to their other
services.
amelius - 7 hours ago
But if Android apps are smaller and faster, people will switch
over to Android.
[deleted]
s73ver - 6 hours ago
I highly doubt that. Few people actually know how big any given
app is. Plus, there are more compelling things keeping people
on their platform of choice, like iMessage or the sunken cost
of apps that they've already purchased.
foepys - 7 hours ago
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.
DamnInteresting - 6 hours ago
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 - 6 hours ago
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.
saagarjha - 4 hours ago
> my MacBook keeps nagging me that my "hard disk" (actually an
SSD) is "full" because I only have 3GB of free spaceThat's
because it will use that space for caches and swap, and you're
preventing it from doing so and making the system slower.
DamnInteresting - 2 hours ago
Yes, I know. My point was that today's "practically none" was
20 years ago's "more than the OS can handle."
slaymaker1907 - 4 hours ago
And supposedly we don't need PWAs according to Apple...
nrhk - 3 hours ago
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.
antfarm - 6 hours ago
LEGO's app for their new robotic toy is 1.03 GB.
https://itunes.apple.com/de/app/lego-boost/id1217385613
crazygringo - 2 hours ago
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.
stormcode - 5 hours ago
Advertising APIs.
laurencei - 6 hours ago
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.
rz2k - 5 hours ago
While that sounds like a clever trick that Apple could use, they
really want to minimize production costs and maximize utility for
consumers. Their profit margin comes from a share of that surplus
utility.I suppose it can help hide price increases of the next
higher configurations, such as when the base configuration of the
MacBook Pro decreased from 256GB to 128GB between 2016 and 2017,
with the list price for 256GB configurations increasing by a
couple hundred dollars. However, Apple has also gone as far as
developing an entirely new filesystem to decrease storage use.
nerdponx - 6 hours ago
This is usually my thought when I see issues like this. If Apple
wanted to fix the problem, they would fix the problem.
wooter - 5 hours ago
this incentive analysis is so shallow it doesn't pass first
muster. does fitting/selling more apps make Apple more money?
are storage and bandwidth expenses? do users value performance?
most people here seem to agree more bloat = less users.
s73ver - 6 hours ago
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 - 1 hours ago
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.
jarjoura - 5 hours ago
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.
ehsankia - 5 hours ago
I'm curious, does anyone have the equivalent app sizes on
Android? I'd love to see a comparison, to see if this is more of
a platform issue as mentioned in a few comments, or a developer
issue.I guess we also should be looking at the actual data
transferred rather than the number shown on the store page.
MBCook - 1 hours ago
I'm 100% willing to believe this is a universal problem and is
just as bad as Android. I'd be FLOORED if Android apps were
significantly smaller.
tomerv - 1 hours ago
I checked now.LinkedIn: 20.36MB Facebook: 76.59MB Twitter:
25.71MBThat's about 1/8th the size of those apps on iOS.
Those are just the first three apps in use article, I'm sure
the rest are about the same.
MBCook - 1 hours ago
Wow.I wonder why it's so different.Hopefully someone can
chime in with the reason.
johncolanduoni - 1 hours ago
Java byte code is generally much smaller than equivalent
machine code. If you use something like Multi-OS engine
which statically compiles Java bytecode to native code
for iOS it's fairly typical to see an order of magnitude
difference in binary size.This actually affects Android
5+ too (Multi-OS engine uses Android's AOT compiler) but
since it happens on the device it doesn't affect download
sizes.
MBCook - 1 hours ago
Really? I've never heard that before. I'd guess it would
be bigger if anything.Any idea why that is?
mtl_usr - 4 hours ago
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 - 4 hours ago
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 - 3 hours ago
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.
justinclift - 2 hours ago
Not sure if "Linux distros" is the completely right term
there. The various *BSD based "ports" systems do similar
too.
marcosdumay - 3 hours ago
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.
mtl_usr - 4 hours ago
I guess they went as far as they could without a proper
package manager.> 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?Since the source code is shared with Apple once
it reaches the marketplace, wouldn't it be simpler for Apple
to compile a specific version for whatever version of the
Swift language is available on the target device ?It wouldn't
have any market value and wouldn't drive iOS devices sales
but is would certainly slim them down a little.> 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.This sorta makes me like iOS a bit more. Memory gets
cheaper but security doesn't get any cheaper when the
dependencies grow.
babesh - 2 hours ago
Your source code isn?t shared with Apple. You ship Apple a
binary or intermediate code.Edit: Also doesn?t help if you
have C or C++ code mixed in there.
richardwhiuk - 4 hours ago
It would have to entirely app stored manage - it's not possible
for iOS developers to currently share code between
apps.Everything that is shared between apps currently is stuff
that's provided by the shared platform.
saagarjha - 4 hours ago
> isn't it possible to bundle some dynamically loaded libraries
that can be shared by multiple appsYes, there is one: the
standard library, provided by Apple. However, many apps eschew
this to use their own libraries and frameworks for whatever
reason, be it ease of use or feature enhancements, and these
cannot be shared.
tomphoolery - 4 hours ago
> In reality, each one is its own little OS full of its own UI
frameworks, testing frameworks, and nontrivial code.Are you
talking about React Native apps here as well?
babesh - 4 hours ago
It?s partly unfair and only a partial picture. Many apps post
install proceed to download data.Some limit that amount of data
they download but a few are indiscriminate about it. I hated the
Yelp app because it seemingly did not limit how much space it
took up. The more reviews you viewed, the more space it took up.
I never found a setting to limit it. If you go to Manage Storage
you will discover that many apps take over 100mb in documents and
data.
svenfaw - 7 hours ago
What blogging engine is this? Real nice and clean.
jspash - 6 hours ago
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.
vladdanilov - 5 hours ago
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...[2]
https://twitter.com/rjonesy/status/878051126704254976[3]
https://twitter.com/vmdanilov/status/892015508203216896
mfabbri77 - 4 hours ago
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.
saagarjha - 4 hours ago
iOS vector asset catalogs (which use PDFs) actually don't
support true vector rendering; any vector images are converted
to PNGs at compile time.
jordansmithnz - 4 hours ago
As of iOS 11/Xcode 9 vector images are supported which is
quite nice. It may still convert to PNG for backwards
compatibility though, I?m not sure if App thinning discards
the PNG for iOS 11 devices.
LocalH - 3 hours ago
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.
justinclift - 2 hours ago
Wouldn't it make sense for the file format to just allow svg
in addition to others?eg png is fine, but if a developer
wants to include svg then let them.For developers who do care
about the clean, unblurred stroked at arbitrary pixel sizes
this wouldn't impact them at all.For the developers who care
more about the space taken up, this would give them a
potential useful option.
e12e - 2 hours ago
I might agree that for very small icons (eg: targeting a ~VGA
or 800x600 to maybe 1024x76 phone screen) hand painted bitmap
graphics might be best... but shouldn't it be enough to ship
16x16 (or whatever) icons along with vector graphics for
high-resolution screens? And if it's too slow to live-render
the graphics, how about rendering custom icon sets (etc) on
install - using the gpu, and then cache on the device?
Groxx - 2 hours ago
Fuzzy reasons abound, but you do occasionally see this. One
major often-complete-blocker that I've seen though has been
ungood rendering, so results aren't always identical on all
devices. You can't really rely on the device's possibly-weird
implementation (who knows what the OEM did to it)(except on
iThings probably), so you're forced to bundle an svg renderer
that works reliably on all devices and has consistent behavior,
and good luck finding a high quality lib that does that[1].
And, to be friendly to the designers, it has to be reasonably
full-featured.[1]: but if you know of one, I'd love to use it!
TylerE - 2 hours ago
Hand tweaking for specific resolutions is an art. You can't
expect to just render SVG and get equivalent results.
gcb0 - 26 minutes ago
even if you provide one svg for each range, you still gets
massive size savings for 99.9% of icons
mahyarm - 3 hours ago
Raster images are still faster and often you can make your png
images very small and do stretching.OTOH, people do vector
stuff for many things, it's just they typically don't use SVG
but something more efficient. XML parsing is not lightweight
compared to a binary format or some sort of vector -> code
translator speed wise.
moosingin3space - 2 hours ago
pcwalton's project Pathfinder
(https://github.com/pcwalton/pathfinder) may eventually lead to
an efficient GPU-based vector renderer, which would make this
feasible.
dgfgfdagasdfgfa - 2 hours ago
I mean, it's feasible now; plenty of folks use vector
rendering: Caching the result makes the CPU rendering much
easier to deal with. The GPU would really help more with
animations and dynamically constructed vectors.In any case, I
suspect something like lyon (https://github.com/nical/lyon)
would be a better fit than pathfinder, which is both a) not
super portable and b) very focused on rendering text, which
it does very well.
Simon_says - 2 hours ago
For some things like icons and UI elements, the automated
resizing gives worse (fuzzy) results than a human artist. It
makes a difference.
nathancahill - 4 hours ago
Because different graphics are shown are different resolutions,
rather than purely scaling a highly detailed 1024x1024 SVG down
to 128x128.
IncRnd - 2 hours ago
SVG = scalable vector graphicsSVG files are vector based.
iaml - 3 hours ago
>1024x1024 SVGVectors don't have pixels.
leddt - 2 hours ago
The point is still valid. An SVG designed for a high DPI
screen will most likely look bad on a low DPI screen.
matheweis - 2 hours ago
But they do generally have a nominal size at which the
artist considers the render to be optimal... no need to be
so short.
s73ver - 2 hours ago
However, they usually are designed around a target size.
And it's quite possible that, scaled too small, much of the
detail is lost. Hence why you'd still want different vector
files for different resolutions.
spyspy - 4 hours ago
I'm guessing but it seems logical that phones are not the place
you want to do extra graphics rendering if you don't have to.
GuB-42 - 3 hours ago
Modern smartphones have quite competent GPUs. They can run 3D
games at 1080p/60fps. They could raymarch circles around an
svg icon. And if it wasn't enough, the renderings could be
cached for later use.
dapreja - 1 hours ago
TBH not many people consider SVG format worth the effort
unless the graphic is made from scratch. 1) an organization
rarely rationalizes having a UI dev spend 6 something hours
either transforming an existing PNG to an SVG, or spending
12 hours compleitly replicate an existing design in
photoshop only for it to be exportable as an SVG. I could
be far fe5ching things but sometimes business or upper
management get short sighted on the small things. Probably
there is no rationalizarion in spending extra effort in
having these graphics all svg format, thus improving your
application's load and bandwidth utilization, vs pumping
more funds towards other easier quicker solutions.
kllrnohj - 56 minutes ago
GPUs do not like SVGs. They don't handle them well at all.
Most SVGs are CPU-rasterized as a result.
Froyoh - 41 minutes ago
This may be unrelated, but why do they push out updates every
other day or so? No other app is like that. And sizes aren?t
getting any smaller. They?re at version 137 right now...
chatmasta - 2 hours ago
A simple solution to this would be for Apple (or the developer,
via Apple) to distribute different builds based on the device
installing the app.That is, developers could compile a different
copy of the IPA for all target devices. Using variables like CPU
architecture, screen size, and other feature flags, a smart
compiler could cut a lot of code and assets that never run or
display on certain devices.(Granted, this would be much simpler
on iOS, which has a limited set of targeted devices compared to
Android.)In fact, it seems Apple has already taken steps in this
direction with its cloud compilation (I'm not an iOS developer,
so not sure of the specifics). What would worry me is if they
started requiring all source code be uploaded to their servers
for compilation. Going down that road is fraught with ideological
pitfalls.
magnetic - 2 hours ago
I think they already do that with bitcode. You upload the LLVM
bitcode and it will generate the code for the appropriate
architecture as needed. It's standard when you upload your app
to iTunes. They don't use your source code for that.
skywhopper - 2 hours ago
Wild guess, but presumably file size was not Apple's only or
primary consideration on image format. Rendering performance, app
load times, and power conservation all likely rank higher in
Apple's priority list that raw disk space used.
cybrjoe - 7 hours ago
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 - 6 hours ago
Why didnt you go staight to their web site? Its well usable on a
mobile browser.
jbverschoor - 6 hours ago
cordova, debugging info, unscaled and uncompressed images.
custos - 7 hours ago
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 - 7 hours ago
protip: switch to browser-based FB. it's perfectly reasonable.
colanderman - 7 hours ago
And, you can still access messages by selecting "Request
desktop version" from the Chrome menu.
qntty - 5 hours ago
This no longer works for me, YMMV.
lbebber - 7 hours ago
Or http://mbasic.facebook.com
maccard - 6 hours ago
Didn't know about this one, thanks. That's an extra 300MB
free on my phone from removing Messenger.
mavhc - 6 hours ago
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.
fenwick67 - 5 hours ago
And the permissions aren't as nuts.
vanderZwan - 7 hours ago
If you're on Android, you can try SlimSocial for Facebook +
Notifications for Facebook, both available through FDroid. 223
KiB and 103 KiB respectively.
marcusjt - 7 hours ago
There's also Facebook Lite https://play.google.com/store/apps/det
ails?id=com.facebook.l...And if Play Store won't let you install
it then download & install manually from here
http://www.apkmirror.com/apk/facebook-2/lite/
Rjevski - 7 hours ago
Analytics and ads/tracking is one of the reasons. They're always
writing/including more code to track every single click and pixel.
kutkloon7 - 7 hours ago
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.
jayd16 - 4 hours ago
>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.This is pretty tone def. The bulk of
apps are audio and ui assets and the compression rates on those
are quite good.That said, the compression rate for iOS apps is
horrible as Apple decides to encrypt and then compress the
binaries, completely blowing apart the compression ratio of
duplicate data.
richardwhiuk - 4 hours ago
Compress then encrypt is continually a source of
vulnerabilities.
rlv-dan - 7 hours ago
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.
deft - 7 hours ago
I'm pretty sure this is part of it. Remember leftpad? For
electron based apps they're just bundling all of chrome which
explains the size too.
allover - 7 hours ago
Leftpad is not an example of the issue mentioned. Leftpad is
an example of a small module that was being used by a lot of
projects. GPP is talking about pulling in larger libraries
which contain code not actually used by the app.(Also
Electron bundles 'just the rendering library from Chromium'
[1], not 'all of Chrome').[1]
https://electron.atom.io/docs/tutorial/about/#core-
philosoph...
deft - 1 hours ago
Sorry for not being specific. As for leftpad I just meant
the concept of using libraries when you really don't need
to. Not the size.
AndrewStephens - 7 hours ago
There are many reasons why apps are so big, but I think you are
right about a major part of the problem. Development
environments these days make it very easy to add in third party
libraries for very little effort.At a previous job we had a
monolithic java server that ended up at over 350Mb of compiled
code simply because each development team had imported whatever
libraries they thought they needed. In some cases, 2 or 3
versions of the same library were included.
wooter - 6 hours ago
i don't see why any of this is a problem
lsv1 - 6 hours ago
This is why code coverage is so important as part of the
general development cycle.
djKianoosh - 5 hours ago
Wait, code coverage? How does that address the number of
libraries used or duplicate versions of the same library?
slaymaker1907 - 4 hours ago
How did they get multiple versions of the same library to
work together? Java loads things via the class path so I
would have thought that would cause some sort of error.
swsieber - 4 hours ago
Some libraries change the namespace (package names) between
major versions, specifically to allow transition from one
to another in a gradual manor, or to start following
namespace guidelines better.
tedunangst - 3 hours ago
jarjar?
potatolicious - 7 hours ago
I think this is likely the biggest culprit. Another user
pointed out an analysis of the Facebook
app:http://blog.timac.org/?p=1707Most 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.
prophesi - 5 hours ago
I'd be interested in seeing an analysis of the Instagram app
post-takeover by FB. Its size has risen considerably since
then.
adrianratnapala - 3 hours ago
Depending on how they are made, how the linker is configured,
and the phase of the moon, static linking can help by just
taking the required functions.Also I think we, as
programmers, have taken the "don't reinvent the wheel"
principle too far. The idea is to use 3rd party code to (1)
save time writing, (2) reduce the risk of bugs, and (3) lower
the maintainance burden.But this makes sense only if the
benefits outweigh the corresponding costs of integration,
which also (1) takes time, (2) might be done wrong
(especially because you don't understand the part you added),
and (3) creates a maintainance burden. Of these, only #1 is
solved when your development environment makes adding new
libs quick and easy.
Swizec - 7 hours ago
> 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 - 6 hours ago
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 - 6 hours ago
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 - 2 hours ago
> 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 - 2 hours ago
> 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.
pm215 - 5 hours ago
If you want "just pull in the things I use" you can
already get that by having a static library, and if you
were going to be shipping a private copy of the .so file
in your app then surely you would be better off with a
static library -- you don't get any of the benefits of
the DLL (sharing with other apps, can update the DLL
without shipping a new copy of the whole app), so why pay
the cost of it?(If you link against the static library
then the linker pulls in only the .o files that the app
used, so assuming that the library was written in a
sensibly modular way you pay only the binary size cost
for more-or-less what you use. The linker can probably
discard at a finer granularity than whole-object-file
these days, but only-the-.o-you-use has been there for
decades.)
dfox - 3 hours ago
Probably only widely used static C library with fine
grained dependency tracking is glibc. The source code
structure required for that is probably one of the major
reasons for people to call glibc's source code unreadable
and/or unmaintable.
RodericDay - 6 hours ago
I interpreted the comment in exactly the same way, and
once again I'm baffled to see a perfectly polite and
correct comment downvoted and greyed out.
thehardsphere - 5 hours ago
Young minds don't like it when someone questions the
wisdom of how they reinvented the wheel, even when the
question comes from confusion instead of malice.
Swizec - 6 hours ago
Maybe you're not familiar with how it works. The idea is
that you do, let's say, "import lodash" then your
packaging system says "A-ha! But you're only using these
5 methods!" and only packages those.Behind the scenes,
lodash is built out of many modules, but you as a
developer don't need to think about that.Because tooling
isn't perfect yet, you have the option of helping it out
manually and being explicit about importing submodules.
We were able to reduce our compressed JavaScript size by
some 60% using a combination of automatic and manual
tricks like that at my day job.
dom0 - 6 hours ago
Many C++ libraries follow this approach.
joshvm - 5 hours ago
This happens a lot, especially with dynamic linking. I have a
project that uses Qt, OpenCV, CUDA, PCL and VTK - fairly
standard stack for 3D imaging and visualisation.Since you
normally need to bundle dependencies to account for different
versions, this adds up quite fast. Qt adds 20MB for OpenGL,
15MB for the VC++ redist, about 30MB for other core libraries.
Some stuff in OpenCV requires Nvidia's performance primitives
(NPP), so in goes nppi64_80.dll - that's 100MB alone.
opencv_cudaarithm310.dll is 70MB and even opencv_imgproc310.dll
weighs in at 30MB. And on and on.So yes, one little call to
cv::cuda::remap adds in a boatload of dependencies when all the
algorithm is doing is using a lookup table to sample an image.h
ttps://github.com/opencv/opencv/blob/master/modules/cudawar...
maxxxxx - 4 hours ago
It's pretty ironic that dynamic linking's main motivation was
to eliminate duplicate code and reduce code size. Deploy a
DLL once, every software uses it and doesn't have to include
it.Now it has turned out exactly the opposite way. If we went
back to linking object code together we would get smaller
sizes. Instead we have to include huge DLLs.
dfox - 3 hours ago
IIRC Windows has pretty involved infrastructure for
deduplicating same executable images both in memory and on
disk.
ryandrake - 7 hours ago
This would be true if the entirety of the library was used by
the application. Wouldn't the linker throw out anything unused?
msbarnett - 4 hours ago
Depends on if you're statically or dynamically linking. When
statically linking the final binary shouldn't contained
unused functions from external libraries.
teamhappy - 6 hours ago
> Wouldn't the linker throw out anything unused?There
(usually) is no dead code elimination for libraries.
maxxxxx - 5 hours ago
A lot of modern runtimes don't have linkers. With Java, C#
and JavaScript you get the whole library. There is no
elimination of unused code.
slaymaker1907 - 3 hours ago
Java as of Java 9 does have a linker.
mikeash - 6 hours ago
Depends on the language. If you're using something like C++,
you can probably remove a lot of dead code. But with more
dynamic languages, like Objective-C or Ruby or JavaScript, it
becomes difficult or impossible to prove that a given chunk
of code is never used. In Objective-C (which I'm most
familiar with), the linker will keep all Objective-C classes
and methods because it has no idea if you might be looking
things up by name at runtime and invoking them that way.Even
if you can throw away dead code, you can run into bloat
because a library has a massive set of foundational APIs that
the rest is built on, and using one little feature of the
library ends up bringing in half the library code because
it's used everywhere.
Retric - 6 hours ago
You could use static analysis to find out if anything calls
objects dynamically by name at run time which could be a
useful optimization. To be safe this would be one bool
value for the entire code base, but with some care it would
help. A larger issue is size is simply not considered a
significant issue.
mikeash - 6 hours ago
With Objective-C, that will always come back "true." Even
if you never use dynamic lookups, Apple's frameworks do.
I suspect the same is true of other languages.
Retric - 5 hours ago
Interesting, I find that surprising due to the overhead
involved. In most languages calling functions via string
names is very expensive.PS: Do you have an example?
mikeash - 4 hours ago
Nibs and storyboards are full of this stuff. They
instantiate classes by name, call methods by name, etc.
Some example documentation if you're curious:https://deve
loper.apple.com/library/content/documentation/Ge...https:
//developer.apple.com/library/content/documentation/Co...
https://developer.apple.com/library/content/documentation
/Co...Objective-C's dispatch is built around looking up
methods by their selector, which is effectively an
interned name. Looking up the selector can be slow, but
once you have one, invoking a method using a dynamic
selector is as fast as invoking one with a selector
that's known at compile time.
saagarjha - 4 hours ago
> Interesting, I find that surprising due to the overhead
involved.Due to the frequency of this, objc_msgSend
(which handles dynamic method calls) is hand-written in
assembly, with caching and "fast paths" to improve speed.
The overhead can usually be brought down to that of a
virtual function call in C++.
Retric - 3 hours ago
That's like saying shooting yourself in the foot only
hurts the first time. But, it's probably not a major
performance issue in practice.
dfox - 2 hours ago
The interesting part of this is that all this dynamism
and dependence on runtime actually improves performance
in comparison to C++. For example it is perfectly
possible to implement objc_msgSend in portable C such
that it is on modern superscalar and heavily cache
dependent CPUs on average faster than C++-style virtual
method call.
mikeash - 3 hours ago
That's the thing about performance. If you do something a
million times, it's usually OK if the first time takes a
thousand times longer than the fast case, as long as
subsequent times are fast.Look at how much code is
written in Ruby and Python. Their method dispatches are
way slower. To put it in perspective, it takes CPython
about an order of magnitude longer to add two numbers
together than it takes Objective-C to do a dynamic method
dispatch.
vec - 7 hours ago
A huge chunk of that probably goes to, well, videos or hi-res
photographs to be used in building the UI. Hi-res splash screens
plus a bunch of hero images plus 2+ prerendered sizes of each
display element for different pixel densities plus a dozen 30
second tutorial videos can easily add up to a couple hundred megs
of assets alone.
silassales - 7 hours ago
I think a large factor is the ever increasing need to have
different display sizes for different pixel densities,
developers essentially have to create and package a couple
versions of the same application into one package and that is
alot of waste.
masklinn - 7 hours ago
If the application is properly packaged, the appstore should
be able to generate configuration-specific variants which
only include the assets relevant to your device class (https:
//developer.apple.com/library/content/documentation/ID...)
silassales - 6 hours ago
This makes sense, a much better way to do things.
potatolicious - 7 hours ago
At least in the context of this article (iOS app bloat) this
is no longer the case - developers upload all assets for all
pixel densities, but Apple repackages for each specific
device, so that each device only gets one set of assets. Same
goes for binaries for multiple architectures - each device
only gets the binary for its specific CPU architecture.Also
to the GP's point - Apple also now no longer supports splash
screen images, so that element of bloat is no longer a factor
(though some legacy apps have retained them pointlessly).I
think for non-game apps assets are not the primary driver of
bloat.
silassales - 6 hours ago
Interesting, thanks for sharing that.I didnt know this as
the only mobile I have dabbled with has been game dev with
android in which case assets are the main cause of bloat.
vanderZwan - 7 hours ago
The worst part is that they probably use huge PNGs to make sure
the flat graphics are clean. You know, the kind that are
perfectly suitable for vector graphics.
wott - 5 hours ago
Unless your graphic designer provides you with vector
graphics embedding a vector for each pixel of the rasterised
image of the original vector graphic.Sigh...
vanderZwan - 2 hours ago
That's almost as bad as the autogenerated SVG I once was
sent that used hundreds of thousands of think horizontal
lines to fill an area. Instead of, you know, a filled
polygon.The sheer number of vectors could make any renderer
I threw at it crash.
crazygringo - 1 hours ago
Flat graphics are actually extremely compressible with
PNG's.That's actually one of the positives from moving away
from gradients and shadows everywhere, funnily enough.
saagarjha - 4 hours ago
Not for apps like Facebook. Their app binary is in the hundreds
of megabytes.
titzer - 6 hours ago
Too many programmers, too many templates and frameworks, poor
factoring, too much code reuse, bad build configurations, and
lack of LTO.
joeblau - 6 hours ago
Lots of things. Most companies now have huge development teams
and that means that you're going to get a lot of duplicate and
triplicate media assets. Duplicate and triplicate static
libraries and frameworks (which Apple is trying to address with
it's new dyld improvements[1]). As you also can't forget all of
the analytics and A/B testing frameworks that are put in place.
Each one of these apps can actually probably run 100^2
permutations of the app.[1] -
https://developer.apple.com/videos/play/wwdc2017/413/
sliverstorm - 3 hours ago
When I was developing a few pet apps, the reason was pretty
simple. I was pulling in entire libraries for one or two
functions. They were good libraries and good functions. I think
multiple examples were Google-provided app development libraries
that you roll into your app. Like, appcompat. Nobody can get by
without appcompat anymore it seems, but nobody needs all of its
functionality either.Anyway, probably millions of lines of code,
99.9% of which I didn't call. There is a tool for stripping code
that will not be called, and I reduced my apk's from ~20MB to
~1MB, although I wound up turning it off in the end because it
was not trivial to enable correctly. (I was linking 3rd party
binary libraries into my app which complicated things)
kutkloon7 - 7 hours ago
While I was typing this comment ghostly pointed out some great
blog entries: https://news.ycombinator.com/item?id=14901602
miguelrochefort - 7 hours ago
Things will only get worse. The application paradigm is
unsustainable.https://medium.com/@miguelrochefort/the-application-
paradigm...
sidlls - 6 hours ago
The current alternative, treating the Browser like a poorly
implemented, feature-scarce OS on which to run "web apps", is
worse.
gue5t - 6 hours ago
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 - 2 hours ago
...So by hiring / lucking into someone whose job it is to look
at UX. Like a designer.
r0ze-at-hn - 7 hours ago
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.
TeeWEE - 7 hours ago
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)
Eridrus - 6 hours ago
I don't know the status of iOS, but Android has done some work on
sending diffs on updates, so real sizes should be smaller: https
://android-developers.googleblog.com/2016/07/improvemen...Doesn't
do anything for size on disk, but should help network a lot.
eerikkivistik - 7 hours ago
Yep, agree with the image bundling issues. We have tried to keep
our footprint as small as possible in our own product (3D
modeling application https://3dc.io) and are clocking in at 8mb
on iOS. Out of that about 3MB are icons/splash images and other
media. Regarding vector graphics, we couldn't use them, as they
cause bugs and flickering with css animations in iOS Safari. But
we do generate everything we can procedurally (primitives,
colorpicker etc.) which saves a ton of space.
whowouldathunk - 7 hours ago
> 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.
filleokus - 6 hours ago
Is it possible maybe to render out the vector graphics once (on
the device) and then have them pre-rendered (cached) until they
change?I guess it would add considerable overhead for a
negligible improvement in size (compared to just shipping all
images) for most devices.EDIT: Too slow...
outworlder - 4 hours ago
But you don't have to redraw them all the time.
[deleted]
lcnmrn - 6 hours ago
Why vectors can't be pre-rendered and cached?
whowouldathunk - 5 hours ago
That's what a bitmap asset is.
marcosdumay - 2 hours ago
Except that a cache is disposable, and disposed often in
practice.
adamnemecek - 7 hours ago
I wonder is this is due to lack of generics in objc.
miguelrochefort - 7 hours ago
I know this affects Xamarin apps.
chc - 6 hours ago
Objective-C has fully dynamic dispatch. In a context like that,
generics are just a type safety thing to ensure that you aren't
sending messages to the wrong type ? they don't make the
executable any smaller.
adamnemecek - 6 hours ago
They make code reuse possible. Watch this Sean Parent video
https://www.youtube.com/watch?v=4moyKUHApq4 where he estimates
that if Photoshop was rewritten using generics, the code size
would go from 3,000,000 LOC to 30,000 LOC. You are right,
during compilation, generics are specialized so you end up with
code, however going all in on generics removes a lot of
accidental complexity.
chc - 5 hours ago
I think you've misunderstood my point. What code reuse is
possible with generics that is not not possible in
Objective-C without generics? I don't think there is very
much, because Objective-C fundamentally doesn't care the
types of objects.
adamnemecek - 5 hours ago
The full answer would be kinda long but this is a rehash of
the debate that has been had many times over.You cannot
just compare obj-c vs generics, you need to also account
for the fact that when you are obj-c development, you might
need some fast code and as a result drop to c. And code
reuse is hard to impossible in C.The fact that code reuse
can be done without a performance hit is enough of a
difference difference on it's own as it pushes down the
level at which code reuse can be done. E.g. you can use
generics for Graphics or Audio or general low level stuff.
swolchok - 3 hours ago
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...
adamnemecek - 27 minutes ago
I'm aware, they are nowhere near comparable.
[deleted]
outworlder - 4 hours ago
That has nothing to do with code size. You'll either get some
sort of type erasure, which will create the types are compilation
time anyway, or you'll have some sort of dynamic dispatch.
Neither approach will make the generated code any smaller and may
even make it bigger.
dineshswamy - 7 hours ago
I m building a product that would bring the size of the apps way
down
twsted - 7 hours ago
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 - 6 hours ago
Not only, there is IMHO also a "technological supremacy"
bias.Quite obviously most developers will have:1) VERY powerful
hardware2) VERY fast (and unlimited) internet connectionIt'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 - 5 hours ago
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 - 4 hours ago
OT but not much, and JFYI, I started using an alternate unit
of measure for web page sizes, the Doom:https://twitter.com/x
bs/status/626781529054834688https://pbs.twimg.com/media/CLLGe
nwWgAAZAVv.pngLike: Hey, nice home page it is only 3 Dooms
...
borplk - 2 hours ago
It's not just "lazy developers".For most freelancers and
contractors the economics of the market means most of the time
you have to be lazy or you will lose the job to someone else.
davexunit - 5 hours ago
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 - 3 hours ago
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.
gregoriol - 4 hours ago
I tweeted some frustation about this a few days ago
(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 - 4 hours ago
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.
jorgemf - 7 hours ago
With text-only webs over 5MB I wouldn't expect less from mobile
apps.