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 :)
Module File
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.
![enter image description here]()
Why not Swift?
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.
