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 retain, release, and 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.

Swift

No doubt one of the unspoken goals of Swift was to encourage programmers to write native applications. Apple makes its money from hardware; Apple would prefer programmers write applications that are exclusive, or at least unique, to iPhones and Macs. With the proliferation of Android devices, however, as well as a generation of developers who have grown up on web apps, many mobile apps are becoming little more than web views built with HTML, CSS, and JavaScript. This is due in part to the fact that such applications are trivially cross-platform, but the rise of mobile web apps can also be attributed to the fact that JavaScript is a comparatively easy language to learn (and, like PHP in the late 1990s and early 200s, many young developers cut their teeth on JavaScript).

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.)

Swift also introduces new capabilities for properties, such as computed and lazy properties and property observers. It also has new capabilities for classes, such as subscripts and custom operators.

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?

Let me be clear: I do not mean to say that any of Swift’s features are impossible for new programmers or those steeped in JavaScript (or other languages like Python or Ruby) to understand. I have no doubt that interested programmers will be able to grasp Swift’s more advanced features, and I certainly don’t mean to say that Swift’s development was a waste. Swift offers a lot of great features for new and seasoned iOS and OS X programmers alike.

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.

I’ve long been a fan of native apps (I’ve never liked running “applications” across a few dozen browser tabs, and as far as writing software goes, I’m no fan of JavaScript), but it will be interesting to see if Swift lures those who planned to write a mobile web app towards native app development instead.