The journey from Objective-C to Groovy

Apple / Development / iOS

A few weeks back I posted an entry called “The journey from Groovy to Objective-C”. Well at WWDC 2014 Apple announced their new language called Swift which is eerily similar to Groovy in many ways.

This truly is fantastic news because Groovy is an insanely productive language. After years of using it, it is hard to go back to anything else – but you find ways to manage as I mentioned in my previous post on this.

However you’d think that something as expressive and powerful as Groovy could never be fast enough for an Apple-quality native experience, but wow it really is possible it seems. Swift is faster than Objective-C in many cases according to Apple – of course C/C++ heads will say that’s no big deal as Objective-C is “slow” relatively speaking.

Having only played with Swift for a few hours since WWDC (I’m busy making an iPhone app), the overlap with Groovy is very obvious and welcome.

What is funny is that I am hearing the same tumult over Swift in the Objective-C world as there was over Groovy in the Java world. A large portion of people don’t want to touch it, and a large portion are rabid about it.

I am really looking forward to the dust settling and being able to build iOS apps with Swift. Those productivity benefits I enjoyed for so long after moving to Groovy from Java will mean we can make better apps more quickly. I have been using ObjectiveSugar to bring some Groovy-ish goodness to my Objective-C to date, and these little enhancements seem no big deal but the difference they make to the way you think about code, the readability and terseness are invaluable.

Swift features like Optionals, Closures and the at-times mind-bending Generics systems, not to mention the pattern matching are going to be so powerful. Of course there’s a fair amount horror too at the what operator overloading is handled, but we’ll see how that goes. I don’t think we’ll end up with C++.

All of the little warts around interfacing with Objective-C APIs will surely in future be solved by new Swift native APIs, presumably with some major overlap between iOS and OS X UI technologies. I can really see Apple introducing a totally new UI layer based on Swift in a year or two, that allows most UI functionality of iOS and OS X to be expressed identically.

It is pretty likely Apple will add the ability to execute Swift server-side code (endpoints) in CloudKit at some future point, and that will also be very interesting. It remains to be seen whether they would open up a server API that could be used outside of CloudKit client code, to allow cross-platform clients, but with this recent WWDC it seems all bets are off.

Remember to read the full Swift Language Guide free from the iBooks store.

The Author

Marc Palmer (Twitter, Mastodon) is a consultant and software engineer specialising in Apple platforms. He currently works on the iOS team of Concepts sketching app, as well as his own apps like video subtitle app Captionista. He created the Flint open source framework. He can also do a pretty good job of designing app products. Don't ask him to draw anything, because that's really embarrassing. You can find out more here.