Why we chose Swift for Stringer

Dave Vioreanu | December 2, 2014

A little-known fact about Stringer is that it is built entirely in Swift. While this may have seemed like an audacious decision, particularly when it was made six months ago, we had a few reasons for doing so.

The timing was right.

The timing was perfect, actually. When WWDC rolled around, we had just finished up a few rounds of prototypes for Stringer. The plan was to head out to San Francisco, get some tips from Apple Engineers, then come back and scrap the code to start fresh on the production build. With the announcement of Swift coming at that exact breaking point, the path down developing in the new language was almost certainly cast in stone.

We were excited, but needed to be pragmatic. Surely Apple wouldn’t make Swift available unless it was, at least, really close to being ready to use. But was jumping on the razor’s edge worth risking the viability of our first application? One final prototype was in order — get the major use-case of Stringer functional within a week, using Swift. If it worked with no major hiccups, we’d move forward.

There were many hours of doubt in that week, but once the syntax was figured out and the new structure for method calls was deciphered, we had a functional Swift prototype and the confidence to move forward.

Swift was buggy. Or, it kept changing. Swift was buggy and kept changing.

Without a doubt, we knew our decision to use Swift would bring with it an unknown level of torment and frustration. With each new beta release came the inability to build our codebase, followed by hours of figuring out just what had changed. The proverbial cherry was the stability of Xcode, or the complete lack thereof. Time spent restarting Xcode after endless crashes was substantial, to say the least.

The biggest hurdle however, was the complete lack of a community to work with. With Objective-C, when you hit a snag you can tweet for help or open your resident Stack Overflow browser tab. Not with Swift, particularly at the time when we were neck-deep in primary development. For this reason, the amount of “trial-and-error” programming was higher than we probably would have liked. When the app wouldn’t build, or was not acting as expected, we did not know if we had implemented APIs incorrectly, or if Swift was just not doing what it was supposed to do. To boot, documentation was close to non-existent.

We had a lofty goal of launching with the release of iOS 8, but the volatility of Swift quickly pushed us into a more measured and realistic plan that waited for greater stability, which finally came with the GM release.

Leading the way.

We certainly aren’t revolutionaries, as there are probably plenty of purely Swift applications in the market at this point, but there are a few additional benefits we’ll recognize with the early adoption.

Derby was able to form and focus its efforts, uninterrupted, thanks to what we built at Nickelfish. Using Stringer as the test bed for Swift, we can now quickly migrate the much larger client services team without having to factor in the large learning curve to a project schedule or budget. Having in-house knowledge of Swift will aid both companies in moving forward on the platform.

Finally, we are fully prepared to follow Apple down the Swift wormhole. Lets face it — they probably won’t support two languages for very long. If history is any indication of how this will go, developers will need to jump on the Swift bandwagon pretty quickly. My speculation? Objective-C is deprecated for iOS 9 and only Swift applications will be accepted for submission to iOS 10.

(Seth doesn’t agree. Sounds like a two-year wager is in order.)

Is Swift right for you?

If my speculation is correct, then yes. Swift will become the de facto language for developing on Apple platforms, so you’ll need to make the jump one way or another. However, the decision to use Swift today will most certainly be made by more important business factors.

The immediate switch to Swift may not make sense if you have an existing Objective-C codebase that hardly changes. Unless the application has a healthy revenue stream that would support a complete re-write, you’ll probably just stick with what you have until the Apple ecosystem no longer supports it.

Timing is also a concern. If you are in client services and need to deliver a project on a tight schedule, it may be best to stick with what you know best, at least for now. This is particularly true if the project is adding new features to an existing application.

Today, Swift is best when you have a fresh start, like we did with Stringer. If no lines of code exist, jump outside your comfort zone and make sure you are able to keep up with the big platform changes Apple has in store for us. Documentation is more thorough, the tools are more stable, and most importantly, the support community is growing rapidly.

We are thrilled to be a part of Swift from day one, and look forward to participating in its maturation over the coming years.