2

First of all, I've been an Objective C developer for years, and around the time that Swift was announced I was mostly maintaining existing Obj C projects. The chance never came to be fully invested in a Swift app, whether from scratch or to maintain. My efforts where directed mostly towards .Net and React Native at that time.

I've done research on what ABI is. It's all fine and dandy. From that answer, I can only assume how that comes into play for Swift, since I do not have much heavy involvement with Swift.

So, from simply guessing, is all the ruckus, racket, and fracas in Swift ABI talk to do with the 'assumed' fact that when a library is written/compiled with version 1.0 of Swift (before Swift 5), it will work fine with an app written in 1.0. When the next version of that library is written in Swift 2.0, that aforementioned app written in Swift 1.0 will not be able to use it, unless compiled for Swift 2.0? Assuming that I am correct on that one, what if I have an app written in Swift 4, and the library I wish to use was written in Swift 1.0 Can I use it? With Swift 5 now released, are ABI issues now resolved for Swift libraries and apps 5+, and not 5+ interacting with 5- ?

If I had experienced these issues first hand I might have had a better understanding of Swift ABI issues.

Please explain with actual examples that cover the full range of cases (if possible).

Update: please include if there are any issues with ABI for small version increases eg from swift 4.0 to 4.1

pnizzle
  • 6,243
  • 4
  • 52
  • 81

2 Answers2

1

The chiefly interesting thing to know about ABI stability is that for systems before iOS 10.2 and Swift language versions before 5.0, the Swift language frameworks have to be embedded in the app, adding several MB to its size and perhaps some other runtime overhead. But in iOS 10.2+ and Swift 5.0+, now that there is ABI stability, that stuff is in the runtime and Swift apps are much smaller, probably faster, and quicker to launch.

In other words, thanks to ABI stability, Swift is now the first class citizen that Objective C and Cocoa have been all along.

matt
  • 515,959
  • 87
  • 875
  • 1,141
0

Application Binary Interface. ABI stability for Swift is about compiling source code into binary files with a common interface over several versions of the language. Without an ABI stability, the binary files across versions of the language, are incompatible with each other, because their formats differ. Dynamic libraries, for instance, have a static call table. As quoted from Wikipedia: "An ABI defines how data structures or computational routines are accessed in machine code". An ABI stability ensures that the library and caller (the app) use the same binary protocol for invoking functions, even if not compiled for the same version of the language.

For Swift's purpose, an ABI stability will allow developers to switch to newer versions of the language, without updating their libraries/frameworks, that way taking advantage of the newer features of the language without waiting for the libraries to get updated. From a Swift.org article back in February: "Today, when a Swift library changes, any apps using that library have to be recompiled." Again, from that article:

ABI stability for Apple OSes means that apps deploying to upcoming releases of those OSes will no longer need to embed the Swift standard library and “overlay” libraries within the app bundle, shrinking their download size; the Swift runtime and standard library will be shipped with the OS, like the Objective-C runtime.

For you as a developer, ABI stability in Swift, means more compatibility with libraries. Due to the Swift language developers needing to ensure that the ABI stability doesn't break, the rate of addition of new features will drop.

Andreas is moving to Codidact
  • 1,642
  • 4
  • 21
  • 40