Bitcode also now deliberately trades off size vs speed and includes indexes used for LTO, etc. They could be including those.
You should almost always expect bitcode to get beat by "llvm-dis|xz", because the goal of bitcode is not to be the most compact possible format, but instead, a compact format the compiler can use effectively :)
Now, if actual on-device binary sizes increased, my guesses would be:
1. it now includes bitcode, or another architecture, in the binary (which would be interesting)
2. Something has gone horribly horribly wrong :P Really, speaking as a guy whose org maintains the toolchains for platforms like this, there's a 0% chance we wouldn't notice a 2x-3x size increase.
1 - The binary format itself isn't very efficient. Compressing it usually yields at least a 50% reduction in final size, often more
2 - Even though .ipa is a zipped format, there's no actual compression on the binary itself because it's encrypted before compression. I have no idea why they do this, I can't perceive any security benefit(Any jailbroken phone can be tooled to output the unencrypted binary. And you can bet anyone trying to reverse engineer your app will be using a jailbroken phone for their work)
Basically, if you're a large company with lots of apps and shared dependencies(Google, Facebook, etc...) doing the "right" thing and writing shared library code across projects ends up bloating your binary size immensely. And since binary size(rather than resources like images) dominate the final app size, you're in trouble if you want to keep app size down.
Source: I work on the iOS app for a music streaming service, despite our best efforts, our app downloadable size is ~35MB(~45MB installed size). Our android counterpart, almost effortlessly has the same app functionality with a 14MB downloadable package(they did some cleaning a while ago and got it down to 10MB at some point). Thing is, if we do proper compression(no binary encryption, single architecture) we end up with a 19MB .ipa file
PS: The compression issue doesn't affect installed size, but I believe the issue here is simply that (1) the binary format they're using is just too damn inefficient by default
These numbers were all around 60mb on Xcode 8.2.1
(Pardon the joke, but while the "m" obviously means "M" from context, I really wish people -- especially computer engineers -- wouldn't say bits when they mean something eight times as large.)
Specifically to those who don't use iTunes Connect, this page is titled "Estimated App Store file sizes for Build", and the (?) callout says "This is the amount of disk space the app will take up on the customer's device."
That's the size as uploaded by the developer, not downloaded to user.
So
* the bitcode portion has grown by 4.5x
* the non-bitcode portion of the bundle has grown by 2.2x (40MB to 88MB)
https://twitter.com/JokerEph/status/847512069209432064 https://twitter.com/JokerEph/status/847513808570523653 https://twitter.com/JokerEph/status/847514189929234432
bitcode is already compressed.
But the regression is huge, there needs to be a command-line switch to turn that off.
With bitcode, app thinning and what not in the mix the Xcode build artifact is so much different from what's actually being downloaded it's hard to tell if this radar has real world implications for anyone but the developer uploading the build to apple. Still interesting, and potentially annoying though.
I guess there is also a risk that the compilation process generating 3x larger files could also be slower as more work are being done - but that's just speculation.
Binary sizes in iTunes connect (from our Xcode 8.3 build) all were 2x-3x larger depending on device.
Side note: filing a Radar is the new top of the customer acquisition funnel. Go Realm! :)
So, a) for devs, if you think your app caches, provide a way to clear it (look at Opera's Coast browser, who puts it in the Settings app), and b) for users, if you think you are out of space, look at apps and compare app size to total space, and you'll find some hogs.
https://developer.apple.com/library/content/documentation/Fi...
> "Note that the system may delete the Caches/ directory to free up disk space, so your app must be able to re-create or download these files as needed."
> tmp: "however, the system may purge this directory when your app is not running."
Let's not forget that they are a hardware vendor.
I don't think it's some grand conspiracy theory, but the interests of the vendor and of the user are not precisely aligned when it comes to efficient usage of storage. (The lack of stripping applications of their alternate language content on install/download also comes to mind.)
(For example, removing @2x images for a plus device that uses @3x images, or vice-versa).
Afaik bitcode is so that Apple can rebuild binaries for different target architectures (e.g. new models of phone, watch, et c) without source developer interaction. It should come in major handy in the OSX app store when ARM64 Macbooks ship in a year or two. A full app store of working apps on hardware launch day will make the bitcode requirement worth it when it's the smoothest architecture transition they've ever done (out of 680x0->ppc and ppc->x86).
As for alternate language content, honestly that stuff doesn't take up very much space, and stripping it would break the code signature. The only way Apple could strip that is if they perform the equivalent of App Thinning based on a list of languages you specify when downloading the binary from the App Store (and even that wouldn't apply to downloading non-MAS apps).
Yeah. It's not like Apple had to settle lawsuits about batteries that seemed to be designed to break after a while. Oh, wait...
Apple limit 100 mb per download.. So this big issue for all developer.We need apple to remove the limitation over 100 mb or atleast 1GB.
