At Intuit we work in 2 week sprints. Last sprint I decided to take a story about a crash happening in an image downloader class. After looking at it for a bit, I decided it would be a great candidate to rewrite using dispatch groups, and also in Swift. (It’s an internal goal to rewrite when we can in Swift).
At first it was rough going and slow. The write a test, run it, and fail felt far slower than just writing the class from scratch, and then debugging it inside the app.
But – I really wanted to give it a try, so I changed my layout in Xcode. Instead of having the source in my left source panel in Xcode, I decided to put the unit test file there. And then on the right side I split that into two panels: the new Swift downloader source, and the old Objective C source.
That changed my focus from writing the source, to writing the tests, and then making the tests pass. I know it sounds like a small thing, but for me it really worked.
I also decided to embrace the “slowness” of TDD. It gave me more time to think about what I was writing and how to make sure it covered all the cases.
In short, something I feel I could have finished in a few days (with no tests) took me 5 days (along with meetings, production support, etc). But I got into it and really enjoyed it. I’d recommend you give it a try!
If you’ve started down the road of incorporating Swift into an Objective C project, and run into an error when adding calling a method in your Swift class that Xcode says isn’t there, or doesn’t autocomplete, try the following:
Add your #import “module-Swift.h” to your Objective C .m file. (In my case it’s #import “AppName-Swift.h”.
If that doesn’t work, recompile. You’ve probably just added a method in your Swift file, and Xcode needs a chance to compile it and add it to that auto-generated module-Swift.h file
Hopefully I’ll have more tips as I use Swift more and more at work. Stay tuned.