We have used Swift on a few of our projects but we haven’t fully adopted it yet. Until very recently the language and tools appeared to be changing rapidly, and that gave us pause. We put a quality experience for our clients and their end users at the forefront of our values, so we won’t adopt a new technology unless it provides significant benefit.
And when we saw posts by early adopters – including ones here, here and here – we delayed switching until we saw more stability. But we were not so blind to the coming reality of a Swift-only world, as you can see in our earlier discussion about Swift.
With Swift 4.x set to be released in 2017, we were unhappy to see yet more breaking changes, namely in the way Strings are handled. Strings are of course a fundamental building block of any application from an end-user perspective, so it is a rather large breaking change in our view. But overall, we see nowhere near the breaking changes that we saw in previous releases. In earlier versions, the changes were at times large enough that you might well have done a complete or even total rewrite of your app. That re-write can easily introduce bugs and will certainly add to your development costs, increasing costs and delaying schedule on a project with little added value to the end user experience. We didn’t want our customers with hundreds of thousands of users to take on the burden of those growing pains simply because we wanted to play with shiny new toys. But that time of waiting is drawing to a close for Push.
We haven’t picked a day yet but the “Switch to Swift” will come soon and it will be total. A Mac OS X developer who used to program in Carbon (a legacy Mac development system) and saw it slowly give way to the new Cocoa system once told me: “it was better off to abandon Carbon completely and move wholesale over to Cocoa, rather than trying to hang on to Carbon beyond the initial stages.” We have the same view when it comes to Swift versus Objective-C. We have many projects written in Objective-C and have no plans to rewrite those programs in Swift right away. But in the not so distant future all our new development will be in Swift and Objective-C will be relegated to legacy maintenance work.
If your team hasn’t switched to Swift yet then you, too, may have avoided unnecessary pain. But you won’t be able to put it off much longer, lest you be left behind. One of the biggest hits – aside from a dwindling Objective-C community – will be due to maintenance costs increasing on any projects you plan to keep updating regularly without transitioning to Swift. Before long, Objective-C will be a second class citizen to Apple and will not receive the same support and bug fixes that Swift will receive. At that point bug fixes for Swift may not be “back ported” to Objective-C because Apple could instead use that development time to build new features in Swift. And when that time comes, Objective-C will become an anchor you will furiously try to free yourself of.
