Apple’s Chris Lattner, original creator of the Swift language, has recently announced on the Swift Evolution mailing list that ABI stability, one of the goals originally planned for Swift 3, will be postponed.
In Lattner’s own words:
Some of the loftier goals that we started out with aren’t going to fit into the release - including some of the most important generics features needed in order to lock down the ABI of the standard library.
As a consequence, ABI stabilization has been removed from the Swift Evolution repository’s ReadMe.
As it was stated in the original ReadMe, ABI stabilization would allow applications and libraries compiled with future versions of Swift to be able to interact with binary code compiled with Swift 3.0. Thus, ABI stability would guarantee some level of binary compatibility, even in spite of changes in the source language, and would make it easier for third-parties to ship binary libraries. Additionally, ABI stability would allow to remove the need to ship the Swift standard library along with binaries, as is currently the case with iOS and OS X apps created with Xcode.
Lattner also clarified that the discussion concerning this feature and when it will make it into the language will take place starting sometime around August 2016. It is not yet clear whether ABI stability will come with Swift 3.1 or 4.0, but Lattner expects it to be one of the highest priority features.
Lattner’s announcement was met with some complaints about how most of the goals originally considered for Swift 3 have been dropped. Other comments stressed how Swift 3's initial scope was defined at the very beginning of Swift open-sourcing, and that it was input provided by the community which later drove Swift to focus development on other areas of the language that needed better definition before the ABI could be stabilized. Apple engineer Greg Parker additionally remarked that once an ABI is defined, it becomes very hard to change it, as the history of OS X and iOS architecture transitions demonstrates. In particular, he mentions a few cases where the Objective C ABIs had deliberate or accidental flaws mostly due to schedule pressure, such as BOOL being a character instead of a proper boolean, or the use of setjmp-longjmp exceptions instead of "zero-cost" exceptions due to GCC legacy, and others. All in all, he concludes:
If we tried to rush Swift ABI stability out the door for Swift 3 we would certainly end up with deliberate or accidental flaws [...]. Being able to take the time to get it right is a rare luxury.