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

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.