Right, I forget to mention that. But if you are in the cross platform space thats just how they all work (that I've encountered at least). The difficulty of consuming Swift in Objc vs the other way around means that lots of iOS libraries are Objc based, but Apple is starting to signal that it might be over sooner than later as they begin to introduce new Swift/SwiftUI-only subsystems. Or maybe they have an ace up their sleeve with exposing those in the Objc space. Doubt it.
EDIT: and a nitpick. Its not generating any objc code. Its generating a binary which is exposed to swift using the same mechanisms that objc libraries use. I.e. it compiles to a native binary (an xcframework or framework, I forget which). It doesnt transpile.
> Its generating a binary which is exposed to swift using the same mechanisms that objc libraries use. I.e. it compiles to a native binary (an xcframework or framework, I forget which). It doesnt transpile.
right, though the native library (xcframework) exposes its interface as objc objects (.h header files), since swift only knows how to read c and objective-c modules afaik...
EDIT: and a nitpick. Its not generating any objc code. Its generating a binary which is exposed to swift using the same mechanisms that objc libraries use. I.e. it compiles to a native binary (an xcframework or framework, I forget which). It doesnt transpile.