Apple announced a new language for iOS development at WWDC 2014. I anticipated this would happen at some point (not necessarily this year, but this year or next). I got that much right, but what I got wrong was the language that was announced.
The third was really a continuation of the first: not only did every demo at WWDC 2013 use Storyboards, but every single demo app from the developer portal was redone using Storyboards.
I saw this as a two-part sign. The first part I saw as a natural evolution of Interface Builder, in which Storyboards started to get more functionality (and overall attention) from Apple than nib-based files.
I saw that emphasizing Storyboard development could facilitate two important future-proofing functions. First, to help future-proof against different device screen resolutions, second, to future-proof against new languages.
The more “code” accomplished in a Storyboard, the easier it becomes to hook up the Storyboard’s outlets and actions to code written in a language other than Objective-C. (Objective-C is a language that I really love BTW, but I understand others’ distaste for it in the same way I love Uni – aka Sea Urchin Roe – but I understand that it isn’t yummy to everyone’s palate).
This will be the last time I will say it: I was both right and wrong at the same time.
So what do I think about Swift?
Looks like a cool modern language. Some parts of it reminded me right away of C# -https://twitter.com/jonflanders/status/473556152035180544.
One of the creators of Swift – http://www.nondot.org/sabre/ – posted that C# was one of the languages from which they drew ideas, so that made me feel better right away.
My other take-away from the language is that, despite what everyone else seems to be saying, I don’t see a future Swift programmer being able to be a successful iOS programmer without knowing a lot (if not everything) about Objective-C.
Although Swift isn’t built on Objective-C the language, it is built on the Objective-C runtime, and (for the for-seeable future) will continue to use the Objective-C runtime during app execution.
It’s also important to remember that the frameworks that Swift programs will use (i.e. UIKit, SpriteKit, etc.) are all built with Objective-C. Apple’s samples are all in Objective-C. Over time, I am sure that more and more Apple samples will be ported to Swift, but until that happens many pieces of Objective-C code will persist in the wild.
Also remember that there is a large Objective-C-based set of samples, frameworks, and libraries built outside of Apple. Many of them will likely be ported to Swift as well, but it may also be that Swift developers will need to learn how to translate Objective-C code.
Another pertinent point: many APIs from Apple aren’t in Objective-C at all. The iOS AddressBook API is a C-based API. Again, it may be that Apple will end up wrapping all its C-based APIs with Swift-compatible APIs (e.g. an Objective-C-based API), but until that happens (and it hasn’t happened yet for Objective-C programmers and believe me – we’ve wanted it) some code will have to still be written in Objective-C.
I also notice that people are getting a number of things wrong about Swift. For example this article: http://www.wired.com/2014/06/apple-swift-language/?mbid=social_fb&utm_content=buffer7d9fd&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer states that Swift has “automatic garbage collection” which isn’t technically correct. Swift builds on the compiler technology for Objective-C that Apple added into the Clang compiler a few years ago: automatic reference counting or ARC.
So in conclusion, I think that Swift will cause current Objective-C programmers to be even more productive creating iOS apps than we already were . It also is going to make the introduction to iOS much easier for new developers, since it has many more modern language features that developers are used to than Objective-C has/had. But, since the Objective-C runtime is still underlying Swift language for at least the next few versions of iOS (if not forever), each Swift developer is going to need to understand those Objective-C runtime features, just like every C# developer needs to understand the CLR, and every Java developer needs to understand the JVM.