When to Move to Swift
Despite this newfound revelation, I still think the prudent choice is to continue writing apps in Objective-C. Those who are fully on board with Swift commonly reply: every line of Objective-C you write is a legacy. While this is true, Objective-C code will still be viable for at least another five years, and probably won’t stop working for closer to 10 or 15. This is based the fact that every one of Apple’s OSes is written in it, as well as the frameworks themselves. (How long did Carbon code work for? How long before Finder was rewritten in Cocoa?)
However, your Swift 2.2 project is also going to become legacy code, and that transition will happen this September. Your migration will be a bloodbath, and it will have to happen in one fell swoop (including your dependencies!) because of a lack of ABI compatibility. Latent bugs will creep in from the migrator, and you’ll have to keep your
swift-3branch updated with regular, messy merges. In the end,git bisectwill stop working, and your compile times will still be awful.
Ben Sandofsky (via John Gruber):
I strongly believe Swift is the future of iOS development. It’s only a matter of when, and the blocker is the breakneck speed it evolves. For smaller apps, Swift is good enough. For big apps, it’s at least a year away.
I’m using “big” as shorthand for a few different categories. It can mean lines of code, number of developers, complexity, or low-tolerance for problems.
There are pros and cons to both paths. Personally, I lean towards using Swift for new projects and new major versions. I am less worried about the breaking sources changes in Swift 3 than I am about the poor Xcode experience (broken auto-indentation and unreliable syntax highlighting, code completion, and symbol lookups). Nearly two years after the initial release, I thought those would have been fixed.
Previously: ABI Stability Deferred Until After Swift 3.0.
Update (2016-06-01): Bridger Maxwell posted a diff of his app’s changes for Swift 3 (via Soroush Khanlou).
