Menu
I need to make an library for iOS (either Framework or static library - I haven't decided yet) that can be used in both Objective-C and Swift projects. What is the best way of doing this? The way I see it I have three options:
The main requirement here is that it should be as easy for developers to use as possible. Ideally, they should be able to choose their language and not care, or indeed even know, what language the library itself was written in. Can this be done?
Also, I want to be able to distribute the library with CocoaPods, if this has any significance.
872
You can use Objective-C and Swift files together in a single project, no matter which language the project used originally. This makes creating mixed-language app and framework targets as straightforward as creating an app or framework target written in a single language.
And, since then, Objective-C has been the primary language for software at Apple. It's important to note here that Objective-C is a proprietary language, which means that only Apple can make core changes to the language.
The correct approach is as follows: Import your Objective C framework by dragging and dropping the framework into an Xcode 6 Swift project. Create a new Objective C file in your project (File->New->File [Objective C for iOS]). Accept the prompt (agree) to create a bridging header file between Objective C and Swift.
An XCFramework can be either static or dynamic and can include headers.
Option 2. Is out of question (described in detail later)
Option 3. As you said, you should really avoid it.
Option 1 is the best. Just design your API with Obj-C and Swift in mind. What does it mean ?
• Don't use selectors - they're not a Swift standard.
• Use nullability to convert to optionals
• Closures and blocks may have the same syntax, but there's a slight difference, watch out for that:
Swift closures and Objective-C blocks are compatible, so you can pass Swift closures to Objective-C methods that expect blocks. Swift closures and functions have the same type, so you can even pass the name of a Swift function.
Closures have similar capture semantics as blocks but differ in one key way: Variables are mutable rather than copied. In other words, the behavior of __block in Objective-C is the default behavior for variables in Swift.
Source: Apple's Using Swift with Cocoa and Objective-C - It explains everything in detail.
You can read more here.
When designing such API you have to know how everything is converted, but if you do it right the users won't notice a difference :)
Make sure your x.framework is shipped with the modules folder and file inside.
New Xcode generates it for you. This way users can use your Obj-C project in Swift without adding it to a bridging file. So they can just import myLib out of the box.
Unfortunately, the most sensible way to distribute a compiled library right now is to write it in Objective-C.
And that's because of one big reason: Swift Binary Compatiblity Problem
While your app’s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together.
This means that frameworks need to be managed carefully. For instance, if your project uses frameworks to share code with an embedded extension, you will want to build the frameworks, app, and extensions together. It would be dangerous to rely upon binary frameworks that use Swift — especially from third parties. As Swift changes, those frameworks will be incompatible with the rest of your app. When the binary interface stabilizes in a year or two, the Swift runtime will become part of the host OS and this limitation will no longer exist.
Peter Steinberger, the founder of PSPDFKit, which is also a library distributed as a compiled library has ran into the same problem: they're stuck with Obj-C for now and can't use Swift.
75
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
