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. Value types, generics, enums with associated values, optionals. It’s possible, but if that’s your plan then you really don’t need a 4K TV anyway.Įverything that’s great about Swift has to be sacrificed for Objective-C interoperability. Swift and Objective-C are interoperable in the same way that you can plug a VHS player into your 4K TV. Swift and Objective-C are interoperable, right? 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. A year down the line we still had a mostly Objective-C code base. It was difficult to gracefully integrate new Swift code into existing Objective-C classes and systems. I can tell you that it didn’t move the needle very much. This is probably most teams’ initial idea, and it was ours too. Surely, then, over time there will be more Swift code and less Objective-C.

The naive approach is to simply decide to write all new code in Swift. It was large enough that a full rewrite from the ground up in Swift would take years and was out of the question. If you work at Netflix then it probably looks pretty small! It’s all relative, but if you work on an app with 2 or 3 developers then it probably looks monstrous.

Objective c to swift migration