Right after Tim Cook announced Swift, I looked to my left and right and saw jaws dropping and eyeballs fixated on only the bird in the orange Swift icon on stage. Objective C has been Apple's programming language of choice for the last several years, so the introduction of Swift marks a huge departure from what has become so familiar to the iOS/Mac developer.
After downloading and reading the Swift Programming Language book that Apple released on iBooks, and I was initially pleasantly surprised. Objective C is a great language, but is indeed quirky, with its confusing syntax, plethora of [ ], @, *, **, and most importantly, its high learning curve when coming from a different language.
After playing with Swift for a few days, I now have a much stronger grasp of the language and a certain level of understanding how things work. I learned that the language is extremely nuanced, specifically when it comes to Array behavior, casting, and optionals (more on that later...)
One of the drawbacks of Swift is that if there are no coding standards that a team adheres to, it is easy to write very efficient yet unreadable code.
Here is a snippet of code that takes an array of names and sorts them in reverse alphabetical order:
//Objective C
NSArray *unsortedArray = @[@"Ahmed", @"Marwa", @"Siva", @"Paul", @"Otto", @"Sam", @"Candy"];
NSSortDescriptor* sortDescriptor = [NSSortDescriptor sortDescriptorWithKey:nil ascending:NO selector:@selector(localizedCompare:)];
NSArray* sortedArray = [unsortedArray sortedArrayUsingDescriptors:[NSArray arrayWithObject:sortDescriptor]];
//Sorted Array = [Siva, Sam, Paul, Otto, Marwa, Candy, Ahmed]
//Swift
let names = ["Ahmed", "Marwa", "Siva", "Paul", "Otto", "Sam", "Candy"]
reversed = sort(names, {>})
// reversed = [Siva, Sam, Paul, Otto, Marwa, Candy, Ahmed]
The Swift code above is indeed much more compact than its Objective C counterpart, but a developer who inherits this code might have a hard time understanding exactly what this does if there was no comment explaining what is happening. There is indeed a way to make swift more readable, it just requires writing more code.
//Swift
reversed = sort(names, { (s1: String, s2: String) -> Bool in return s1 > s2 } )
One of the developers of one of the most popular iOS apps, Tweetbot, said that he will wait some time before converting current code to Swift.
Executive decision: Ignore Swift for the next 3 months, then re-access. Don't see a reason for being bleeding edge on that one.
— Paul Haddad (@tapbot_paul) June 3, 2014
I have to agree with him, because it is clear that Swift/xCode 6 are still works in progress. Currently in Swift, anything you declare in any class is automatically public and available to every other class. At one of the labs at WWDC, we asked an Apple Swift engineer if it's possible to make a property private, (that can't be altered from a different class), and we were told that this is indeed coming in the next few months. So, Apple is still actively working on Swift, and developing production apps now intended to launch with iOS 8 in the fall might be a little premature. The advantage of using Swift now would be the ability to provide feedback on the language and potentially influence the iOS/Mac language of development for years to come.
My advice to any new comers to iOS land is the same advice that Aaron Hillegass gave: learn Objective C first, then transition to Swift. Most of Apple's Cocoa and Cocoa touch frameworks are written in Objective C, so you will inevitably need to work with them to write an iOS app. Also, most iOS apps written thus far have been written in Objective C, and some apps even have some C/C++ code as well. While Apple went through great lengths to make it easy for both Objective C and Swift code to coexist in the same app, you might run across an app that is written in 3 different languages, Objective C, C, and Swift. You don't want to be in a situation where you inherit an iOS app written in Objective C and tell your project manager/client that in order to implement a feature or kill a bug it will take you an extra 4 weeks because you have to rewrite the whole thing in Swift instead of working on it directly.
While some developers think that Objective C is harder to learn than Swift, I think it is the opposite. While Swift might be less code to write than Objective C, it is extremely nuanced, and can easily confuse a new developer. Here is a simple example involving arrays:
In Objective C, you create an NSArray for an array you cannot modify after its creation and an NSMutableArray if you intend to modify the array in the future (Add, remove, replace objects to the array). You CANNOT add/remove/or replace any object in an NSArray, because is is not mutable. The class names make it very clear what you can and cannot do.
In Swift, Arrays behave rather differently. You create mutable and immutable versions of objects using let (immutable), and var (mutable). However, if you create an array with let (immutable, meaning you cannot change it), you can STILL replace objects within the array with others. It turns out that as long as the length of the array is the same, you can modify the contents and it will behave as if it is mutable, even though technically, it is not mutable. Also, if you create an optional immutable Array in Swift, you can never add/remove objects from it. I have filed Apple Radars on these and urge you all to do the same. These behaviors are documented in Apple's Swift Guide Book, but are not so intuitive.
Add optionals, generics, tuples, etc to the mix and you end up with a language that is very functional in nature, yet at the same time very nuanced. I remember when I was first learning Objective C I was complaining that it is a lot more code to write than other languages, but over time I grew to appreciate Objective C's verbosity, as it greatly increased code readability.
Having said that, and having rewritten one of my personal apps using Swift, I now find it very cumbersome to write Objective C code. I find Swift to be much more succinct, and more elegant, specifically optional chaining.
The adoption of Swift by the iOS developer community will follow the Innovation Lifecycle graph below:
Perhaps in Swift's case will be a little quicker to get to the late majority than usual, but in general, innovations take time to fully penetrate a market and completely replace what they intend to replace. Even after Swift has achieved 84% of Objective C's developers, the laggards will still need Objective C developers. The majority iOS developers will learn it and embrace in a short number of months, but Objective C won't become extinct anytime soon.