At Duo, we find ourselves increasingly utilizing the Swift programming language for internal projects and always like to offer tools to our customers to use our APIs. As a relative newbie to Swift myself, I thought converting the DuoAPISwift would be a great way for me to take on a lightweight project in Swift and learn a thing or two about the language in its latest iteration. So last week I began the task of converting our Duo Auth API client to Swift 3.
The first step for most when it comes to Swift conversion seems to be to pray and the next is to run the automatic conversion tool in Xcode. If you’re one of the lucky ones, everything may build fine and no new bugs will be introduced. Of course, this is almost never the case. We were no exception, the tool did do a lot of the major leg work, but we did have to spend a bit of time getting everything working again afterwards.
One of the simplier things the auto conversion tool commonly missed was the change required to mark closure arguments as escaping. We had to go back and make sure that all of our block method parameters were correctly marked as escaping when they did so. Simple enough!
The largest issue we dealt with when converting to Swift 3 was due to the changes in implicit bridging conversions. Specifically, we had a lot of implicit casts in method parameters as we passed around String/NSString types as AnyObject types. As we went through and added our explicit casts we realized just how much implicit conversion we were relying on. Our method parameters, often being AnyObject types, can sometimes be hard to understand and easily used incorrectly. It became clear through this conversion that our next version of the DuoAPISwift should address this by making our types more explicit and reducing the amount of casting.
In all, this project was a simple one that gave me a good overview of some of the new features into Swift 3. It reminded myself and others how important it is to keep up to date on a language like Swift that’s changing so quickly. And it’s even more important to make sure we design APIs that are explicit and eliminate potential confusion as much as possible.