An Approach for Migrating From Objective-C to Swift
It was difficult to gracefully integrate new Swift code into existing Objective-C classes and systems. A year down the line we still had a mostly Objective-C code base. Almost anything of any real importance was still in Objective-C, and all we’d really built was some surface level Swift on top of an Objective-C core.
[…]
Everything that’s great about Swift has to be sacrificed for Objective-C interoperability. Value types, generics, enums with associated values, optionals.
If you have a whole bunch of Objective-C and you write a tiny bit of Swift in the middle, then that Swift ends up being crappy Swift.
[…]
The key is that we start with a small Swift ‘island’. It can be just be one Swift class. We write nice Swifty code that we can be proud of, and then we provide shims that our Objective-C code uses to interface with it.
[…]
It may seem like overkill to have an Objective-C shim for a Swift wrapper around an Objective-C type, but remember this is all a means to an end. If we’re making good progress on our language transition then we’re deleting shims as fast as we’re creating them.
Steve makes a great point here. Swift shines brightest at the model layer, where its strong types help you architect a better foundation for the whole app.
Adding some Swift views on top of Obj-C and then working your way down won’t get you there.
I concur. Writing Swift on top of an Objective-C base is not a great experience and doesn’t provide a lot of benefit. But substituting in a Swift base is non-trival because most of the features can’t be used from Objective-C. Even sticking with reference types, you can’t subclass a Swift class from Objective-C. Hence the need for techniques like Barnegren mentions if you can’t rewrite everthing at once.
Update (2022-01-17): Steve Troughton-Smith:
A lot to unpack here, but yes, your Cocoa-oriented data model is absolutely gonna be the worst and most frustrating point of transitioning to Swift. It just doesn’t fit the way everything else works, and forces you into way more potentially-problematic boilerplate than you want
3 Comments RSS · Twitter
My approach is to just stick with Objective-C until it's no longer usable, then just abandon Apple-specific frameworks in favour of Electron or similar.
@bob Same here. ObjC still feels great to me. Rewriting working Objective-C code in Swift feels like a waste of time. What's the benefit? Longer compile times? Inferior compiler warnings/errors?
I've got nothing against Swift, it looks like fun with lots of interesting ideas, but ObjC is still fun for me also. I've got 200k lines of code all in ObjC that took a decade to write and debug (so far), there's no way I can rewrite all that. Also my app is very tightly integrated with AppKit, which last I checked is still very ObjC oriented. This interesting article just reinforces my decision to continue using pure ObjC code. And I do enjoy the fast compile times and not having to worry much about tooling.
