How good is Swift? My first impressions
As many know, last year, Apple released its new programming language, Swift, and since then they put a lot of efforts in making the language more and more popular among iOS developers, specially newcomers. Here we are now, with Swift running for a little bit more than a year — 2.1 just got released edit Swift has also been open sourced. But is Swift really worth it? I’ve recently been assigned to start a project from scratch using Swift and I took this opportunity to dive into it. Last year, I thought Swift was pretty incomplete. Let’s check how it is now.
After getting over the learning curve, experimenting numerous crashes from Xcode and and getting crazy errors, I was pretty surprised. Many things I’ve always felt Objective-C was missing were added to Swift. On the other hand, I was also somewhat disappointed with other stuff that I had expected from a programming language that has been “out of beta” for more than one year.
Lets start with the good things and then we’ll go to the famous “but…”, and since most of these topics may get quite a stage for itself we won’t get into much details here. I left some references in the way for you to learn more about each individually.
Map, reduce, filter
Swift might not be a functional language but it has incorporated nice aspects of functional programming and one thing is for sure, it can be quite useful… At first glimpse, it might look weird, but once you learn how to use it, you’ll say good bye to many extra loops and lines of code. You can check this tutorial here if you want to have a glimpse on it.
Optionals?
Optionals are basically a way to say if that variable is nullable ‘?’ or not ‘!’, but when you first look at optionals you go like “What is it supposed to mean?”, specially when unwrapping a boolean value and negating the value, then you almost think you’re writing in Spanish…
var arriba : Bool?
arriba = false
let tequila : Bool! = !arriba!But after you understand how it works, it makes your code way cleaner and maintainable.
Collection type specification
class Company {
var employees : [Employee]!
}This was something I found really strange when I started programming in Objective-C; being able to create a collection of a type is something really good for making the code cleaner and avoiding having an object of a random type in the middle of your collection.
Protocol extensions
Protocol extensions is a really nice feature on Swift, where you can give your protocol methods a default implementation. If you know that the classes that implement your protocol will always have a partial or same behaviour, you can put this code there and be even more friendly to the old and good practices of code reuse.
For me these features were of good help and I was really happy to see it there. With that being said, we got to that unfortunate “but…” that goes to some things in the language I was not happy seeing or not in there. So without further ado, lets get into the list.
Constant Changes!
Swift is a very new programming language, which got out of beta last year with some improvements. But being a release means to have a solid defined code base with changes by deprecation, which is not what we have seen on it. Instead things are removed, changed or going back and forward constantly. For instance one of the changes on Swift 2.1 release notes:
- The type dispatch_block_t now refers to the type @convention(block) () -> Void, as it did in Swift 1.2. This allows programs using dispatch_block_create to work properly, which was an issue in Xcode 7.0. Note that converting to a Swift closure value and back is not guaranteed to preserve the identity of a dispatch_block_t. (22432170).
Access modifiers
We’ve got some access modifiers added private and internal, it was nice, but I got really disappointed with it not having a protected access for subclasses. Some can argue if you put the subclasses in the same file they have access, but would you really be willing to put all your inheritance chain in one file? Wouldn’t it be messy?
Selectors
Performing selectors in Objective-C was not 100% error safe [myObject performSelector:@selector(myMethod:)];
you could write anything for selector, but at least you’d have a list of some possible methods and you could get a warning saying it was not safe that way. I always thought it was insecure this way and when starting on Swift, one of my first thoughts was about less error prone selectors. Surprisingly, Apple managed to make selectors even easier for people to make mistakes. Now when you send a string straight away, you can easily make a typo and you won’t realize until it crashes.
let button : UIButton = UIButton()
button.addTarget(self, action: Selector("myMethodName:"), forControlEvents: UIControlEvents.TouchUpInside)Syntax too flexible
In Swift you can write many things in many different ways, excellent no? less things to worry when writing the code, flexibility, easier to learn… Well, this doesn’t go very well when you think about maintenance and readable code, unless you’re a lone wolf you should keep in mind that you have to take a look in other peoples’ code, for instance:
public enum MyEnum : Int {
case Custom
case Other
case Normal
}
func myMethod() {
let button : UIButton = UIButton(type: .button.setTitle("My title", forState: .Normal)
}Which enum value am i calling? having UIButtonType.Custom and UIControlState.Normal would be much more clear. When you look at it and imagine all the time added up to stop in each situation trough the whole code and check what’s happening, doesn’t sounds that good right?
Xcode
Before finishing, we could not forget our dear IDE, Xcode! This is not something related directly with the language, but since most of the iOS developers use it and it is also Apple’s responsibility, I felt it couldn’t be left aside. Xcode was never known as the best IDE, but since it belongs to Apple, I was expecting it to work better with Swift. Many times we get some errors that only make things worse, specially with Optionals. Some errors I faced where being asked to replace a type by itself, add characters that don’t fit there or messages that are better just to ignore and find the problem on your own, among others.
- first error:
- after fixing the error:
- Solution:
Conclusion
This article is about the points that caught my attention and I found worth to highlight, it’s not a complete list of what’s new in Swift nor an Objective-C vs Swift fight. This being said, if we go back to our initial question “But is Swift really worth it?”; well the real answer is — as always, “it depends”. I feel like Swift is still a language in beta almost ready but trying to disguise itself as a release. If you don’t mind the learning curve and the negative points mentioned then I suggest to give it a try. If on the contrary you can’t afford it for now, the best option would be to wait until it gets more stable and become a real release.
