April 22nd 2015 Swift Makes Programming Easy!
When Swift was announced last June, I noticed a curious reaction: Many people posted that they now planned to write a native app, since Swift made writing native apps easier. It’s a sentiment I still see expressed from time to time on programming forums, and every time it surprises me, since I have long found that it was not Objective-C that made writing iOS and OS X programs “difficult”; rather, the complexity of writing applications for those platforms lies in the platform itself. After spending ten months working with Swift and writing a book, it seems like a reasonable time to express my thoughts on the subject: Does Swift making programming easier?
Objective-C, iOS, and OS X
Objective-C itself is not a terribly complex or difficult language. It is little more than a veneer on top of C, and adds only a few capabilities to C. Objective-C introduces classes, protocols, categories, and a runtime that can deal with dynamic method dispatch and supports object and class introspection…and that’s about it. The Objective-C language itself is very simple and can probably be learned in a few weekends of study.
The difficult parts of Objective-C are the frameworks that comprise iOS and OS X. The core frameworks, Foundation and AppKit, are broad. Foundation introduces a class hierarchy rooted at
NSObject (or, more rarely,
NSProxy), as well as the memory management system in the form of the
autorelease methods. AppKit and UIKit introduce an entire library of UI components designed around an MVC paradigm, and require programmers to have at least a basic understand of the event loops utilized by both iOS and OS X. Many frameworks also make extensive use of key-value observing and Cocoa bindings, which are not a core part of Objective-C but are central to writing software on Apple’s platforms.
That’s a lot of stuff to learn, and it doesn’t stop there. Modern Mac applications make use of Core Data and an array of other commonly-used system frameworks, not to mention the plethora of great open-source frameworks available now. iOS apps often use even more frameworks, such as Core Location, as well as open-source frameworks like AFNetworking. AppKit and UIKit differ enough that programmers writing both Mac and iOS applications will have to learn both to be effective across both platforms. Users’ expectations of UX are high enough that programmers will have to learn about the various animation frameworks and techniques used on iOS and OS X. Increasingly networked applications require that iOS and OS X programmers learn about the various concurrency and IPC mechanisms available to them as well (which obviously means they are required to have a general understanding of concurrency and its pitfalls, too). And, of course, there’s Cocoa Auto Layout, which didn’t even exist ten years ago (we had the relatively simpler—and relatively less flexible—system of springs and struts).
When I compare the iOS and OS X development landscapes to those of ten years ago, it’s enough to make my head spin.
Does Swift actually make iOS and OS X programming easier? Will programmers choose to write native apps instead of cross-platform web views because of Swift?
It’s hard to ignore the notion that even though Swift may be easier to learn than Objective-C, Swift programming still requires extensive knowledge of iOS and OS X frameworks—and those are not made significantly easier to master by a more modern development language, especially since they were still designed and developed with Objective-C in mind.
Furthermore, Swift is not necessarily an easier language to learn than Objective-C. It may even be harder, because, in comparison to Objective-C, it has far more features. Syntactically, it looks nicer, but beneath its shiny surface lurks a lot of features that are great for advanced programmers, but not easier for newcomers to understand or master.
One example is Swift’s compound data types. Whereas Objective-C only introduces classes, Swift features classes, structs, and enums. Each can contain methods, and the difference between classes and structs is nuanced. (Objective-C has structs as well, inherited from C, but the difference between structs and classes in Objective-C is much more clear.)
And while Swift offers much superior type safety as compared to Objective-C, that type safety comes at the cost of simplicity. Optional types are a much appreciated addition that will leader to safer code, but they are harder to understand than Objective-C’s
nil, especially when working with Objective-C code. Swift’s type system adds a couple more wrinkles: Type casting is at least different, if not more complicated, than casting in Objective-C, and generics, while safer than Objective-C’s dynamic typing, are also an advanced feature that may be unfamiliar to those used to dynamically-typed languages.
Some of these things will be familiar even to newcomers. Subscriptable classes, for example, are featured in many other languages such as Python and Ruby. Other features, like custom operators, will no doubt be as controversial as techniques like method swizzling and class posing in Objective-C.
Is Swift Easier?
I’m not convinced, however, that it will succeed in luring programmers who avoided iOS (and OS X) because they thought that Objective-C was hard. Swift may appear to be easier to learn than Objective-C, but it actually packs a lot of features, both elementary and advanced, that make it harder and more time-consuming to learn than Objective-C. On top of that, the real challenge in writing software on both iOS and OS X is in learning all the frameworks and libraries used on those platforms. And because both platforms, as well as most third-party frameworks and libraries, are implemented mostly in C or Objective-C, Swift programmers not only have to learn Swift, but also must have at least a basic understanding of C and Objective-C.