gophering on
HN Gopher Feed (2017-08-01) - page 1 of 10
App sizes are out of control
398 points by trevor-e
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
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
    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. ;)
    spcelzrd - 6 hours ago
    Progressive Web ApplicationsIt's the new name for a home screen
    jessaustin - 6 hours ago
  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)
      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?
  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]
  Kiro - 5 hours ago
  What exactly is the difference between a PWA and a mobile
    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
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.
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 even includes their
  messenger).Also, relevant xkcd:
  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
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]:
    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
    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,
        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
    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
  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
  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-
      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.
/kayak-flights-hotels-cars/id...(As far as I can tell, the answer
to "why is 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.
  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."
  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
  amelius - 7 hours ago
  But if Android apps are smaller and faster, people will switch
  over to Android.
    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
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
  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.
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
    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
          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
        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
      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
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 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][2][3]
  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
    ( may eventually lead to
    an efficient GPU-based vector renderer, which would make this
      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 (
      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
    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
        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
    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
  ails?id=com.facebook.l...And if Play Store won't let you install
  it then download & install manually from here
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
  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]
        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
    potatolicious - 7 hours ago
    I think this is likely the biggest culprit. Another user
    pointed out an analysis of the Facebook
    app: 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
      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
      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, 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 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, 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
          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
      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
    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


          /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
  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:
        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
        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] -
  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:
miguelrochefort - 7 hours ago
Things will only get worse. The application paradigm is
  sidlls - 6 hours ago
  The current alternative, treating the Browser like a poorly
  implemented, feature-scarce OS on which to run "web apps", is
  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
  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 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.
    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
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 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:
    adamnemecek - 27 minutes ago
    I'm aware, they are nowhere near comparable.
  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
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
      jaclaz - 4 hours ago
      OT but not much, and JFYI, I started using an alternate unit
      of measure for web page sizes, the Doom:
      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
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