The promise of Swift looks great. Faster performance¹, better error handling, and better compile-time bug detection sound like very welcome additions to the iOS/OS X development ecosystem. The thing is, though, there are problems, problems that make it impractical to put time into mastering the language.

Swift is being actively developed as a language, so much so that Apple is making changes to it that often break existing code. I believe this is necessary in the early stages of the language to avoid the significant cruft that can accumulate by maintaining backwards compatibility, but I can’t afford to regularly rewrite existing code because something in the language changed. Until the language reaches a stability point where existing syntax can be reasonably guaranteed to still be the same in the near future, I believe it wasteful to use it in a production environment where that time could be put to better use enhancing the product.

Swift’s immaturity also shows in its design. Many patterns we’ve embraced in object oriented programming have not yet made it into Swift. For example, objects in an array conforming to a child protocol cannot be indirectly cast as conforming to the parent protocol. Instead, the workaround requires fully copying the source array and doing an explicit cast in a map. Things like this add up. To be most productive it’s important that the language get out of the developer’s way – proven design patterns should be supported without having to resort to programming a workaround.

Ultimately I believe Swift will mature and meet its promise, but I don’t know when that will be. I have no special attachment to Objective-C – it’s just the best tool for the job currently. Until Swift can dethrone Objective-C, I’ll stick with it.