Transitioning to Swift
iOS community has enthusiastically accepted Swift as the successor to Objective-C. iOS developers feel excited when they get to implement a new app or a feature in Swift. The open-source community has been voraciously contributing to the ever growing collection of third-party libraries written in Swift. Apple has also made it clear that it will be investing heavily in the advancement of Swift. WWDC is right around the corner and I can’t wait to find out what new features we will get from Cupertino.
Sorry we’ve been quiet for a while. Working on something…
— Swift Language (@SwiftLang) May 28, 2015
Because of all these reasons, you might have finally been able to convince your team to transition towards Swift. Here are some tips that might be helpful during the transition.
Training #
Ideally you want everyone in your team to get up to speed with Swift quickly by reading books, blog posts and open source code. However, everyone is busy and it is hard to find time to learn a completely new programming language in a short period of time. Therefore, those who have more experience with Swift should pair frequently with less experienced to transfer knowledge quickly. If someone in your team is not quite motivated to learn a new language, schedule 1-1 meetings with them to teach the basics. If you want the transition to be quick and successful you need to be aggressive with knowledge transfer.
If someone in your team is particularly good at teaching, free up that person’s time so that he or she can focus on bringing the team up to speed.
“A great team is composed of engineers who complement one another.” - Jocelyn Goldfein
One of the most effective ways to demonstrate how Swift applies to the development of a production app is to organize a workshop. Create an example app that demonstrates various aspects of an iOS app, for example communicating with remote and system services, persisting data locally, and building complex yet fluid UI with Core Animation. Build this app live again with your team during the workshop. This also gives you an opportunity to show how general software design and testing best practices apply to Swift.
Although Swift is a different programming language, you will need to use the same underlying frameworks provided by Cocoa Touch that you used to call from Objective-C, for example UIKit, Core Data, Core Location, etc. Therefore, transitioning to Swift should be relatively easy for iOS developers with some Objective-C experience.
If someone is completely new to iOS development, make it very clear to them that they need to learn both Swift and Objective-C. The transition towards Swift will take time and there will still be plenty of Objective-C code around for them to read and extend.
There are plenty of resources out there for learning Swift. It might get hard to know where to get started. Just ask everyone in the team to check out the freely available official guide to Swift first. It provides a good introduction to Swift. I also recommend checking out the Coding Explorer blog. It explains, in a very accessible manner, how various features in Swift work. Finally, checkout the LearnSwift.tips site for a curated list of helpful resources.
Testing #
Decide which testing framework to use early on. Write some tests in XCTest. Re-write the same tests in other frameworks, for example Quick. Ask your team members which one they are most comfortable with. This is especially important, if your team doesn’t have a strong automated testing culture. You need to take away as many excuses as you can for not writing tests.
If the majority of your existing tests are written in Kiwi and your team is accustomed to writing tests in Rspec style, it might be easier to transition to Quick than XCTest. Otherwise, XCTest might be a better fit.
Deciding What to Implement in Swift #
Swift’s interoperability with Objective-C is quite amazing. You can easily call Swift code from Objective-C and vice versa. This allows you to fully implement a new feature in Swift without having to rewrite the existing Objective-C project in Swift first. That said, being strategic about which new feature gets implemented in Swift might help you manage the risk, especially if an important deadline is looming. During the planning phase, identify which user stories are good fits for implementing in Swift.
Resist the temptation to re-write existing Objective-C classes in Swift. You have already put a lot of effort in making these classes reliable. You won’t be gaining any additional value by re-writing them in Swift. There is a greater chance that you might introduce bugs if you rewrite them. Even if you have good test coverage, I still recommend against the rewrite.
A good rule of thumb could be to implement all new classes and tests in Swift. You will be surprised how much progress you can make without much risk if you follow this rule.
Coding Guidelines #
Create a style guide that outlines the Swift coding conventions for your team. A style guide makes it easier to keep the code in your project readable and consistent. Although the iOS community is still figuring out best practices for writing good Swift code, you can borrow a good amount from the guides published by Github and raywenderlich.com.
If you have a culture of reviewing each other’s code, make a note of styles you agreed on and add them to the guide immediately. Important thing is to get started. You can keep adding new conventions as you discover them.