Is your iOS app piling on weight? Blame Xcode 8.3: We shed light on Apple's bloat riddle

Hmm, I'm highly suspicious about this. Bit code would not inflate the size of the binary to anything like that extent, if at all. Much more likely is that this development team has simply, directly or indirectly, used some SWIFT. It may be one of the frameworks nearly every development project will use. It may even be an Apple supplied framework. Apple are using SWIFT with ever more frameworks, and as Apple's own frameworks are precompiled and the SWIFT use can be entirely behind any frameworks used by this company's app, Apple could easily have done this in a way that meant the developer didn't have to change any compiler settings that would have alerted him to the fact SWIFT is now being used.

For now, while SWIFT is a young language, Apple want to ensure the language can be revised. A problem for many languages before SWIFT has been that the fundamental syntax and compiled code structure gets locked down before anyone has a chance to use the language, as it were, "in anger." To overcome this Apple are simply revising the language for a period of time and provide the migration tools to update existing swift code with any revisions. But this then poses a versioning problem. If structure of compiled code is revised, compiled code will be incompatbile with compiled frameworks if from different "versions" of the language. To overcome this, during a fixed initial period, when a developer uses SWIFT or a framework requiring SWIFT, a version of the entire SWIFT "runtime" compatible with the SWIFT version used in the App (it isn't actually strictly a runtime but the phrase will do here), is included with the App. This, understandably adds a large overhead. Once the SWIFT language reaches its final form, then apps will use common library code and there will be a significant reduction in App binary size.

That does sound plausible, and it fits the general disarray and lack of planning that's surrounded Swift since its launch. ("well, we looked at the mess that is Python 2/3 and thought 'hey, we're Apple, our developers will totally follow us when WE break source-code compatibility!")

As for even including bitcode in submissions in the first place, I can see two reasons: first, it's easier to screen the Intermediate Language inside those files than the optimised machine-code that actually gets run, so bitcode makes it easier to find unauthorised API calls, malware, or anything else that Apple doesn't want to accept. The second is that I'd imagine that Apple was simply leaving the door open for Intel-powered iThings, or ARM-powered macThings (or, heaven-forfend, a touch-enabled Mac that could run iOS apps?).

Microsoft does this second bit already with its Universal Windows Platform: your submission is in CIL (the interpreted byte-code used by all .Net languages), which the Store backend compiles down to a native x86 or ARM binary as appropriate depending on your target platforms.

(and, one small thing? Apple's contribution to the technology world having too many programming languages is called "Swift". It's not an acronym, it's just a word. "SWIFT", in capitals, is how banks transfer money between each other.)

Do we know for sure app sizes didn't increase too?

Several well known apps seem to have massively grown in size recently... Suspicious..