Qvik <3 Swift Anniversary
We fell for Apple’s new programming language Swift at first glance. It was so beautiful and elegant that we felt like getting involved ASAP. Here’s a more or less honest blog post about what our first year together has been like.
Since being announced in WWDC 2014, Apple’s programming language of choice Swift has caused ripples in the pond of iOS developers. While some seemed annoyed at having to learn new things, most were excited about the clean and elegant, yet expressive syntax of the new language – and this was certainly the case here at Qvik.
Compared to our previous hook-ups Swift was a real good-looker. And hey, if one is forced to use a proprietary language for one’s software development for a single platform – and even if this is changing rapidly after Apple open sourced Swift in December 2015 – it really doesn’t hurt to have a beautiful language for doing so instead of a total eyesore. Yes, I’m looking at you, Objective-C!
We had been messing about with Swift few months before we were really ready to make a big commitment – we wanted to know our new partner before getting too serious. But in Spring of 2015 we made the big decision to switch to Swift as our main iOS development language. At the time it was still in version 1.2, lacking several crucial features such as proper error handling and defer, but we were willing to overlook that.
Compiling and autocompleting Swift code took noticeably longer than Objective-C, but as the development speed was considerably faster than Objective-C, this more than made up for any shortcomings. With Swift 2.0, the missing language features are there, autocompletion seems faster, and even the infamous Interface Builder Storyboard editor appears faster. Yay! Xcode crashes/freezes/bugs out more often than ever and the Swift compiler error messages are still a mess, but all in all things are definitely getting better.
The Swift language borrows many powerful features from existing languages; type inference from functional languages, C++’s auto keyword, lambdas/closures from languages such as Lisp and Python, tuples from Python, the ‘defer’ construct mimicking C++’s unique_ptr, Java’s ‘finally’, and so on.
Optionals are a clever way of forcing null checking, and having the ‘if let’ / ‘guard let’
statements make using them a breeze. It is very rare that I notice running into a null crash at runtime thanks to the Optionals’ way of forcing the programmer to manage nulls. Also, integration with any existing legacy Objective-C code is a cakewalk, making it possible to port existing projects to Swift piece by piece.
Objective-C will more than likely always hold some footing in iOS development after all; while it is possible to integrate with C APIs from Swift, the same doesn’t hold for C++, and you really do not want to do it with C either. In other words, we’re bound to see Objective-C wrapper classes that encapsulate integrations to native APIs.
With already several pure Swift projects on their way at Qvik, things are looking very good for us iOS developers. Also, with the tvOS and WatchKit SDKs, Apple development is diversifying and hopefully the industry will pick up on the new things quickly – so that we’d get the chance to really get cracking on them sooner.
During this first year together our relationship with Swift has become much stronger and more mature. Swift has grown to be a better partner, which is great because we know Swift will just keep getting better all the time.
Looking forward to our good times yet to come!
P.S. Sharing is caring so if you’re interested, here’s links to Qvik’s open-sourced Swift libraries.
• https://github.com/qvik/qvik-swift-ios
• https://github.com/qvik/qvik-network-ios
• https://github.com/qvik/qvik-cloudinary-ios
