Feet in Both Worlds: From Objective-C to Swift
This morning we’re gonna talk about Objective-C and Swift interop. We’re gonna talk about it really from two perspectives. We’re gonna talk about it from a theoretical perspective, that of language design. […] And then we’re gonna talk about what it was like for us to take a […] 20,000 to 30,000 line Objective-C app, and start adding 20,000 to 30,000 lines of Swift to it, and to add those lines in a very Swifty style.
Interoperability makes it possible to integrate [Swift] features back into Objective-C code with no hassle […] without having to rewrite the entire app in Swift at once.
This is a quote from the Swift book, this is a lie from the Swift book. It’s a nice lie. I mean, it’s kind of true. It’s kind of true if you write bad Swift. But then, it’s basically just syntax sugar versus Objective-C, which is nice, but which is maybe not worth the complexity. […] Okay, so we had this plan, because the Swift book told us this thing, and we believed it. And we embarked about 13 months ago on a large project, we being Khan Academy, to write a large product in Swift, large existing code based, running a large new product.
It was not great, it was emphatically not great. So along the way, we were constantly forced to rewrite large swathes of our app in Swift as we went, or we were forced to decide not to use Swifty idioms and semantics, which is not a decision that we really enjoyed having to make. I think it’s fine. I’m not saying, “Oh, you shouldn’t use Swift in existing apps.” But what I am saying is, “You should add a lot of padding to your estimates.” ‘Cause it slowed everything down a lot, for months. Many, many, many months. And so there’s people out there who are just saying “Well, screw it. I’m just gonna rewrite the whole thing in Swift.” I don’t know, that might have been a better strategy. Transliterating Objective-C to Swift is pretty easy.
This is a conference talk from November 2015, before Swift 2.2 and Swift 3, but a lot of the issues still apply.
