3 ms·
There is need to translate existing Objective-C code: on platforms where the Objective-C bridge is unavailable (Linux and Windows), Swift code can not call Obje
by zapzupnz 6y ago
There is need to translate existing Objective-C code: on platforms where the Objective-C bridge is unavailable (Linux and Windows), Swift code can not call Objective-C code, nor toll-free bridge with Objective-C types, and therefore Objective-C types cannot be subclassed.
For non-Apple platforms, you have to use a different implementation of Foundation — which has pretty good but not identical coverage to Apple's one.
As a side note, it's always seemed clear to me that when Apple provides a new technology, they provide a stop-gap solution, like Carbon, for developers who, for a variety of possible reasons, may not be able or willing to use the new tech, like Cocoa.
The bridge between Objective-C and Swift has always seemed like Carbon to me.
Fortunately, unlike when Carbon was canned and rewriting for Cocoa seemed like a real chore, I don't think Apple will can the Objective-C bridge any time soon — but for Swift code now targeting or intending to target non-Apple platforms, it may be best to start thinking about migrating away from relying on the bridge now — decarbonify your Swift code.
- DagAgren 6y agoDoesn't seem like there would be much demand to run legacy Objective-C code on other platforms, as it would most likely be strongly tied into macOS or iOS APIs that would be availble anyway.
- zapzupnz 6y agoIndeed. Although, some of the things that Apple's ObjC Foundation provides that aren't in Swift's cross-platform Foundation are sorely missed — but I doubt there's much impetus to put them in Swift's cross-platform Foundation, either.
- cerberusss 6y agoYeah, that could be an interesting use case.