Menu
Menu
Binary frameworks? Without ABI? In Swift? What’s the deal with Swift Modules? In his talk, Peter discusses binary frameworks and stability, when and why ABI matters, and why his team writes in Objective-C. Learn more about what you can do right now, what other companies are doing, common pitfalls, and the future.
Peter also published an in-depth article on the PSPDFKit blog about this topic.
Good afternoon everyone! My name is Peter Steinberger, and I am the founder of a company that sells a PDF SDK. We sell the binary and not the source code. People often ask us, "Why do you still write Objective-C?" The answer is not that simple.
So everybody has heard about the application binary interface and the fact that Swift has no stable ABI yet, and that it’s somehow bad. The ABI describes how the data is laid out in memory, how the type metadata is stored, how function names are mangled, what the calling conventions are exactly, how calls into the runtime are made, and of course, the whole standard library.
To give you an example, in older versions of Swift, Array was 24 bytes. Now, it’s 8 bytes. So, if you have code that uses the new 8-byte Array, and you have older code compiled in an older compiler that expects the 24-byte Array, it will read uninitialized memory, and you know how that goes. Once the ABI is stable, the Swift team will have a much harder time making such performance and memory optimizations.
Now, Swift ABI is a moving target. It was first mentioned as a goal for Swift 3 in 2015. And as Swift 3 got closer to the release, it didn’t make it. Then Swift 4 kicked off with the goal of achieving binary stability. And as it entered phase two, people reiterated the importance of ABI, but it was deferred. Now, Swift 5 has kicked off, and “stable ABI is a hard goal.” Apple even created an ABI Dashboard. This time it’s really happening — at least, we believe so.
Now, why does this matter, and how does this affect you? One reason is if you use a compile cache — for example, you can build something with Carthage, which stores the compiled binary to speed up your build time. Currently, you have to be very, very careful, as there is no safety net. If you are lucky, you link two pieces with different compilers and you get a linker error. If you’re not as lucky, things just crash in the runtime in a weird way.
The second reason is that, currently, every app ships the Swift standard library, i.e. the runtime library that’s needed for your programs to work. Once the ABI is stable, Apple can move this library into the OS. This will save a few megabytes per application, so if you do the math, if you have 100 applications, that’s half a gigabyte. And it also allows you to reuse the shared library across the whole OS, so it only needs to load it once and not many, many times. As a result, memory usage goes down, and app startup speed goes up.
Notice how I didn’t say anything about binary frameworks, because we’re missing one crucial thing, and that’s the Swift module format.
The Swift module file is basically the binary equivalent of a C or Objective-C header file. This includes API declaration and even inlineable code. The compiler needs it for type checking and code generation.
Module format stability is a stretch goal for Swift 5, and given that it’s a really large and complex topic, it’s likely not going to happen anytime soon.
Now, this doesn’t mean that Swift binary frameworks are not possible. In fact, they are, and there’s one very prominent one out there already by SAP: the SAP Cloud Platform SDK. It works, as long as you use the exact same version of Xcode, so down to the patch level if you’re unlucky. You can see that this is quite limiting already, and SAP even has a blog post about the topic. I checked yesterday, and the last version was for Xcode 9.1.
To summarize:
If you want to learn more, you can read my in-depth article about this topic on the PSPDFKit blog. Thanks for listening!
Peter founded and bootstrapped PSPDFKit GmbH in 2011, and has since expanded the company with the goal of providing the highest quality PDF framework for all platforms. While Peter is responsible for the day-to-day management of the team, he never misses the chance to go under PSPDFKit’s hood and improve upon the original code he wrote back in 2011. Peter has worked with iOS since the inception of the iPhone, and is regularly invited to speak at conferences around the world. Prior to PSPDFKit, he worked as a Senior iOS Engineer at a startup in San Francisco and taught iOS and Mac development at his alma mater, the Vienna University of Technology. Follow him on Twitter.