April 17, 2015 // By Magenic
As surprising as many of the WWDC 2014 announcements were, Apple completely blindsided the I.T. industry with the announcement of Swift. Swift is a completely new and modern programming language that is intended (and destined) to replace Objective-C as the default language for iOS and OS X programming.
Why Swift, why now?
Before talking about Swift, let’s talk about what developers use today to program for Apple’s OSes: Objective-C. Although C, C++, and Objective-C are all first-class citizens of the iOS and OS X operating systems, Objective-C is typically used to develop apps because it is kinder and gentler to developers (especially since the advent of ARC for automated memory management), and Apple’s high-level frameworks are written in it. (C and C++ are used more for operating system-level code, such as device drivers, base-level frameworks, and real-time programming needs.)
Objective-C is not proprietary to Apple, but it is often associated with Apple because iOS and OS X are the only popular operating systems that use it so extensively. Objective-C came to Apple via the NeXT acquisition that brought Steve Jobs back to the company. NeXTStep, NeXT's operating system, became the foundation for OS X and iOS. In addition, Xcode, the development environment for Apple's OSes, is a direct descendant of NeXTStep's developer tools.
Objective-C was innovative and powerful and easy to use in the early 1990's, but many languages today provide an even kinder and more productive environment for developers. While Objective-C is a strict superset of C, it could be difficult for developers from other platforms and languages to quickly pick up Objective-C.
To move forward, Apple wanted a new language that was 100% compatible with the existing Objective-C frameworks on iOS and OS X, but that took on many of the innovative features of languages created in the past 20 years. Computers are far more powerful, so languages and compilers can do more of the dirty work for developers.
Let’s be absolutely clear: Swift is not a ‘lite’ version of Objective-C.
Swift is a complete replacement for Objective-C. From what I’ve read so far, Swift can be used any place that Objective-C is. Swift is not meant to be a simpler version of Objective-C, but rather a plug-in replacement for it.
Swift is also not a performance-degraded version of Objective-C. Apple showed some impressive performance results of Swift at WWDC, where it even outperformed Objective-C in some tests. Of course, I have no doubt that Apple cherry-picked those results, and only time will tell what the real performance characteristics are. It certainly seems like Apple is attempting to make Swift have performance characteristics at least as good as Objective-C. So no worries there.
Another item of note: Swift is compiled to native ARM or Intel code, just like Objective-C. And it uses the same ARC (automatic reference counting) that Objective-C uses, instead of a garbage collector. This efficiency has allowed Apple to ship iOS devices with half the RAM of equivalent Android and Windows Phone devices, and still have excellent performance. So Swift does not negatively affect this in any way.
I won’t cover Swift’s features, because that’s been done in the excellent Swift Programming Language available for free in the iBooks Store and in PDF format from Apple’s developer web site. Swift has been influenced by other languages such as Objective-C, Rust, Haskell, Ruby, Python, and C#.
I will say that Swift has one neat feature that is missing from other mainstream platform languages like C# and Java: Playgrounds.
Playgrounds are a great learning tool for beginning and advanced developers alike. A playground doesn’t become part of a shipping app, but rather is a source code window where you can enter code and have it compiled and run in realtime. But it’s more than just logging text into a window. You can inspect objects with a click, inspect and play loaded multimedia files, and even see the results of drawing routines.
On top of that, it has a timeline where you can view your drawing and animations, and scrub the view back and forth in time to see how your code plays out. You can then cut-and-paste your completed-and-tested code from your playground and put it in your Swift source files.
Pretty amazing stuff. Swift is certainly not the first language/environment to do this, but it’s the first mainstream one to do so. I expect Microsoft and Google to respond to playgrounds soon enough.
Using Swift Today
You can mix Swift and Objective-C in the same Xcode project. You cannot, of course, mix Swift and Objective-C in the same source code file. But you can have Swift and Objective-C source code files freely mixed within a project, app, or framework.
Xcode 6 will auto generate Objective-C headers from your Swift source code (just build the project to make sure they’re created) so that you can import those headers into your Objective-C source files and use your Swift classes as if they were Objective-C.
Likewise, Xcode 6 will prompt you to create a “bridging header” so that you can use your Objective-C code in your Swift classes. This is something you update manually, so you control what is visible and what isn’t.
One neat thing about Swift and Objective-C interoperability is that it keeps the idioms of each language. For example, if you create an initializer in an Objective-C class like this:
then in Swift it will appear as:
which is how Swift uses initializers. All of this is automatic and done by Xcode for you.
Surprisingly, Swift apps can be deployed on not only iOS 8 and OS X 10.10, but also one version back (iOS 7 and OS X 10.9). So developers can start learning Swift today and create apps that are compatibly with one OS version back.
How Swift Affects the I.T. Industry Today
Swift is going to have a huge impact on the I.T. industry. Most enterprises have some sort of mobility initiative, and at some level that involved iOS devices and Objective-C. Even if you package custom apps as HTML in PhoneGap, a custom plugin is developed in native code.
Let’s face it: Objective-C developers are hard to find and expensive. The language has a high initial learning curve for C# and Java developers, although I’d argue it’s fine once you get over that hump. It’s just that many developers are not willing to get over that hump.
Swift is not only more modern and productive than Objective-C, it’s much easier to learn for developers coming from other platforms. And playgrounds make learning fun and easy.
What is the enterprise to do with native apps (or plugins) written in Objective-C? Luckily, you have at least 3 months to decide, as Swift and Xcode 6 will not be production-ready until the fall. Nonetheless, it’s fairly clear that existing apps should continue to be modified and enhanced with Objective-C (especially since there are no Swift language experts in existence yet).
I would definitely encourage you to get your developers learning and developing with Swift as soon as possible, and ask any consulting firms you work with what their plans are for Swift. Objective-C will eventually have the term ‘legacy’ associated with it, and if there’s one thing Apple hates, it’s legacy.
What Swift Means for the Future of I.T.
With 800 million iOS devices sold, MacBooks being prevalent at most developer conferences, and Macs often used in educational institutions, it’s clear that Swift will have a huge impact on client-side development in the I.T. industry. (Swift, of course, will have no impact on Microsoft .NET shops that use C# for back end development.)
Apple clearly intends Swift to eventually replace Objective-C. Swift is simple enough to learn—and playgrounds are learner-friendly enough—that Swift could become the default language for teaching programming, perhaps displacing Java. Yet Swift is powerful enough for any enterprise coding requirement.
With new college graduates learning Swift to program their iOS devices, and existing developers tinkering with it at home and on the job, iOS (and OS X) developers will become much more prevalent, easier to hire, and less expensive over time. (Sorry, this won’t happen overnight.)
So what happens to new and existing iOS and OS X apps? Do we throw them away and start from scratch?
An educated guess would be that new apps, certainly, will be started in Swift. Because you can use Objective-C code and frameworks in Swift, any open source or custom frameworks you have in Objective-C can be reused and treated like a black box. Things like AFNetworking will likely be migrated to Swift soon enough, but you can still use them today in Swift or Objective-C apps. That compatibility is a defining feature of Swift and part of what makes it so attractive. And, remember, Swift-based apps will run in iOS 7 and 8, and OS X 10.9 and 10.10.
As for existing apps, well, I wouldn’t write any new classes in Objective-C; not for long, anyway. For the time being, small enhancements to existing classes would still be done in Objective-C, but I’d seriously look at rewriting individual classes in Swift when they are significantly changed or enhanced.
Think about this: 3 years from now, there will be much more Swift developer talent. Many of these developers won’t even know Objective-C. The sooner you move your code base to Swift, the better. It doesn’t need to be done overnight, but you do need a plan.