I’m not going to lie; I came at swift with a certain degree of scepticism. I have been a developer of native iOS apps since 2008/2009 using pure Objective C and if I’m honest it really is one of my favourite languages to code in. As a result I didn’t have any reason to embrace Swift at least initially as I was perfectly happy in my world of Objective C.
So what happened two weeks ago?
John Appleby and I were discussing our DemoJam Submission for this years SAP TechEd & dCode in Vegas, which included the usual mix of new technologies such as HANA Live, SAP Landscape Transformation and more. We always intended to put an iOS front-end into the mix but then we thought that it might be fun to try another new technology…so why not Swift?
So how did Swift stack up?
So off I went to create a relatively simple iOS UI in Swift. Realistically I could have probably created the UI in Objective C in about 30 minutes being conservative.
The answer is simple, definitely not longer, but not that much shorter either. The fundamental structure of the code was identical – I still needed a data source delegate for my tables and my UI was still being created in (call me old) interface builder.
However there was a massive difference in some of the fundamental concepts that usually would trip up a newbie developer or script junky. Gone were the complex imports required to keep everything linked up as well as the definition of your external interface in those .h files. This seemed strange of course as an old school ObjC developer but it makes perfect sense when you think about it and I found myself quietly forgetting about those complexities and just focusing on what I was trying to do. Which seems to be the whole point of Swift.
So in the end, I wrote less code which was as easy to read which worked just as well and took about the same amount of time (although this time would probably decrease as I get more familiar with the language).
Overall first impressions
What you gain
You gain a lot in Swift like the reduced complexity that I mentioned around header imports and the syntax. There is another area I have yet to mention which is Swifts hiding of all things memory related. Seasoned ObjC developers will know all about retain, release, autorelease etc. to keep on top of memory management.
There are no such problems in Swift as the compiler/runtime container takes care of all that. I like and dislike this – I like it because it’s easier but I dislike it because it has been beaten into me by crash reports to always manage your memory and to suddenly not have to care goes against muscle memory.
What you lose
Not a lot. I’ve not found much that I can do in Objective-C that I can’t do in Swift with the exception being of course integrating with certain enterprise systems like the SAP Mobility Platform’s native libraries. That said though, I haven’t given them much attention during the two weeks and I’m sure with some tinkering I could get it work (if I wanted to which, at the moment, I don’t – I’ll just continue using Objective C for that).
Swift is new, no doubt about it and as a result there are a few things which are still in development and I can most definitely forgive this. The only one that causes me real issues would be class/static variables. The current release of Swift does not support these and I use them quite a lot in enterprise development (possibly over-used but there you go).
Swift is very easy to pick up for both existing and new iOS developers and I would highly recommend people to give it a try. The only advice I’ll give for when you do try it is to give yourself a goal and a task to complete using ONLY Swift. Only in that way will you be forced to really try out all the aspects and really see the potential of the language.
So in a nutshell – I like Swift a lot, it is powerful and easy to pickup although it is still under development. There is nothing stopping us using it to develop the next generation of iOS apps and I for one will be using it where I can going forward.