To Swift and Back Again
This article could have been about how we converted our current project to Swift, then eventually had to convert 15k lines of Swift back to Objective-C again. But it’s not going tell that story. – The main reasons are outlined in this article anyway: by Swift 1.0, compile times for a project like ours was exceeding a minute and for editing, Xcode 6.0 was thoroughly broken. With no known date when this would be fixed there wasn’t really much of a choice.
No, this article is going to talk the experience of taking the project to Swift and then back to Objective-C – what was better in Swift and what improved going back to Objective-C.
[…]
The worst part was working with dynamic data structures. This was simply not practical to do in Swift. The best way here turned out to be converting all the dynamic data to classes and structs.
[…]
Aside from that issue, Swift has traditionally been very inconsistent in how and when to inline code. Tiny changes can sometimes grant magnitudes of faster code in a quite unpredictable manner. Swift runtime performance is really a mixed bag. From C performance to something speeds that even Java 1.0.2 would be deeply ashamed of.
It’s not the speed itself that’s the problem, but rather the unpredictability. And yes, this will improve – but when will it be solid enough to rely on? Objective-C is not fastest, but it’s guaranteed to perform exactly the same no matter how the other library is linked.
