When Apple first announced Swift at WWDC 2014 I was very interested yet somewhat terrified. Just thinking of the gotchas and intricacies of Objective-C, made the idea of learning a new language that had yet to hit v1.0 seem pretty daunting. Also, like most people working with existing code bases, I don’t have the luxury of rewriting everything in Swift. But after tinkering around with the language (followed by some great talks at the NSSpain 2014 Conference), I was inspired to begin shipping production Swift code at TaskRabbit.
###TaskRabbit and TDD TaskRabbit’s iOS projects have been TDD from the beginning. Version 1.0 shipped with an extensive Cedar test suite and was migrated to Kiwi when we moved to version 2.0. Now, our shared code library, our version 3.0 client app in the app store, and our enterprise Tasker app have all been built using TDD and Kiwi. When I decided to start introducing Swift to our TDD project, there were very few options for how to continue testing.
###Options To Continue TDD With Swift Almost immediately after Swift was announced two new TDD/BDD frameworks, Sleipnir and Quick, appeared on Github. I chose not to use either of the these frameworks because I would have had to create another test target that would run separately for the new Swift code. I chose instead to move forward with bridging, and write tests for the new Swift code in Kiwi.
###Things To Know About Using Swift With Objective-C
The Swift compiler generates a header by default with the filename
ProjectName-Swift.h for the public classes and methods you create. The tricky thing is this file gets generated for the target that contains the Swift source file. With Kiwi, your app target is a dependency of your specs target so your specs target will not be automatically linked to this generated header. You’ll need to add
to the User Header Search Paths of your build settings for your specs target. Then you can simply import
ProjectName-Swift.h in your spec files or in your specs precompiled header if you use one.
###Wrapping Up This is still a work in progress. I’ve tried many tactics to accomplish the things needed to use Swift within a full-scale test-driven Objective-C project and this are some of the things that have worked for us thus far. There are definite drawbacks to using Swift and Objective-C with bridging, such as some pure Swift features may be unavailable. We have had Swift code live in production for over 6 months and are looking forward to the future of the language. I would gladly accept questions, comments, or suggestions of how others can have integrated Swift into their existing workflow.