We’ve just gone live with OTTO – a campus companion for students – and it’s written entirely in Swift. As with any new technology, it can be a difficult to decide when is the right time to abandon the old and start using the new, or if that’s even the right decision at all, but we are indeed all-in on Swift, right now. Here’s a few of the things that factored into our decision.
Swift is the future
When Apple first revealed Swift at its annual developer conference in June 2014, it was a surprise to almost everyone, including most Apple employees. The feeling was largely one of intrigue, coupled tightly with uncertainty – would this new language take off, or would it just be a flash in the pan? For most, it made no sense to start writing commercial code in Swift when the future of the language was still unknown. Despite this, many adopted it anyway. Fast forward to WWDC 2015, and the message from Apple is clear. Almost every bit of code demonstrated at the conference was written in Swift, and in fact, one of the only times Objective-C was seen was during a session on tracking down hard to find bugs. Pointedly, the bug being demonstrated was a bug that isn’t possible in Swift.
If you need further proof of Apple’s commitment to Swift, you only need to look at the improvements made to both Swift and Objective-C in the last year. Swift has already moved from version 1.0 to 2.1, bringing a huge number of features and improvements that make developers lives easier. Objective-C has seen a few improvements too, but in every case these improvements only serve to make it easier to write Swift code. In other words, Objective-C is essentially at a standstill.
Finally, if you still need more convincing, Apple recently made Swift open-source. They’ve provided a full road-map of their plans for future development, and they’re openly encouraging input and suggestions from the community. As Software Engineering SVP Craig Federighi said, Apple thinks Swift is “how really everyone should be programming for the next 20 years”.
Committing to Swift doesn’t have to mean abandoning Objective-C
Mix and Match is the ability to have Objective-C and Swift in the same project, and it means there’s no good reason not to start using Swift today. Apple makes it incredibly easy to have some code written in Objective-C, and some other code written in Swift, and they’ll both get along just fine. Worried about converting all your legacy code to Swift? The beauty is that you don’t have to. If you have an existing Objective-C project, you can simply leave it all in place, and write any new features in Swift. Or convert some of it, and leave the more complex parts in place. It’s up to you.
That said, we chose to move everything to Swift. OTTO, a collaboration and campus companion for students, is small enough that the process wasn’t an exhaustive one. Embark on the other hand, a global transportation utility, is still in early days of development which made the conversion to Swift relatively convenient. In both examples, it gave us a chance to clean house – code always builds up over time, so we took the opportunity to remove anything that was no longer required, resulting in a leaner, cleaner codebase. The other primary reason for going down this path was to save on context switching. Swift and Objective-C are similar in some ways, but very different in others. Writing code can be difficult enough at times, and we didn’t want the extra burden of handling code written in two languages at once.
Built on a solid foundation
For any developer well versed in Objective-C, Swift feels pretty familiar. This is because all the frameworks and technologies that make Apple platforms so great are still available. Everything that powers iOS and OS X apps today works just fine with Swift (better even). This means developers new to Swift can focus purely on learning the syntax and language features, and still be productive right from the start. The only thing you’ll lose by switching to Swift is the time required to learn the language.
Just a small number of Apple’s frameworks, tools and resources
Less code, less bugs
Objective-C has a unique and unusual syntax, which at times can be convoluted and unnecessarily complex. Whilst it would be a bit harsh to say Objective-C feels like something out of the 1980s, it certainly doesn’t feel modern. Swift has a clean, concise, elegant syntax, and it feels like a modern language. Swift also does away with something called header files, which means the number of files required for a project typically halves with Swift. Swift also requires less code to be written in general, which is always a good thing. The less code there is in a project, the less chance there is for bugs.
Swift Playgrounds are a really neat concept. Under normal circumstances, creating a new feature in your app means adding some files, writing some code, compiling your project, and running your app – over and over again, until the feature is working. Using a Playground, developers can type some code on the left hand side, and instantly see the results on the right. These results can include complicated formula output, images, and even animations. Being able to see these results instantly means significantly faster iteration, and can save many hours of work. Whilst Playgrounds aren’t always suitable, when they are are they really shine.
Apple loves to deprecate
iOS, OS X, watchOS and tvOS apps can all be written in Objective-C, if you want. But will that be true for the next Apple product? Apple is notorious for deprecating old technology, and while Objective-C will be around for many years to come, I wouldn’t be surprised if the next product category Apple enters is one that can only be developed for with Swift.
Swift is the future
It’s the point we started on and we think it’s an apt one to finish on. We here at Contact Light believe Swift is here to stay. If you’re still waiting to see how Swift matures, don’t, you’re only delaying the inevitable. The right time to start migrating your apps to Swift is now. Indeed, productivity might take a small a speed bump now as developers get comfortable with the language, but you’re doing yourself a disservice in the longterm by writing any more Objective-C.