Swift
June 5, 2014
Wish for it, and it'll happen. Well sometimes. In my last blog post I wished for a replacement for Objective C, and here it is. And it's awesome.
I've been thinking about, playing with and coding in Swift since I woke up to the news of it on Tuesday morning. I had the iBook downloaded before breakfast but had to wait through an agonising day of my day-job to get to play with it properly. (It's on the web now too, over at the Apple developer site.)
Apple just made coding for iOS (and OSX) a whole lot easier and fun to do.
Apple also just killed the thriving industry of people trying to work around the barrier that Objective C was becoming. Appcelerator, Corona, Eero, PhoneGap, RubyMotion, Xamarin, all those and more, all dead. Scripting languages like Python and Ruby, and the awful, awful mess of JavaScript are looking pretty dicey too.
But that's a good thing. Cocoa is great, and Objective C, once you get over the shock of it, Objective C can be pretty good; but iOS (and OSX, a platform that's featuring more and more in my thoughts) deserve better than pretty good. They deserve great. Now they have it.
You may have noticed I'm a fan.
There are naysayers of course. Mostly they point out that some language like Go offers superior feature X or Y. Well, maybe. For now, maybe. But you can't code an iPhone app in Go. You can't even code an Android app in it, for that you need Google's copy of a two versions out of date Java 6 and compared to that, in the words of Craig Federighi, Swift "totally rules".
I have all of three days experience of Swift, which is to say as much as anyone outside of Chris Lattner and a handful of guys at Apple, but because of that and because it relies on beta software – yadda yadda yadda – the following may be full of mistakes.
Some observations garnered from the last few days. This may be of use to someone, so I'll jot it down here. In years to come I can always reminisce about how naive I was. (Moreso.)
- NSHomeDirectory() refers to the app's sandbox when inside an iOS project, but to the user's home directory when a playground's outside of an app.
- In the same vein, import UIKit will only work in a playground that's inside an iOS project.
- I was impressed by the first introductory tour chapter of the Swift book including a downloadable copy of itself as a playground to let you dabble directly in the examples. Thoughts of literate code though gave way to worries about malicious swift code downloads. This'll need to be addressed. Meh, it's beta software.
- Using the Cocoa libraries is going to take a bit of overcoming muscle memory (ditto not typing semicolons). So far the choice of what is and isn't optional as a parameter name is mostly intelligent and helpful. Thought has gone into this, eg CGContextFillRect(context, rect) makes sense as it is, but CGRect(x: 0, y: 0, width: 100, height: 100) benefits from the names.
- When you create a class you'll get a stock init() function, but for a UIView used by IB for example init(frame: CGRect){super.init(frame: frame)} is not what you want. You'll need to add init(coder aDecoder: NSCoder!) { super.init(coder: aDecoder)}, or have no init function and use the inherited one.
- There are no private, protected, friend, buddy, pal or other access modifiers. Everything's public. In the language so far anyhow. There are protocols, and that's how access is meant to be handled I suppose.
- There is sometimes a very Ruby-esque dedication to having more than one way to do things. There are by my count nine ways to declare closures (anonymous functions). eg to use the example in the book, the following are all equivalent:
reversed = sort(names,
{ (s1: String, s2: String) -> Bool in return s1 > s2 } )
reversed = sort(names) {
(s1: String, s2: String) -> Bool in return s1 > s2
}
reversed = sort(names, { s1, s2 in return s1 > s2 } )
reversed = sort(names) {
s1, s2 in return s1 > s2
}
reversed = sort(names, { s1, s2 in s1 > s2 })
reversed = sort(names) {
s1, s2 in s1 > s2
}
reversed = sort(names, { $0 > $1 })
reversed = sort(names) {
$0 > $1
}
reversed = sort(names, >)
As I get used to it it'll get easier to spot the patterns, and blocks in Objective C never really made sense to me intuitively. I could power my way through them but I struggled with the syntax, these at least look right or wrong to me when they are.
It's very early days but this is all very, very good. I had rewritten the blog engine that powers this site as a Node module (in JavaScript, boo!) but I really couldn't be bothered going back to it to put that into production, this is the old Ruby-powered site. I'm rewriting my blog reading app, and a couple of new apps in Swift. Writing in other languages just seems like a waste of time.
Apps that are easier to develop & get right & to maintain. Better apps, quicker. What's not to like?