Thoughts on Swift

hsoi blog, talk Leave a Comment

When Apple announced their new programming language – Swift – everyone took notice.

I’ve been watching Swift with much anticipation since the announcement, but haven’t worked with it until recently. Main reason? There’s only so much time in a day and I have clients and other obligations to tend to. But still, I paid attention.

Recently, Apple declared Swift 1.0 GM. At the same time, iOS 8 was happening and I wanted to give PanemQuotidianum a small bump for iOS 8, taking advantage of a new feature: widgets (Today Extensions). This would allow the Panem daily message to be visible right there in your Notification Center. Seems appropriate for the app.

This seemed like a good opportunity to finally get my feet wet with Swift. I was determined to write the widget and do it 100% in Swift. I wasn’t going to rewrite Panem in Swift, but there was potential for some bridging between the app and the widget. That didn’t pan out, but I did have to make some changes to make it possible for the widget to work. But that’s not the relevant discussion here: I’m talking about Swift.

I’ve been reading Apple’s documentation, but it’s a lot to deal with, especially when you want to dive right in. The awesome has a 3-part tutorial on getting started with Swift, so I started there. Many things seemed familiar, but certainly there was a lot of new. Playgrounds are a great resources for being able to try before you commit.

Here are the two things that sold me on Swift.


As I worked on the widget, I found a good place to refactor some code because most of the logic was the same in both places. However one place needed one result out of the work and the other place needed another result. Tuples to the rescue! Oh sure, I could have done a bunch of things to make it work: return an NSDictionary, or create a more cumbersome implementation method with two simpler convenience methods that called the cumbersome method to get the work but then make the API easier to work with in most client code. But any of those approaches are just… well… how you have to deal with it in Objective-C, but Swift? A tuple gets it done very easily.

I didn’t plan on doing things that way; the code just naturally went that way but it was like “OK, there you go… instant example of Swift advantage!”

Old Habits Died Quickly

I only spent 2 days working in Swift code.

Then I had to write some Objective-C code. I couldn’t! I was writing my if-statements without parenthesis, and I was forgetting to put semi-colons on the end of statements! I’ve spent the better part of 20+ years writing in C-based languages, and all those habits quickly went out the door after only 2 days of Swift.

You don’t know what’s extraneous until it’s gone. 🙂

I’ve used other languages that are less verbose, like Python and Ruby, but they are such radical shifts that it doesn’t feel the same. Swift still maintains a very C-like syntax, but just does away with so many of the C-isms. Things that can be considered extraneous. Or simply overcoming much of the shortcomings of C. Like to be able to use strings in a switch statement is awesome. The lack of needing to break out of case statements can save a lot of trouble. Further syntax changes are there precisely to make life better, things we always wanted in C-based languages and perhaps found ways to accomplish (e.g. Swift’s ?? operator), but Swift just codifies.

The Future

It’s quite evident Swift is Apple’s future.

They spent 4 years developing it. Why did they develop it? Because they want the best performance, and there are things that are just hard for compilers to do with C-like languages, like aliasing. Consider Apple’s massive investment in LLVM. Consider all new developer documentation is providing both Objective-C and Swift information. There’s big investment. Exactly what Apple sees to gain we don’t know, but it’s evident from their massive investment in it, they see it as very important and vital to their long-term future.

Thus, it’s only wise to adopt it.

Does this mean Objective-C is going away? Unlikely. Look at another big piece of Apple’s technological history: Carbon. Carbon was introduced before Mac OS X 10.0 because originally Apple said “Hey all you developers, throw away all your existing source code and rewrite your apps from scratch using this new obscure language (Objective-C) and these new obscure frameworks (Cocoa, or then known as “YellowBox”)” and every developer balked. Could Microsoft really just trash and rewrite Office? Could Adobe really just trash and rewrite Photoshop? So after much backlash, Carbon was introduced as a way for old Mac Classic Toolbox APIs to exist in the Mac OS X world. Carbon still exists today, but it’s obviously deprecated and doesn’t get the love and forward-progress Cocoa gets. On the whole, this is fine. But recall how Apple was just as “yeah, Carbon’s an equal citizen” about the technology. Where is it now?

I don’t think Objective-C is likely to go away. iOS developers will probably see less of it, but I suspect the Mac OS X developers will hold onto it more. There’s much more support for legacy systems with Mac developers (than iOS developers). As well, cross-platform is a big deal. Most iOS development that goes cross-platform tends to use solutions like Appcelerator, PhoneGap, or Xarmarin/Mono — which is a whole other solution. But most Mac OS X cross-platform development tends to take approaches like using C++ for model/engine and other xplat resources. C++ and Swift don’t directly integrate: to use your C++ code in Swift you must wrap the C++ code in an Objective-C wrapper and use that Objective-C wrapper in your Swift code. I’m not sure what adoption will be like there.

Still, Objective-C should remain around for a good while. But like Carbon, I suspect while it will continue to live, it will also become a lesser priority. We will likely see all new things from Apple being done in Swift, from documentation, to sample code, to even new frameworks being Swift-only.

Me? I plan on using Swift all I can. Not every project will be right or able to use Swift, but where possible Swift is going to be adopted. Why? The writing is on the wall: it’s the future for Apple, and we won’t be left behind. Plus gee… if it isn’t a fun and nifty language to use, that in a short while has demonstrated it’s got a lot to offer. If it can enable us to write better software, less bugs, more power, more efficient, both in terms of the development and then how it runs for users? Well, why wouldn’t you adopt it?


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.