4 ms·

In my opinion, the integration between Objective-C and Swift is so incredibly seamless, that there's no need to translate existing Objective-C code. When I sta

In my opinion, the integration between Objective-C and Swift is so incredibly seamless, that there's no need to translate existing Objective-C code. When I started working at my current client, there was a huge existing Objective-C code base to talk to an internal HTTP API. I just started coding. When I needed to add functions, I subclassed Objective-C classes in Swift.

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 ago
  Doesn'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 ago
    Indeed. 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 ago
  Yeah, that could be an interesting use case.

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 ago
Doesn'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 ago
  Indeed. 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 ago
Yeah, that could be an interesting use case.