Two Reasons We Needed Swift

Swift needed to happen. Objective-C had no future. I know this is a harsh statement, but this is the conclusion I came to this week after writing purely in Swift for a few months now. It is hard to admit, especially after spending most of my software development career writing in Objective-C. There is a chance that a lot of you will disagree with this statement, but let me mention two things I find lacking in Objective-C that are extremely important when it comes to writing good code.

Objective-C by its nature is a much forgiving language (and I am using this term loosely). It allows developers to get away with bad code. It does not impose requirements for handling errors. It allows for nil return type where a specific type is expected. It does not guarantee immutability. It requires extra work to declare true constants. Block syntax (should I say more)?.

Consider this example (this is a simple function for returning documents directory URL).

This is how alternative, Objective-C version looks like:

The above Objective-C function can technically return ether NSURL pointer or nil. Because of that, diligent developer will check for nil every single time he/she tries to get documents URL. However, it is not perfectly clear from looking at the Objective-C version that it can return nil, after all the return type is NSURL. Because of that, usually developers assume that NSURL will be returned every single time and simply use it as if NSURL is guaranteed.

Looking at the Swift version of the function, it is perfectly clear that the function can fail. It forces developers to handle an error if it occurs. And even if we are almost guaranteed to get the documents directory, why should we trust it will work every single time in the first place? Trust, but verify.

Next is mutability. It’s a bit tricky when it comes to Objective-C. When you define a constant in Swift with let, the compiler guarantees immutability. Array, dictionaries and quite honestly most of the data structures in Swift are value types which also means they are copied when necessary (copy-on-write). In Objective-C, while you could declare immutable string with NSString*, the fact that you have immutable object does not mean the pointer will never change. Also, consider the following:

Both the mutable and immutable dictionaries will now contain the following:

The solution is to manually make copies like so:

While it is doable, it is still the source of bugs that are hard to debug. Good luck when working with multiple threads. Swift eliminates this issue completely since there is simply no reference sharing, period (value types are copied on assignment). Another important point about mutability in Objective-C is the fact the mutable classes such as NSMutableArray or NSMutableDictionary are subclasses of their immutable counterparts which means I can return NSMutableArray instance where NSArray instance is expected. This would be another gotcha when debugging Objective-C code.

It is true that unlike Swift, Objective-C has been around for quite some time. It has established best practices and quite honestly is still a good language to write in. Swift, however, is the future not because Apple is actively encourages developers to write in it, but because it is genuinely a much safer language to begin with. It solves lots of problems and makes code safer.

Having said all this, I am not looking forward to Swift 3.0 migration. It will be a bumpy ride, that’s for sure.

Two Reasons We Needed Swift

Leave a Reply

Your email address will not be published. Required fields are marked *