I began learning Swift shortly after its surprise introduction at the WWDC 2014, but last week marked the first time it was put to accomplishing my App development goals. Swift is new programming language, created by Apple, for building applications for OSX, iOS, and WatchOS. It is appealing because it has the capabilities and feel that developers expect from a modern language, and for many it was a breath of fresh air in comparison to Objective-C, the defacto option of the time.
Many developers learning to build iOS applications struggled with Objective-C because of its unusual syntax. It is a blend of the familiar C syntax with a uniquely different and awkward syntax used for working with objects. Like C++, Objective-C is a superset of C, so I like thinking of it as a C++ implementation that came from a bizarre parallel universe. After years of experience working with Objective-C, I’m still not as efficient at reading it as I am with C#, Java, and C++. That said, it is unfair to write the language off because of its syntactical peculiarities. It has an excellent library of well-designed APIs and its object paradigm is arguably cleaner in some ways than the C++ approach. Objective-C’s utilization of selectors over traditional method calls also offers flexibility not readily available in C or C++. In all, I found it to be a productive language despite its short comings.
Now that there is an alternative, what is the drive for a developer, like myself, to switch after an already considerable investment into developing Apps with Objective-C? Well, for one thing it adds modern language features that were not available in Objective-C, like generics. It seems to have borrowed heavily from other contemporary languages, like C#, and introduced new concepts of its own which makes it a more expressive and productive. In addition, Apple claims there are substantial performance benefits. The performance of Objective-C is adequate for most purposes, but greater efficiency can also lead to reduced power consumption and positively influence battery life.
My first Swift project was an experiment to see how quickly I could rewrite Keep Time’s timing code. Swift and Objective-C are fully interoperable to the point where both languages can coexist together within the same project, which enables developers to utilize Swift to add on to existing Objective-C projects, or to gradually rewrite entire applications one class at a time. My experience was a favorable one and working with the language was actually enjoyable because it eliminates all of the cruft that Objective-C inherited from C. I also appreciated that the syntax is far less tedious, which means more energy was directed at solving problems and less was spent on figuring out how to express myself in the language. One thing is clear, Swift’s designers are not afraid to challenge long established conventions. For example, it was surprising to discover there is no concept of a protected accessibility modifier. Working with a language that challenges established notions sometimes feels frustrating; however, it is provoking me to rethink my approach to software design and it is through experiences like these that developers hone their craft and produce ever more elegant and maintainable code.