5 ms·

> Nike iOS app install size was 182.2 MB. A week later, it was 322.1 MB This is besides the point, but is anyone else concerned just how insane those sizes are

> Nike iOS app install size was 182.2 MB. A week later, it was 322.1 MB This is besides the point, but is anyone else concerned just how insane those sizes are? There are operating systems smaller than that, why is that needed for a single app from a sports brand? What is this app even supposed to do? How much functionality did they need to cram into it to get a 180MB binary? Why does the app even exist? Why does it apparently need 160MB of just text to do whatever unfathomable job it has?

stock_toaster 4y ago
Launch images (png) for every supported screen size? Sound/media files? Libraries? I’m sure it starts to add up.
- csande17 4y ago
  Haven't launch screens used resizable Storyboard layouts for several years now?
  - drEv0 4y ago
    They have. I believe Xcode even warns if a project is not using the resizable option.
- outcoldman 4y ago
  I used to have an app built for some AWS services (mac, ios). First decision to use some AWS libraries added size to the binary, it grew from 1MB to 70MB, I wrote simple AWS library myself just for my needs and that resulted in the binary of 2-3MB. Most of those apps use a lot of common libraries that add a lot of size to the binaries.
  - version_five 4y ago
    I'm working on a machine learning project where we're trying to package something up, and bringing in all the packages that get installed by default with the framework we're using adds gigabytes to the size of the application, almost all of which is probably not necessary. The challenge is it's bloat on top of bloat, without an obvious way to pare it down, so it becomes a separate engineering effort to try and make something small and efficient. Under a certain size and for many applications, it's more cost effective just not to worry about it and keep the bloat
    - kelseyfrog 4y ago
      I found myself in the same situation a few years ago. We hacked together a dubious version of treeshaking using 'python -v' and got the thing small enough to run on an aws lambda which saved a bunch of money. Fun times.
- causi 4y ago
  Launch images (png) I'm flatly amazed that sort of thing isn't some kind of bitmap/vector hybrid format. Like a high resolution central logo and then rules for defining the background, like "blue fading to white at the edges".
  - interpol_p 4y ago
    iOS has not required launch images for every size for some time now (since iOS 8 in 2014). It requires instead a piece of UI called a launch storyboard [1], which scales using the standard UI layout system to the different sizes However custom images can still be set for every possible size, if you really want [1] https://developer.apple.com/documentation/xcode/specifying-your-apps-launch-screen https://developer.apple.com/documentation/xcode/specifying-y...
  - Lukas_Skywalker 4y ago
    Android has an interesting solution to this called 9-patch-files [1]. They basically add a 1px-margin around the image. By coloring the margin in different colors, you tell the OS what areas to stretch and what should be kept as-is based on the screen size. [1] https://developer.android.com/studio/write/draw9patch https://developer.android.com/studio/write/draw9patch
- hulitu 4y ago
  > Launch images (png) PNG files (if not generated from a jpg) are quiet small.
  - dagmx 4y ago
    They're not. You're likely thinking of indexed color PNGs, but full color depth PNGs are quite large. A JPG/HEIC/AVIF image will be significantly smaller. The source of the PNG doesn't matter.
gok 4y ago
Developers want to avoid writing one simple thing, so they add a huge dependency, then never remove the dependency even if they later remove the needed feature. And then they don’t even bother to enable trivial optimizations like dead code stripping because they just don’t care.
- piskerpan 4y ago
  > they just don’t care. This is it. Developers on broadband and tight budgets don't care about app size. On the App Store there's usually no direct correlation between app size and conversion rate: the app will eventually be available anyway.
  - AlfeG 4y ago
    Should I write my own QR parser or just use available one. Should I write my own crypto algo or just use battletested one. Every line I write - line I need to support.
    - hulitu 4y ago
      > Should I write my own crypto algo or just use battletested one. Why would the "battletested" be better ? It is "battletested" by the user, anyway. > Every line I write - line I need to support. So you prefer to support someone elses code instead of yours ? ( because it is battletested - just like log4j was)
      - nomel 4y ago
        > Why would the "battletested" be better ? It is "battletested" by the user, anyway. Your tense is incorrect there. "Battletested" means that past users have experienced the carnage of war, so current users can enjoy peace. Your second usage would need to be changed to present tense, like "battletesting", where you subject them to suffering.
    - piskerpan 4y ago
      I’m with you on that, but the two are not mutually exclusive. I don’t know how it is exactly in Xcode, but in my field there’s a huge difference between importing a whole kitchen sink named “moment.js” or a few “date-fns” functions.
int_19h 4y ago
We're just running ahead of schedule on this: "Programming went back to the beginning of time. It was a little like the midden out back of his father’s castle. Where the creek had worn that away, ten meters down, there were the crumpled hulks of machines — flying machines, the peasants said — from the great days of Canberra’s original colonial era. But the castle midden was clean and fresh compared to what lay within the Reprise’s local net. There were programs here that had been written five thousand years ago, before Humankind ever left Earth. The wonder of it — the horror of it, Sura said — was that unlike the useless wrecks of Canberra’s past, these programs still worked! And via a million million circuitous threads of inheritance, many of the oldest programs still ran in the bowels of the Qeng Ho system. Take the Traders’ method of timekeeping. The frame corrections were incredibly complex — and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely … the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind’s first computer operating systems. So behind all the top-level interfaces was layer under layer of support. Some of that software had been designed for wildly different situations. Every so often, the inconsistencies caused fatal accidents. Despite the romance of spaceflight, the most common accidents were simply caused by ancient, misused programs finally getting their revenge." - Vernor Vinge, "A Deepness in the Sky"
- Nition 4y ago
  The bit I really loved about this passage when I first read it, because it's so clever, is that of course these people with a space-faring culture assume that Unix time was based on the date we first landed on the Moon.
- db48x 4y ago
  Best book ever. I recommend it it frequently!
newZWhoDis 4y ago
We know what mediocrity creates this garbage, but we can’t speak of it here.
summerlight 4y ago
Usually because of dependencies. It's fairly frequent to add tens of megabytes when you pull some SDK or frameworks... Most of those functionalities are of course not needed at all, but unless you design a library with small binary size in mind it's very hard to automatically prune out those dependencies.
mejutoco 4y ago
As a software engineer I agree with your concern. These apps were most probably optimized for developer speed, and not for size or user experience.
novok 4y ago
Because swift is a space inefficient language that likes to specialize & copy everything like it's a C++ template, because it's basically C++ templates gone wild under the hood for speed(tm). If you inspect the types swift makes under the hood sometimes, they can get silly huge. Then add codegen for your protobuffer network models and you explain most of the code bloat. 150k lines of objective-c will be significantly smaller than 100k lines of swift pretty much any day of the year. Look at tweetbot for example, still objective c for the most part, a fairly complicated app, still actively developed and only 30MB.
- saagarjha 4y ago
  Swift doesn't actually specialize things like C++. If you look at the ABI it will pass generic arguments around at runtime.
flohofwoe 4y ago
My guess is it's a mix of an 'NPM mindset' of how to deal with dependencies (e.g. 'the more the merrier'), and then including those dependencies as dylibs/frameworks instead of static linking, which kills any chance of dead code elimination (e.g. it doesn't matter if you only call a single function in a dependency, you still get the whole thing included in the app bundle).
- andrekandre 4y ago
  yep, was able cut down an app from 70mb down to 10mb just by stripping out some 3rd party libs, and it turns out that most of the time only 1 or 2 functions were being used in a lot of cases anyways... i see this all the time...
rockbruno 4y ago
Swift is awful for app size. Structs carry an absurd amount of overhead, some of which is just plain questionable[0]. At one point even Apple's official docs were urging you to not use structs in Swift, though that has since been removed (probably because of SwiftUI being struct-heavy) [0] - https://forums.swift.org/t/reducing-value-witness-size-in-struct-composition/52172 https://forums.swift.org/t/reducing-value-witness-size-in-st...
db48x 4y ago
Most of that size is not “functionality”. The size doesn’t come from the program, it comes from the ancillary data files that go along with the program. You can actually see that in the TreeMaps, there are large files like “Zipcodes.sqlite”, “ph-data.json”, “imgCameraOnboarding1@3x.jpg”, “Alipay_icon_square.pdf”, “OnboardingLanding.mp4”, “FindFour.mlmodelc”, and so on. The next major component is the orange “strings” files like “Localizable.strings”. These are repeated a bunch of times, once for each (human) language that the app supports. If you click on them to zoom in, you will see that there is one called “el.lproj/Localizable.strings”, a “ru.lproj/Localizable.strings”, “pl.lproj/Localizable.strings”, and so on. Finally there are the blue “text” sections, which is the actual executable code (the name is historical, these sections actually contain binary machine code rather than readable text). There are no exact counts on the webpage, but I would say that the executable code is around a third of the size of the app, possibly less. And of course, the whole point of the article is that these apps now have a fourth major component: debugging symbols. These give you the name of every variable and function used in the program, as well as the filenames and line numbers for each instruction in the executable code. These are over 40% of the app size just by themselves. Because these symbol tables are so large, it has been increasingly common to split them out into their own files and only distribute them to your own developers, rather than to every user’s machine.
ChrisRR 4y ago
As an embedded dev who often fits his software down into 64KB, it always suprises me when a simple app takes 1-200MB. Functionality wise so many of these apps could've been achieved on Windows 3.1, and yet they're 3-4 orders of magnitude larger
- db48x 4y ago
  I frequently hear statements like that, but I doubt that it is literally true. Just the localization files in this app are easily a third of its size, and back in the Windows 3.1 era nobody could afford to casually install 40 megabytes of strings for languages they could not read. My entire hard drive held just 40 megabytes back then! (Also, Unicode didn’t quite exist yet.) Incidentally, the TreeMaps provided in this article are really amazing. If every scientific paper provided this level of access to their data, we would be a lot better off.
  - ChrisRR 4y ago
    I'm surprised that any app would need 40MB of text. War and Peace is only 3.2MB

stock_toaster 4y ago

Launch images (png) for every supported screen size? Sound/media files? Libraries? I’m sure it starts to add up.

csande17 4y ago
Haven't launch screens used resizable Storyboard layouts for several years now?
- drEv0 4y ago
  They have. I believe Xcode even warns if a project is not using the resizable option.
outcoldman 4y ago
I used to have an app built for some AWS services (mac, ios). First decision to use some AWS libraries added size to the binary, it grew from 1MB to 70MB, I wrote simple AWS library myself just for my needs and that resulted in the binary of 2-3MB. Most of those apps use a lot of common libraries that add a lot of size to the binaries.
- version_five 4y ago
  I'm working on a machine learning project where we're trying to package something up, and bringing in all the packages that get installed by default with the framework we're using adds gigabytes to the size of the application, almost all of which is probably not necessary. The challenge is it's bloat on top of bloat, without an obvious way to pare it down, so it becomes a separate engineering effort to try and make something small and efficient. Under a certain size and for many applications, it's more cost effective just not to worry about it and keep the bloat
  - kelseyfrog 4y ago
    I found myself in the same situation a few years ago. We hacked together a dubious version of treeshaking using 'python -v' and got the thing small enough to run on an aws lambda which saved a bunch of money. Fun times.
causi 4y ago
Launch images (png) I'm flatly amazed that sort of thing isn't some kind of bitmap/vector hybrid format. Like a high resolution central logo and then rules for defining the background, like "blue fading to white at the edges".
- interpol_p 4y ago
  iOS has not required launch images for every size for some time now (since iOS 8 in 2014). It requires instead a piece of UI called a launch storyboard [1], which scales using the standard UI layout system to the different sizes However custom images can still be set for every possible size, if you really want [1] https://developer.apple.com/documentation/xcode/specifying-your-apps-launch-screen https://developer.apple.com/documentation/xcode/specifying-y...
- Lukas_Skywalker 4y ago
  Android has an interesting solution to this called 9-patch-files [1]. They basically add a 1px-margin around the image. By coloring the margin in different colors, you tell the OS what areas to stretch and what should be kept as-is based on the screen size. [1] https://developer.android.com/studio/write/draw9patch https://developer.android.com/studio/write/draw9patch
hulitu 4y ago
> Launch images (png) PNG files (if not generated from a jpg) are quiet small.
- dagmx 4y ago
  They're not. You're likely thinking of indexed color PNGs, but full color depth PNGs are quite large. A JPG/HEIC/AVIF image will be significantly smaller. The source of the PNG doesn't matter.

gok 4y ago

Developers want to avoid writing one simple thing, so they add a huge dependency, then never remove the dependency even if they later remove the needed feature. And then they don’t even bother to enable trivial optimizations like dead code stripping because they just don’t care.

piskerpan 4y ago
> they just don’t care. This is it. Developers on broadband and tight budgets don't care about app size. On the App Store there's usually no direct correlation between app size and conversion rate: the app will eventually be available anyway.
- AlfeG 4y ago
  Should I write my own QR parser or just use available one. Should I write my own crypto algo or just use battletested one. Every line I write - line I need to support.
  - hulitu 4y ago
    > Should I write my own crypto algo or just use battletested one. Why would the "battletested" be better ? It is "battletested" by the user, anyway. > Every line I write - line I need to support. So you prefer to support someone elses code instead of yours ? ( because it is battletested - just like log4j was)
    - nomel 4y ago
      > Why would the "battletested" be better ? It is "battletested" by the user, anyway. Your tense is incorrect there. "Battletested" means that past users have experienced the carnage of war, so current users can enjoy peace. Your second usage would need to be changed to present tense, like "battletesting", where you subject them to suffering.
  - piskerpan 4y ago
    I’m with you on that, but the two are not mutually exclusive. I don’t know how it is exactly in Xcode, but in my field there’s a huge difference between importing a whole kitchen sink named “moment.js” or a few “date-fns” functions.

int_19h 4y ago

We're just running ahead of schedule on this: "Programming went back to the beginning of time. It was a little like the midden out back of his father’s castle. Where the creek had worn that away, ten meters down, there were the crumpled hulks of machines — flying machines, the peasants said — from the great days of Canberra’s original colonial era. But the castle midden was clean and fresh compared to what lay within the Reprise’s local net. There were programs here that had been written five thousand years ago, before Humankind ever left Earth. The wonder of it — the horror of it, Sura said — was that unlike the useless wrecks of Canberra’s past, these programs still worked! And via a million million circuitous threads of inheritance, many of the oldest programs still ran in the bowels of the Qeng Ho system. Take the Traders’ method of timekeeping. The frame corrections were incredibly complex — and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely … the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind’s first computer operating systems. So behind all the top-level interfaces was layer under layer of support. Some of that software had been designed for wildly different situations. Every so often, the inconsistencies caused fatal accidents. Despite the romance of spaceflight, the most common accidents were simply caused by ancient, misused programs finally getting their revenge." - Vernor Vinge, "A Deepness in the Sky"

Nition 4y ago
The bit I really loved about this passage when I first read it, because it's so clever, is that of course these people with a space-faring culture assume that Unix time was based on the date we first landed on the Moon.
db48x 4y ago
Best book ever. I recommend it it frequently!

newZWhoDis 4y ago

We know what mediocrity creates this garbage, but we can’t speak of it here.

summerlight 4y ago

Usually because of dependencies. It's fairly frequent to add tens of megabytes when you pull some SDK or frameworks... Most of those functionalities are of course not needed at all, but unless you design a library with small binary size in mind it's very hard to automatically prune out those dependencies.

mejutoco 4y ago

As a software engineer I agree with your concern. These apps were most probably optimized for developer speed, and not for size or user experience.

novok 4y ago

Because swift is a space inefficient language that likes to specialize & copy everything like it's a C++ template, because it's basically C++ templates gone wild under the hood for speed(tm). If you inspect the types swift makes under the hood sometimes, they can get silly huge. Then add codegen for your protobuffer network models and you explain most of the code bloat. 150k lines of objective-c will be significantly smaller than 100k lines of swift pretty much any day of the year. Look at tweetbot for example, still objective c for the most part, a fairly complicated app, still actively developed and only 30MB.

saagarjha 4y ago
Swift doesn't actually specialize things like C++. If you look at the ABI it will pass generic arguments around at runtime.

flohofwoe 4y ago

My guess is it's a mix of an 'NPM mindset' of how to deal with dependencies (e.g. 'the more the merrier'), and then including those dependencies as dylibs/frameworks instead of static linking, which kills any chance of dead code elimination (e.g. it doesn't matter if you only call a single function in a dependency, you still get the whole thing included in the app bundle).

andrekandre 4y ago
yep, was able cut down an app from 70mb down to 10mb just by stripping out some 3rd party libs, and it turns out that most of the time only 1 or 2 functions were being used in a lot of cases anyways... i see this all the time...

rockbruno 4y ago

Swift is awful for app size. Structs carry an absurd amount of overhead, some of which is just plain questionable[0]. At one point even Apple's official docs were urging you to not use structs in Swift, though that has since been removed (probably because of SwiftUI being struct-heavy) [0] - https://forums.swift.org/t/reducing-value-witness-size-in-struct-composition/52172 https://forums.swift.org/t/reducing-value-witness-size-in-st...

db48x 4y ago

Most of that size is not “functionality”. The size doesn’t come from the program, it comes from the ancillary data files that go along with the program. You can actually see that in the TreeMaps, there are large files like “Zipcodes.sqlite”, “ph-data.json”, “imgCameraOnboarding1@3x.jpg”, “Alipay_icon_square.pdf”, “OnboardingLanding.mp4”, “FindFour.mlmodelc”, and so on. The next major component is the orange “strings” files like “Localizable.strings”. These are repeated a bunch of times, once for each (human) language that the app supports. If you click on them to zoom in, you will see that there is one called “el.lproj/Localizable.strings”, a “ru.lproj/Localizable.strings”, “pl.lproj/Localizable.strings”, and so on. Finally there are the blue “text” sections, which is the actual executable code (the name is historical, these sections actually contain binary machine code rather than readable text). There are no exact counts on the webpage, but I would say that the executable code is around a third of the size of the app, possibly less. And of course, the whole point of the article is that these apps now have a fourth major component: debugging symbols. These give you the name of every variable and function used in the program, as well as the filenames and line numbers for each instruction in the executable code. These are over 40% of the app size just by themselves. Because these symbol tables are so large, it has been increasingly common to split them out into their own files and only distribute them to your own developers, rather than to every user’s machine.

ChrisRR 4y ago

As an embedded dev who often fits his software down into 64KB, it always suprises me when a simple app takes 1-200MB. Functionality wise so many of these apps could've been achieved on Windows 3.1, and yet they're 3-4 orders of magnitude larger

db48x 4y ago
I frequently hear statements like that, but I doubt that it is literally true. Just the localization files in this app are easily a third of its size, and back in the Windows 3.1 era nobody could afford to casually install 40 megabytes of strings for languages they could not read. My entire hard drive held just 40 megabytes back then! (Also, Unicode didn’t quite exist yet.) Incidentally, the TreeMaps provided in this article are really amazing. If every scientific paper provided this level of access to their data, we would be a lot better off.
- ChrisRR 4y ago
  I'm surprised that any app would need 40MB of text. War and Peace is only 3.2MB