Hello,
I'm still confused with whole ABI and module stability discussions, so I have a very general question (probably a bit silly, so sorry about that 
)
I have a small iOS SDK, that I'm providing to some clients. I've made some errors and wrong architectural choices, and it is time to re-write it from scratch.
So basically from Swift 5 perspective and from perspective to be used from old Objective-C projects is it worth it to create Swift only SDK?
Hey 
,
Nothing silly about it, people here have been on both ends of that conversation hehe, so I would say we all understand :).
It depends on the companies/people you plan to give the SDK to and their requirements and if you plan to give source code access.
If you cannot give source code out, my advice is to stick with Objective-C for a while longer as it will cause the least amount of support pain for you and will decouple your clients and you interns of iOS target and minimum deployment SDKās and all.
If you go for binary Swift frameworks, the paths are two: one if you decide to wrap your framework in a thin Objective-C wrapper layer (this should allow you to use Swift 4.2/5 compiler and mandate licensee/users of the library use at least iOS 11 IIRC, need to double check @jrose is the best reference here, as minimum SDK and you will have both module and ABI stability helping you isolate your library from the Swift version and Xcode and iOS requirements your licensee may have) or an option that could work is to use the Swift 5.1 compiler (Xcode 11) for the library and iOS 13+ as target SDK. I would advise to start this once you and your users are all using Xcode 11+ and can target iOS 13+. From an app developer point of view I would prefer to wait for that scenario too.
Queue āsmall blurbā around it I wrote for one of our docs (forgive me everyone if there are issues with it... seemed to make good sense especially at that time):
Binary Frameworks
If a third party developer shared a binary, pre-compiled, framework with us we need two key concepts to be implemented and working in order for our apps to build correctly: ABI stability and module stability. In short, we call ABI stability the fact that two binary pre-compiled libraries/apps have a stable binary specification to target and which you could use to have them communicate over. We say we have reached module stability when two separate modules can communicate with each other regardless of how they were built (different version of the Swift compiler, different versions of the Swift language specifications)
Summary: ABI stability means that two binary frameworks will work together at run time, but the compiler in Xcode 11 still isn't able to understand the framework content from Xcode 10.2. Starting in Xcode 11, however, there's a new format for binary framework module interfaces that's intended to be stable going forward --J.Rose - Apple
References:
Binary Frameworks - Solutions and Future Proofing
There are a few solutions to this issue that would allow companies to best utilise the platform at hand while not being restricted by N third parties at once (this is from an app developer perspective not user perspective):
[All iOS versions] Write the libraries (binary framework/library) in Objective-C
[All iOS versions] Use Swift, but give the gamesā source code to the app developers so that they are compiling all the libraries together
[Xcode 11 / Swift 5.1] Use Swift, create binary frameworks/libraries
Kind Regards,
Goffredo
Using Xcode 11 does not require a minimum deployment target of iOS 13. Is there a place we implied that?
No you have not implied Xcode 11 mandates iOS 13 as minimum deployment SDK. Corrected the post, thanks for the notes :).
You still have "[iOS 13+] Use Swift, create binary frameworks/libraries", but that's not limited to iOS 13. It just requires Xcode 11.
What is the lowest target SDK you can have for that to work? I would guess there is none then as before iOS 13 is just Xcode version / Swift compiler version dependent.
By the way, edited that portion reflecting your comments, thanks again :).
Correct, any iOS that Xcode 11 supports deploying to. Thanks for updating!
@Panajev @jrose If we're compiling some sort of compatibility list, it should really call out the fact that there are Swift features that don't backward deploy at all, regardless of ABI or module stability. Opaque return types are one, but are there others? While it's not as relevant for SDKs as for apps, there may still need to be some consideration for the fact that there are Swift 5.1 features you can't use on Apple's platforms until you can target the 2019 OSes.
You need to target them, but they do not make your code require minimum deployment SDK bumps unless you do not or cannot have fallbacks for them (but I may be missing things here sorry :)). It is an interesting conversation indeed, but I would then be very interested about the effects on a framework provider in this case?
Right, but the same complexity that prevent their backward deployment makes them hard to duplicate. AFAIK, you canāt recreate opaque return types in another way, so unless you ship a duplicate API in your SDK, you canāt use the feature.