Every June, anyone involved in the software world celebrates the ‘Apple New Year’ — the World Wide Developer Conference. WWDC.
It is, of course, a time for celebration. Applications that were once impossible become possible. Improvements to existing tools make the software development process a bit easier.
This year delivered something bigger than usual — they introduced the new programming language Swift for developing iOS and Mac OS X software. This event will impact anyone with a relationship to software on Apple’s computers and devices. (Which is you.)
So, you might be wondering, how does this new language impact you as a developer? How will it impact your business? Do you have to rewrite your existing iOS applications? What about starting a new application? Are you in the middle of writing an Objective-C iOS application and wonder if you need to switch to Swift?
Some History
In all likelihood, Objective-C will be a primary language for writing iOS and Mac OS X apps for awhile. As of today, you could start writing an application in Objective-C (instead of Swift), and you’ll be OK. If you’re currently developing an application in Objective-C, you’ll also be OK. If you’re maintaining an Objective-C application, yes, you are still okay.
But ‘awhile’ is finite.
Based on previous behavior, an iOS and Mac OS X developer will use Objective-C less and less as time goes on.
It wasn’t that long ago that Mac OS X Cocoa applications could be written in either Objective-C or Java. Slowly, but surely, new features became available in Objective-C that weren’t available in Java. Then, unceremoniously, Java was dropped as a supported language for Cocoa applications.
Java lasted about 6 years for Cocoa applications. The writing was on the wall most of that time. You could argue that Swift and Objective-C are in a very similar situation as Objective-C and Java once were.
It also wasn’t that long ago that Apple made the jump from Mac OS 9 to Mac OS X. Compared to this last week’s change, OS 9 to OS X was a catastrophic jump – a new language AND a new SDK. If you were a Mac developer at that time, your entire skillset was effectively made obsolete.
Mac OS 9 stuck around for a few years. Apple also went to great lengths to allow applications written for Mac OS 9 to run in Mac OS X — either in the Classic emulation environment or ported via the Carbon API. This was largely to support major vendors like Adobe, who had massive codebases and whose applications were vital to Apple’s business, from having to ‘start over’.
There are similarities between that event and last week’s Swift announcement, too.
There are parts of UIKit and AppKit that just aren’t Swift-like, like key value coding and selector based target-action pairs. Something like NSManagedObject seems difficult or impossible to write in Swift. So, there are clearly hugely important pieces of Cocoa that rely on Objective-C. In fact, Swift is really built on top of Objective-C, somewhat similar to how Objective-C is built on top of C, and somewhat similar to how C is built on top of assembly.
But, this was the case fourteen years ago, too. There were certain features that were available through Carbon, but not Cocoa. It was expected that you used pieces of Carbon in your Cocoa applications if you required such a feature. Even today, you can write an application entirely in Objective-C, yet, plenty of your code is eventually calling C++ code (this is the case for Core Animation).
Perhaps we will still write some libraries in Objective-C, since we still write some libraries in C++ and C. Perhaps Swift will find better ways of doing things that we love in Objective-C. No one can say for sure at this point.
Learning from History
As all of Cocoa and Cocoa Touch are still written in Objective-C (and Swift relies on the Objective-C runtime), we still will need to write Objective-C code or at least call into it. (Set a breakpoint in a Swift method of a view controller – you’ll see three or four different programming languages in the stack trace!)
But, we spend the majority of our time writing Objective-C code now, even though we can write code in C++ or C. I think that we will eventually write the majority of our application-level code in Swift. If you believe that, then at some point, you’ll need to switch to Swift.
Thus, figuring out when to switch largely becomes a business decision. No one in the world has experience as a Swift developer. If you are starting a new project, you are hiring people who are still learning. That’s not that big of a deal, because an iOS programmer will already understand Cocoa and Cocoa Touch. Calling into those SDKs with a different language is somewhere on the scale between trivial and challenging, but nowhere near difficult.
Switching then, isn’t all that scary from a business perspective. The net impact will be a slower development process in the first few months. After that, the process will approach normal. If everything goes as planned, developing software in Swift will eventually become faster than developing software with Objective-C.
If you are in the ‘new project’ phase, and aren’t on a crazy schedule — which, let’s face it, isn’t always the case — going with Swift is a good choice. Your team will learn something that will most likely be valuable longer into the future. This is good for your team, but it is also good for the project. It is likely that new features will be communicated in Swift code samples and new API might utilize features only available in Swift.
If you are in the middle of the project or are maintaining an existing project, the cost to either transition your codebase over to Swift or bridge your existing codebase with new Swift code probably isn’t worth it.
Swift and Objective-C target the same runtimes, but Objective-C is much more mature. There are pieces of Swift that are currently missing and have already been promised by Apple (like access modifiers). There are sets of problems that currently have a better solution in Objective-C. But make no mistake, Swift will evolve to address those problems. It wasn’t that long ago that we were writing accessors by hand and didn’t have blocks in Objective-C, and look where we are now.
Also, let’s face it, not many applications are going to make it five years. (Which is apparently the number I’ve come to in my head for when Objective-C begins its death march.) Is it worth it to spend the extra time and resources on something that doesn’t need to be maintained when Swift becomes the standard for application-level code? Probably not.
So, it all boils down to when you want to spend time and money. Use Swift, pay more up front, pay less in the long run. Use Objective-C to pay less up front and pay for it down the road.
Swift Reactions in a Fast-Paced World
In today’s world, word travels fast.
There will be well-articulated thoughts across every tech media site on the ‘mistakes’ that Apple is making: ‘Apple’s New Programming Language Dooms Company’, ‘Would Steve allow this?’ and ‘iOS Developer Switches to Android Only Because of Swift’.
There will be cogent points on Hacker News that describe the pros and cons of Swift vs. Objective-C as programming languages, full of programming language theory, but very little thought towards the grander context.
There will be arguments about how Swift is currently closed source that descend into batshit crazy on Twitter.
Well, actually, these things are already happening.
Some perspective is in order, though.
If you look hard enough, you can find archived mailing lists during the previously mentioned periods of change in the Apple developer world. The message from those historical archives is clear: this change, like all changes, will be met with a wide array of reactions and then we will collectively move on and no one will care anymore.
I guarantee you will find popular Objective-C developers today that were complaining about something years ago. My younger self included.
Change is change, no matter what facet of life. We’re in an industry where change is rapid and inevitable. There hasn’t been enough time to evaluate Swift. That will take years. Swift will improve during that time.
Don’t hitch your wagon to anyone with a strong opinion on something that has existed for less than a week. Their reactions at this point are a projection of their confidence as a developer, not an indication of Swift’s value – no matter how many fancy computer science terms they use or how great their public contributions to iOS developers have been.
For example, right now, there are two big ‘Swift is terrible compared to Objective-C’ arguments going on. (There will be more.) First, the behavior of arrays when passing them to other functions. If you are in the pitchfork business, you better ramp up production for this one. The other item is the lack of dynamic messaging in Swift that enables developers to conjure up a method call at runtime that may not be known at compile-time.
Some folks are absolutely livid about these items. These threads on the Apple Developer Forums look a lot like YouTube comments.
There will be solutions to these problems. Or, they may not even be problems, as we will develop new patterns around new behavior. There might be even more elegant solutions available in the future. You’ll have to be patient. In the meantime, if you are looking to be successful, it is in your best interest to ignore anyone that is beating Swift up. Keep an eye out for Swift improvements that will give you the ability to do new and great things. File feature requests through Apple’s bug tracking portal (not their forums) for things that you want to see.
Some Things You Can Do
- Read the programing guide on iBooks.
- Start writing code by adapting the Big Nerd Ranch Guide‘s solutions to Swift.
- Find a piece of code you use frequently – like a special class that you import into every project – and figure out how to write it in Swift. Find a better way to write it utilizing Swift’s new features.
- Screw up a few times. Do something you know doesn’t work, try and make it work. Let the compiler teach you what things are wrong. Page through the Apple Swift Language Programming Guide’s list of keywords to see if anything guides your understanding. Try out some of those weird keywords.
Remember: Chaos isn’t a pit, chaos is a ladder.
