Note that the size increase is in the _bitcode_ portion of the binary. This slice is stripped from the binary before it makes it to the user's device. This means the size increase is merely an inconvenience during the development process, and has no impact on the size of apps as users see them.
Really need to change the title to reflect that the increase in size is not present in App Store binary.
Side note: filing a Radar is the new top of the customer acquisition funnel. Go Realm! :)
So, the app explodes in size, and since almost no app provides a "clear cache/temp" feature, apps grow til you are crashing routinely. While iOS may clear some space when it feels like it, I have a monthly routine of deleting and reinstalling a slew of apps which take up gigs of space on the device after usage, even though they are just showing data stored on a server. I know, I shouldn't have to worry about this, that iOS will eventually clean it up... but when apps are crashing b/c they can't get space, I wind up having to manually step in.
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.
This is due to bitcode, which won't actually affect the binary size seen by end users (i.e. app download size): https://twitter.com/jckarter/status/846796503775567872 "That at least shouldn't affect your users' download size, then."
Isn't 10.3 the first version that is introducing the new APFS file system? If so, couldn't that have something to do with it? Does each app need to compile for both supported file systems now? I am not a LLVM expert but someone with more expertise on this subject might be able to say. I just found it odd that no one else here had mentioned it. It is the big update for 10.3
This has been fixed with Xcode 8.3.1.
Did anyone actually look at the content which is responsible for the increase in size? I hope it does not include the source itself, comments, and who knows what.
It also seems to take 3x longer while the previous version was no speed demon either. Guess why I have so much time to post here?
wonder what would https://github.com/google/bloaty say about those binaries...
Remind me of Visual Studio
Apple charges $1200 to upgrade the latest touch bar rMBP from 512GB to 2TB of flash.
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.)
The same codebase compiled with Xcode 8.3 produces a binary about three times larger at 158MB, including 70MB for bitcode alone.
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.
This appears to be bitcode. It probably means they just starting making use of more metadata or something that is now included in the bitcode.
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.