by Cesare Rocchi

Between me and Swift

by Cesare Rocchi

When you teach it you build examples close to real world scenarios, but still not fully real. When you work on a project on your own you might take shortcuts to avoid what you suspect are intricate situations. When you work with a team, with designers that want a pixel perfect implementation, with an existing code base, with some bridges to Objective-C, with changes of mind along the way then you have a good battlefield to test a tool.

I spent the last month working (part time) on a client project. I struggled quite a bit with Swift and related tools. These are very personal opinions so a little bit of context is mandatory.

  • For the last nine years I have used Objective-C to build iOS and Mac apps
  • I like Objective-C
  • I have grown a pretty business-y mindset over the years, so I consider a programming language, a compiler, a debugger, an ecosystem just tools to achieve a goal

My first struggle is purely aesthetic. When I open Xcode I still think of Objc. Yes, Swift has been around for a year and a half but old habits die hard.

Compilation times have improved a lot since the first release but I still think we are quite far from the compilation speed of an Objc only project. The project I worked on took almost two minutes to build after a clean. To me, it’s enough to lose momentum. You might wonder why I needed to clean. Because most of the times it’s the solution. Hear me out.

  • You make a change
  • You get a warning or an error
  • You think “it has to work”
  • Most of the times, it has to (at least in the cases I stumbled upon)
  • Clean
  • Build
  • 80% of the times the warning/error is gone

That’s why I always clean, or even delete the DerivedData folder before looking for an answer or asking colleagues and friends for help. I don’t recall having to do it pretty often in the past.

What’s worse is the Segmentation Fault 11 case. Essentially the compiler is telling you “I am confused, please be more explicit”. To me it usually happens when I add or delete code within a closure. The error you see in the console is not helpful at all and there’s no reference to the code that is generating it. You just have to roll back your changes until you don’t get the error. Very frustrating. I have friends that sent their whole project as attachment to a radar. My project was under NDA, otherwise I’d have done the same. If you are curious my case was pretty complicated:

  • subclassing a class that inherited from NSObject
  • that implemented NSSecureCoding (and so needed init(coder:))
  • the superclass had an init? kind of initializer with an optional parameter

All I wanted to do was subclassing and adding a convenience initializer. I followed all the rules by the book, I checked and rechecked. Of course I did clean before building, many times. Of course I deleted DerivedData many times, but I got always the same error. After two hours I thought it was kind of “immoral” to spend more time on that, since I was doing client work.

I could have built a minimal project to reproduce the issue. Yeah, I could, but I did “what’s in the best interest for my customers”. I talked to my handler at the company, I found a workaround and then I moved on.

Overall I had this feeling of fighting the tools instead of getting work done. I am sure it’s not just me. When I go at conferences and chat with friends I meet quite a lot of developers still more productive in Objc and struggling with some of the Swift quirks. There’s a whole episode of Under the Radar where David and Marco talk about why they didn’t jump on the Swift wagon yet.

If I started working on a product (and not just a project) today I’d do it Objective-C, because I am still much more productive with it.

Swift is the future, we can’t ignore it. It has improved a lot since the first release. It’s still a moving target though. Also developing Mac/iOS apps is a moving target, with new devices and APIs released pretty often.

So when (lack of) time is an issue, when shipping on a tight deadline is the goal, when I want to avoid being potentially sidetracked, I try to minimize the number of moving targets and pick a slightly safer harbor.

P.S. When Ben Scheirman read this post he suggested to add “Get off my lawn” somewhere :)