Dear Swift Community,
A few weeks ago, I started a discussion in this forum about what it would take to add non-Apple Objective-C interop support using the GNUstep runtime. While there are several Objective-C implementations for non-Apple platforms, GNUstep seems to be the most widely used and there is a dedicated community of users who would really like to see this happen. As a result of the discussion, I think the most practical approach would be to make Objective-C interop on non-Apple platforms largely consistent with Apple platforms, while requiring a separate compilation mode and standard library distribution.
I would therefore like to get some opinions from Swift maintainers on whether this is something they could see being added to Swift and what the upstreaming process could look like once a prototype is ready.
I'm proposing to add GNUstep interop support as a separate compilation mode, such as a platform variant.
For a Swift program compiled with GNUstep interop enabled this means:
- A different ABI, because the compiler needs to emit GNUstep compatible Objective-C metadata.
- Additional checks in Swift's runtime function, to handle operations on types like AnyObject, which are already performed on Apple platforms but have been disabled for non-Apple platforms.
- Use an "interop enabled" release of the Swift runtime and Corelibs Foundation, which provides type bridging functions.
Runtime and Standard Library changes:
- Define
SWIFT_OBJC_INTEROPon non-Apple platforms for the interop release - The interop releases of the Swift standard library and runtime would have a dependency on libobjc2 and the GNUstep Foundation libraries (Which will also require work to implement missing SPIs and enable Swift object handling)
- Implement a number of type conversion codepaths in the Swift standard library, to support casting GNUstep Foundation to Swift Foundation types and vice versa.
Compiler Changes:
- Replace
SWIFT_OBJC_INTEROPcompile time guards with runtime guards. This would likely entail some refactoring inswiftcand could benefit code structure as well. swiftccode generation must emit GNUstep-compatible metadata for classes, metaclasses, protocols, etc. It may be possible to make internal Clang APIs available for this purpose, which already implement GNUstep metadata generation.- Additionally, some optimized code paths rely on objc4 specific behavior, which would be difficult to implement in GNUstep's Objective-C runtime. For example, objc4's tagged object pointers. There would be a compile time guard for this with non-Apple interop.
This would be an opt-in mode, intended to keep the impact on existing platforms isolated while enabling additional interoperability use cases.
Since this work would primarily target non-Apple platforms, integration and long-term maintenance would likely be driven by the community. Ongoing work, such as changes in objc4–Swift contracts (e.g. the addition of new SPIs), would largely fall on GNUstep. Perhaps a community-maintained support model would be possible?
I and others would be interested in developing a prototype, and I would not expect Swift maintainers to help with the implementation at this stage. Cross-platform Objective-C interop would not only improve Swift code portability, but allow users with large Objective-C codebases to incrementally adopt Swift.
I look forward to your thoughts on this.