Behind the burn, there is a good point :P


Tangentially related, but reminds me of some very carefully worded info about app size improvements people would see for Swift 5 apps back in the Xcode 10.2 timeframe.

It was neat because a simple print("hey")-style app went down from a few MB to a few KB.

1 Like

Is it public knowledge how that reduction was done? We had a bunch of these similar types of optimizations for .NET and Silverlight back when I was at Microsoft. Sometimes, we had to increase the size of the runtime to incorporate the weight each app would have been carrying around. Other times, we did the opposite and reduced the size of the runtime by shifting some of the burden to the apps.


For the Swift issue in particular, it’s that apps didn’t need to include the dynamically linked libraries for the Swift runtime and SDK overlays (like libswiftAVFoundation.dylib for AVFoundation). More generally there’s app thinning and bitcode, where you can ship an app with a deployment target so low that it needs the embedded dynamic libraries for those older OSes, but still thins them out for newer OSes.

1 Like

Nice! I can’t imagine all the complexities involved behind the scenes for making this work well and at scale.