Swift and its Day-to-Day Problems

I recently got back into Mac development in my job (which by the way makes be incredibly happy, but this is another story). I get to work on a cool project for which I decided to go with Swift as the development language. I’m a long time Objective-C user and know a lot of amazing stuff you can do with it. I admit that I might have done some things in the past that might make some people out there very anxious, but that’s how the Objective-C world rolls. You can do incredible things and incredibly stupid things with it. With great power comes great responsibility, so you better know what you’re doing when you swizzle an object’s methods during runtime.

There has been a big fuzz not too long ago about the missing dynamism and flexibility of Swift compared to Objective-C. I don’t want to go into the details here, there are much smarter people that probably already wrote and talked about this. All I can say here is that to me and many other long time Objective-C developers, Swift feels like an academic language. In my opinion it’s not too far away from C++, which was condemned by the public for being too complicated. Swift might be a little easier to write for newbies and there are probably some smart solutions to old problems, but from a broader perspective there’s not that much of a difference – I don’t know why square brackets are more complicated than spreading ? and ! all over the code. It feels like a language designed by programming language nerds for programming language nerds. It solves theoretical problems that lots of developers that just need to get their stuff done do not really encounter in real life. But that’s ok. Let new things emerge. I don’t want to stand in the way of such things all the time and forejudge Swift just because I might be too stupid too understand aaaaaalll the great features. So there’s that. I’m a bit grumpy about the language and how it behaves on it’s home platforms. In general I really like Swift! But I just don’t really understand the need for Swift.

And here I am… I spent some time learning Swift and worked on a couple of side projects to get used to it, and I actually enjoy writing Swift code. At least most of the time. I actually see some advantages. But there are also no huge things I could not do in Objective-C with a little more code but probably way faster and more confident. So, now I am creating this shiny new app with the greatest Swift version out there because who doesn’t find it just great to touch every other line of your code every couple of months because mature Swift got even more mature and everything is different again in ways I could not care less about.

Since I use Swift I want to do everything the Swift way… all in! Why wouldn’t I? Protocol based programming to create interfaces for everything even where it’s not needed to get the work done, because that’s how we roll these days. Why use classes when I can use structs for data types? Awesome! Everything looks so clean suddenly! But what’s this… The app crashes because some property I defined with a protocol type in my view controller is not key-value compliant. I can’t bind the UI to a property with a protocol type? Strange… Ah I got it! Of course the class implementing the protocol has to inherit from NSObject, because we still live in this ancient world (what does NS stand for anyways?!). Hm… Still crashes. Let’s see… there’s an NSObjectProtocol protocol. Maybe my protocol has to inherit this one. Nope, also doesn’t help. KVO methods are not defined in here. After some fiddling around and digging through Stack Overflow I found out that I have to mark the protocol with an @objc flag.

@objc protocol MyProtocol {
    …
}

What the F? I thought I used Swift and now I have to tell Swift to behave like Objective-C?

Phew. Ok. Weird. But let’s move on. Wait what? The app crashes because something with my value formatter for a date label is wrong? Hm. Weird too. Turns out… in order to have a custom value formatter being used in Interface Builder and without registering it in my AppDelegate (talk about less code!) I also have to mark its class with an @objc flag!

@objc(MyTransformer)
class MyTransformer: NSValueTransformer {
    …
}

Ok. Let’s move on… I need an NSTimer and it should periodically call a function of my class. What else is a timer for? Alright let’s test it! Hm… Why is my callback not called? Of course! I need an @objc flag in front of the function definition!

...
let timer = NSTimer.scheduledTimerWithTimeInterval(
    interval,
    target: self,
    selector: #selector(MyTimingClass.fireTimer(_:)),
    userInfo: nil,
    repeats: true
)
...
timer?.fire()
...

@objc func fireTimer(timer: NSTimer) {
    ...
}

Are you kidding me? That’s clean? I think I know the reasons why it has to be done this way. But that’s because I actually know Objective-C and I know how things work behind the scenes. But someone that’s new to the platform and decided to create an app because Swift is so easy to learn (really?)… how should someone like this know what the heck is going on with this @objc thing and why it makes the shiny new code so ugly?

I get that everyone thinks Swift is great because it’s the shiny new tool that everybody has to like because Apple tells you to do so. But let me ask you: for which platform is this language supposed to be created? It sure is not made for the Mac. I’m not even that deep into development yet and I encounter a problem each day that makes me think about the decision to do a Mac or iOS project with Swift instead of Objective-C.

I really can’t imagine that most of the people that contribute to the Swift language – it’s fully open sourced, if you didn’t know yet – are actually building applications with the language. It just does not fit the paradigms that made its platforms so successful and joyful to use and develop for. It’s academic. And why wouldn’t it be that way? The people that are building apps for Mac and iOS are struggling to make a living with their software. They surely have no time to read literally thousands of eMails on the Swift mailing list and to propose changes and improvements to the language. The people that have to use the language are not the ones who design the language. The people who design the language are not the ones who build anything with it.

I really like Swift as a language itself. It’s new, it’s clean, it’s fast. It’s supposed to make everything easier and safer. But it’s just not made for the platform it was intended for. Developers that know what they are doing rather need a language that let’s them do their work, even if academics think this is a bad idea. Swift takes away lots of these things. Dont’t get me wrong… It’s ready for prime time! You can definitely build apps with it without any major problems. But! You have to jump through hoops to make it work the way the platform works too often and that’s either a problem or intentionally made like this. Maybe the language itself is just not there yet. Maybe I’m too stupid for it. I do hope that things like the @objc flags will disappear at some point and when it’s ready, I will also jump on the hype train. Until then I will use it happily but a bit grumpy just to not be the one who has no idea about Swift in 5 years when there are still no new Macbooks, we are all working on our 27 inch iPads, there is only iOS left and you can’t submit any apps that are not written in Swift anymore. But that’s another story too.