WWDC this year was one of the more interesting keynotes I've seen out of Apple in my 13 years of following them. From start to finish, there was a level of confidence I haven't seen in recent events, and I think it's due to a lot of long term bets starting to pay off. They had so much to talk about, they skipped their traditional keynote openers of Apple Store discussion to talk about iOS 8, OS X 10.10, and new developer APIs/tools.

A new modern programming language, Swift seems to be the biggest piece of this. Development of it started a few years back, and was made possible by Apple's extensive work with extending LLVM. Looking back, small hints appeared in Objective-C of the modernization efforts underway (ARC, Blocks). Many developers saw those efforts as a sign that Apple would stick exclusively to Objective-C for a long time, with no hint of the new language being developed in parallel. I'm starting to work though their ebook to learn the language, with a goal to make an iOS 8 app with it.

The interesting aspects of Swift for me revolve around their balance of 3 goals. Safety, Performance, and Modern features. Similar efforts by Microsoft led to .Net frameworks and the C# language. Apple only made a new language, bringing over all the existing Cocoa frameworks. An interesting approach that is enabling any existing Cocoa app to swap out file by file Objective-C for Swift. Apple's goal for the language is to have it usable as a scripting language all the way through to an entire operating system. Will be interesting to see if Apple pushes any Swift code out at the kernel or other open source components of OS X.

I'll follow up with some iOS 8 and 10.10 specific feedback later. Apple is less restrictive this year in regards to the NDA, including opening developer videos to everyone here.

Swift is definitely interesting, but I wish they hadn't tied themselves so much to ObjectiveC and how the framework works. The most obvious area where this shows is that Swift doesn't have exceptions or any other form of built in error handling.

(though CocoaTouch proves you can slap a very different language on top of the Cocoa and do thing that don't exactly fit with ObjC)

Is there a reason behind the lack of such that you are aware of? I've made use of exceptions in some of my past programming efforts and see their use, so it's puzzling to me too that Swift would lack them.

One concern from two coworkers with Swift is readability of the code. The non mandatory need to declare what type a variable is may lead to less readable code. Readable in XCode where you can quickly see due to the tool, but not readable in a code merge tool for example.

So much of my own code reading is more from "is it merging right" between branches, and less following the flow of execution, so I lack the perspective to be able to know how much of a downside this may be. For my personal stuff, probably not a big deal. I just wonder how friendly Swift will be as a language for a team to make use of.

I assume it comes down to they want to use the framework unchanged, the framework uses error codes rather than exceptions, so Swift would have to use them to call the framework even if it had exceptions.

A similar issue shows through when it comes to named parameters on the methods. Unlike other languages with named parameters you can't reorder the parameters when you call the methods, you really are calling an ObjC selector when it comes down to it and so the order is fixed.

CocoaTouch dodges all this stuff by layering its own C# flavour of the Cocoa framework on top of Cocoa. Clearly Apple took the approach of putting as little between Swift and Cocoa as possible.

I use C# and Javascript in a team, both of which have variables with no type defined in the code (when you opt to use var in C#, which we do, a lot). I can't say the lack of variable type visibility when merging has ever really being a problem. Either you know the code and so you know what it going on, or you don't and you probably shouldn't be the one merging it anyway...

Also, the image of a bunch of ObjC programmers worrying about the readability of another language is priceless

My first job as a "build master", I didn't know any better when I started. They just tossed this responsibility onto me, and taught me how to merge up and down in the tree. It's given me exposure to a lot of different code though. And also showed me why merge up and down was a bad idea. Much more prefer merge down copy up.

Thankfully the projects after that were more sane with merges. Generally it was a common engine used between projects, and the only merges I was handling was pulling from the shared area into the specific project team I was part of.

Only this most recent job put me back in a similar position as my first with merges, but I switched them to merge down and copy up practices. Experience in the past paid off to avoid some pain again


Hehe, indeed. Though to be fair, these developers day to day work in C# and C++, we are a mostly Windows shop expanding a little to other platforms.

For C#, there's no type declared in the code; it's still defined. Type inference FTW.

Or, in English: C# 'var' variables aren't dynamic; they still have a type; it's just not visible in the source code. Wave your mouse at it if you care.

I'm sure you know this, Andy (and others), but I'm going to be a pedant anyway, because I've occasionally had to correct some otherwise experienced, professional programmers who should have known better.

All very true. I detailed the difference type inference vs dynamics in my post, but then deleted it before posting.

I appreciate feedback like this Roger. My personal goal with learning Swift is to also fill in some of the knowledge gaps I have from being on the sidelines of development teams.

Swift also does type inference for both 'var' and 'let'. Let being constants in Swift.

Swift is now open to anyone to try out, just a free registration required to download XCode 6 beta: https://developer.apple.com/swift/

I've made progress through the ebook and running the examples side by side in a playground. It's been a great way to learn not only the language, but also filling in some knowledge gaps I have.

Closures is where I'm running into some issues understanding their purpose, and difficulty performing the experiments suggested in the book. I think building a few actual things will help my understanding though. As XCode 6 is stabilizing, I'm getting closer to starting work on an app.

One handy thing as the language is changing, they turn older syntax into warnings with a fixit tip. Found a few of these in my playground after opening it in Beta 3:

A year and a half later, Swift is up to version 2.1.

The announcement earlier this year of it going open source has happened now, and swift.org is the main site for it. Impressively, the commit history going back to Swift's creation in 2010 is fully preserved and part of this. All future development will happen directly on GitHub, similar to how the WebKit team has worked in the open.

Someone from HackerNews summarized the open source aspect, and to me it looks great.

Also useful, a new Foundation project is part of the open source release. It's not tied to the Objective-C based foundation libraries common to only OS X and iOS, instead meant to help cross platform compatibility without the NextStep legacy. This is still a work in progress for the Swift 3.0 release sometime late next year.


Anyone else here been tinkering with Swift, or have gone farther and integrated it into their day to day use?

Good summary of the activity around Swift since the open source release. http://www.jessesquires.com/swift-open-source/