Swift Libraries Not Included in iOS 9 or El Capitan
Chris Lattner (contra Mark Gurman):
There were no public statements that Swift 2.0 would eliminate that requirement (just some rumor sites claiming that) and in fact Swift 2 will continue to require the standard library in your app.
We are interested in making Swift ABI stable going forward, but will need more time to settle things out. In particular, we want to make sure that we get to incorporate ideas and feedback from the open source community before locking things down.
This is really good news for Swift in the long term. However, it does make deployment less attractive in the short term. Gurman says that the libraries for an application take up 8 MB. I found that a Hello World command-line tool is 3.6 MB. Regardless, this gets multiplied by the number of binaries in your application: background helper app, XPC service, Spotlight importer, Quick Look plug-in, Automator action, command-line tool, etc.
Update (2015-06-15): It is not always the case that there will be duplicate copies of the Swift libraries for each binary. For example, a .appex bundle will automatically link to the libraries in its containing app. Xcode 6 does not seem to do this automatically for other bundle types, but in theory a future version could. Any binary such as a command-line tool that could be moved, relative to the main application, probably needs to embed its own copy of the libraries.
Update (2015-07-27): Sam Marshall:
There is a build setting named
EMBEDDED_CONTENT_CONTAINS_SWIFTwhich stores a boolean value. There is an Apple Q&A document that describes how to use this, however there are some assumptions made as to how this flag is to be used.When enabling the
EMBEDDED_CONTENT_CONTAINS_SWIFTflag on a target, a new step is added to the build process. This step runs the target’s build product through a tool calledswift-stdlib-tool, which parses the binary header to get the list of linked dependencies (frameworks/libraries). It will then check the paths of these linked dependencies to see if any of them contain references to the Swift runtime libraries.
4 Comments RSS · Twitter
I agree that this is a smart move. The longer they delay stabilizing the ABI, the more flexibility they have with updating the language. Transforming the top-level generic functions within the standard library from to a series of protocol extensions in Swift 2, for example, is something that would probably have been impossible if they had to stay backwards compatible with the existing ABI, and is an excellent improvement to the language.
App thinning really makes most of the complaints about Swift app bloat moot, in my opinion. There is no longer a multiplier on the 8MB size hit on the customer side, since they will only download the binary appropriate for their device, and if you still are dancing on the 100MB cutoff for OTA downloads, on-demand resources can get you the rest of the way there.
@Lee I wouldn’t say moot. You still have a multiplier for each iOS binary (e.g. extension). And the OTA stuff only helps with flash storage, not RAM, which iOS devices still have relatively little of.
[…] Protocol extensions are so so so cool, but ultimately, I think my stance will stay the same. Via Michael Tsai, iOS 9 still doesn’t have ABI compatibility. My new plan is that once Swift is source […]
[…] possible that overall system performance would decrease if more apps use Swift. The binaries are larger, so they’ll take up more storage space and RAM. They’re calling back and forth to […]
