Shipping with Swift

Being a developer tied to a platform run by one company, I listen carefully to the messaging around new tools which support that platform. Swift was delivered with strong messaging and that messaging has continued in the months since its announcement at WWDC ‘15. I believe strongly that Swift is the future of iOS. You can read my initial thoughts on Swift, here.

With growing support from within Apple (including Tim Cook on multiple occasions), I decided in September to take a serious look at Swift. Since it wouldn’t be prudent to start working Swift into our flagship social product that I develop (along with a great team) at Salesforce.com, I decided instead to build a personal project that I’ve wanted for some time. That project became Wealth+, a personal net worth tracking tool. A simple app, but one which would allow me to work towards shipping a Swift app to the App Store. Several months later, I shipped Wealth+, fell in love with Swift, and have encountered only two app crashes since launch. Here are my deeper thoughts on Swift.

Concerns I had going in #

Can I leverage old Obj-C code effectively. YES! It’s been incredible to experience how simple it is to leverage code from my existing apps written in Objective-C. A simple bridging header is all that’s required. On occasion, I have found it a bit cumbersome to switch between languages in a single coding session. However, as long as the code you’re reusing is worth the overhead, then I think mixing is a fine approach. In a few years I’d expect that I’ll have very little Obj-C remaining in my smaller apps. For larger Obj-C apps the language mix may persist for much longer.

Can I use 3rd party frameworks like Google Analytics? Again, YES! It was very simple to add Google Analytics (an Obj-C library) to my project with very little effort. Within minutes I was able to use the GA framework in a Swift file. Almost as if Swift was its native language.

How hard will it be to learn the syntax? Although I’m still getting faster at Swift, and learning new language features with time, I found that it only took a matter of days to become reasonably productive in the language. As you’ll read below, there are many syntactic benefits which will make you faster overall, even when in the beginning you’ll be slower while flipping between docs and code. I learn best by writing, but I did start my time with Swift by reading the Swift Language Guide from Apple. After reading, I probably stumbled most on optionals. I found myself reading the section on optionals several times before it really started to click. I also found this article by Richard Turton, quite helpful. My approach was to start Swift development by using only patterns and language features which were already available in Obj-C. This allowed me to get started fast without worrying about the best possible way to structure my code. Over time, I’ve introduced more structs, tuples, closures and other great language features that make Swift so powerful.

What I love #

No semi-colons. So weird how dropping one character from each line can be so liberating. Definitely not a huge productivity boost, but it sure feels like it. Only issue is that semi-colon usage is probably the thing that catches me most when I flip between Obj-C and Swift.

Tuples. Super handy to be able to return multiple values from a function without encapsulating in a separate class. Handy, though not compatible when bridging to Obj-C, so I’ve limited my use in mixed code projects.

No header files. I thought I would miss the clarity that a public header provides, but I really don’t. Having a single file to describe a class has made refactoring code so much faster and there are far fewer places to look for stuff - the benefits outweigh the drawbacks. For now, I simply keep public stuff at the top of a class though may look into using protocols for making the public interface a little more explicit (something I picked up from this episode the iPhreaks Show podcast, with guest David Mauro)

Less code, but still expressive. In general, Swift enables me to write less code meanwhile maintaining readability. Sure, you could go all the way with Swift language features and write super-dense code, but I’d worry that you’d leave some team members behind (including me). However, I’ve found it pretty easy to write less code that still reads well. I’m definitely faster writing Swift than Obj-C, though will admit that it’s a little difficult to quantify.

What I didn’t love #

Trouble automating upload to iTunes Connect TestFlight using Xcode Bots. I have filed a Radar on this, but I ran into trouble getting my Xcode Bots to upload a Swift app to iTunes Connect in a post build trigger script. This was disappointing as I’ll really want to do this when I move from building a personal project to building a larger enterprise app at Salesforce.com.

Optionals, at first. As mentioned, optionals were the language construct which tripped me up most. I think what I was missing was the context for what they were meant to solve. Now that I understand their intent, they have become much easier to work with. Optionals are really all about making nil-handling clear to developers looking at the source code, with the goal of fewer app crashes - which seems to be holding true for me. In Swift 1.2, the latest release, it looks like Apple is making optionals even easier to work with and I expect this will be a continuing trend.

Source kit crashes. Lots of community complaining about this, though not even close to a show stopper for me. It’s clearly a bad bug, but I have been able to work around it without losing too much productivity. Looks like an upcoming release of Xcode resolves this issue, as I would have expected. Apple usually does well prioritising the bugs that hit most developers, and this was definitely one of those bugs.

Slow code completion running on a 2011 MacBook Air (not an issue for MacBook Pro 2014). This was probably the #1 hit to productivity as I’d often wait over a second for auto completion to kick in for Swift API. Had to train myself to type a little more to coax the auto complete to work a little faster. Though my #1 issue, it still doesn’t register at a level that would cause me to consider dropping the language. Might be a good reason for a hot new Mac Pro, though.

Truth (for me) #

It’s fun. It’s a lovely language and a hell of a lot more fun than writing Obj-C. This is coming from the guy who thought developers were crazy to be demanding a new language leading up to WWDC. Now that I have Swift as an option, there’s really no going back.

I’m faster (perceived and real). Switching between the two languages has me convinced that I’m already faster on Swift. In fact, I think I was faster on Swift within a month of part-time coding.

I’m still able to switch back to Obj-C and be productive. It’s a little painful to switch back, but I have found little issue switching between the languages. Would I prefer a single-language project? Yes, definitely. But if there is value to be gained by mixing languages, then my experience shows that moving between the languages is quite doable.

Future of Swift #

• It’s here to stay. No question.
• It’ll be what new devs learn first, starting today.
• It will bring new developers to the platform. Obj-C syntax was gating for some.
• Apple will more likely provide syntactic sugar for Swift while letting Obj-C languish.
• The functional programming hype will calm, but hybrid practices between OOP and functional will emerge.

Final Thoughts #

If you’re a developer getting into iOS for the first time, look to Swift. If you’re an Obj-C developer starting a new project, look to Swift. For the rest, it’s a tougher call depending on circumstance, but you could probably guess where I would land. I feel that Swift is 100% ready for production apps and even though the language is evolving, and issues do linger. I trust that Apple will provide the right level of migration tools to keep the pain minimized and will keep improving the tools rapidly. I see no reason to wait, the time for Swift is now.