@yousefhamza @jrose here's what I've done so far, can you help me on this?
To clearly state what my issue is, I want to avoid the following problem:
- I release a (closed-source) framework that contains Swift 5.0 code;
- some developer adds the framework to their app;
- Swift 5.1 is released;
- the same developer updates the app to Swift 5.1;
- the developer must also update the framework to a version compiled with Swift 5.1;
- I'm forced to immediately release a Swift 5.1 update for my framework.
My understanding is that ABI stability will prevent this need from a runtime point of view, but without module stability Xcode will tell the developer that my framework needs to be built with Swift 5.1 to work in its Swift 5.1 app.
Now, to avoid this problem I can release an Objective-C framework in which the Objective-C part is just the public interface, plus an implementation file that calls the underlying Swift code. In trying to do this, I've run in 2 problems:
- to be able to call the Swift code from the
.m Objective-C file I need to make all the needed Swift code
public, so that it appears in the
<$PRODUCT_NAME/$PRODUCT_NAME-Swift.h> header, that I'm going to import in my
- the built
.framework package still contains lots of references to the fact that Swift is there;
The first issue is not really a big deal: I can simply expose just a single Swift class to the Objective-C runtime, and call the real code from that class.
The second issue seems more problematic, also because I'm not sure which generated files will affect module stability, and which won't. In the built
.framework package there are exactly 3 places where Swift is referred to:
- within the
I added a script in the last build phase to delete the first two, and edit the
module.modulemap to remove the lines that describe the Swift module. I then tried to embed the framework in two example projects, one in Swift and one in Objective-C, and everything seems to be working fine: I'm able to call both
import $PRODUCT_NAME and
#import <$PRODUCT_NAME/$PRODUCT_NAME.h> and call the code with no error, both during compilation and runtime.
Does all this make sense?