Mac and iOS developers are taking hard looks at Swift, Apple's new programming language introduced this month at WWDC in San Francisco. Some urgent questions include whether Swift is good or bad, whether it should be used for current and future projects, and whether or not programmers should go back and recode their past Objective-C work.
David Owens, of Microsoft's MS Office for Mac and iPad team, had previously posted on Medium that the introduction of Swift was a bad day for ObjC programmers.
This has me very sad for the future of iOS and OS X development. I do not see, at this point in time, any major changes happening to Swift. There are many fundamental items about Swift that I'm just not a fan of that I think break the spirit of what ObjC was about: pragmatism.
With just a little bit of work (and a lot of time fighting with current bugs in Xcode and Swift), Swift makes it possible to toe the line between type-safety and expressiveness. I can only imagine, that when we get proper documentation for all of this goodness, that most of my static typing concerns will simply dissapear.
Feeling much more bullish on Swift today. =)
At the Cocoanetics blog, Oliver Drobnik responded to the question whether programmers should switch to Swift as well as to whether it makes sense to migrate existing code to Swift. Of course, his answer to the first question could be summarized as "it depends," mostly based on when a particular app will be released. However, on the subject of backwards migration, Drobnik said there are good reasons to wait.
We have several closed- and open-sourced projects using Objective-C. There is nothing to be gained by rewriting everything in a new language. Apple lets you mix and match languages. If you add a new class to an existing project, you may let yourself be tempted by the allure of Swift and use that for the implementation. Or even a new app is something that you can tackle in Swift right from the start to learn about it and be able to give feedback to Apple. I don't see Swift replacing all of Objective-C development right away.
To my sense, Drobnik's approach was similar to starting up a new relationship. He said he would continue coding in Objective-C for existing projects and when Appledoc supports Swift, he might consider doing a project in it. But there was no reason to "rush into a new relationship with a new language and abandon one you have grown to love over several years. Take your time to get to know each other first."
Rob Napier, coauthor of iOS 7 Programming Pushing the Limits, posted on the Cocoaphony blog that despite reports that Swift was a functional programming language, there was little "functional" about it. He said it was a "pretty traditional object oriented language." But that was okay.
I would have loved all of Cocoa development to go functional, but just because I enjoy it. I don't know if it would have furthered the goal of really fantastic iOS and Mac apps, at least in the short term. It's not that FRP isn't a good idea. I don't have a strong opinion on that. It's just that the learning curve is high for ObjC programmers compared to Swift.3 And we'll need to integrate Swift with (non-functional) ObjC for a long time.
Napier hopes that Swift will incorporate more functional features. If so, he said, "Swift might be a surprisingly important language and could improve the programming discipline because programmers would have to learn functional programming to develop on a very popular platform. ... Or none of that may happen, and Swift might just be a language for writing really fantastic iOS and Mac apps, and that's OK, too.
Practical Swift posted a list of 74 built-in functions (of which only 7 are currently documented). "The definition used for 'built-in function' used in this article is a function available in Swift without importing any modules (such as Foundation, etc.) or referencing any classes."
Michael Ash, author of The Complete Friday Q&A: Advanced topics in Mac OS X and iOS programming, posted an analysis of what he called "interesting features" in Swift. The list includes:
Explicit optionals. Swift makes optional values a first-class language construct, and requires that any optional type be explicitly marked as such.
Multiple return values. Swift allows a function to return multiple values.
Generics. This is a huge one. Swift supports generic classes and functions.
Type inference. Static typing is nice, but it can lead to painful redundancy in code.
Class-like structs. Like Objective-C, Swift has both classes and structs. Unlike Objective-C, Swift structs can contain methods.
Trailing closures. This is a nifty feature that's simultaneously pointless and really nice.
Operator overloading. I imagine this one will be controversial.
Ash says he's looking forward to using Swift. "It has a lot of features that may seem foreign to someone coming from Objective-C, but I think they ultimately make a lot of sense and will be nice to use."
We are in the earliest days of the transition from ObjC to Swift and there will continue to be naysayers, no doubt. Eventually, there will be fans. That transition, however, won't be — dare I say it — swift.