Rewriting a Mac App in Swift
Brad Larson (tweet):
We believed that redesigning this application using Swift would allow us to create a safer, more maintainable, and more testable application. Not only did we achieve those goals, but the resulting application is more responsive, nearly doubles the printing speed of our systems, and has a slew of other improvements.
[…]
The Swift version of our Objective-C application, with the same user interface and features, is only 39% as large. […] While a chunk of the code reduction is due to removing redundancies (replicated definitions in interfaces and implementations, etc.) and abandoning my trusty Allman indentation style, most is due to better code reuse and better design that Swift encourages.
[…]
However, I have only become more convinced over time that there should be the ability to specify error types in the Swift 2 model. […] At present, I have no way of telling the compiler that the only error type a function should return return is a RoboticsError, so if I miss a conversion from a CommunicationsError to a RoboticsError at some point, I'm accidentally bubbling up a generic CommunicationsError and losing error recovery information (and potentially exposing myself to a crash if I make assumptions about error types higher up).
[…]
The ease with which you can create lightweight data types in Swift also worked for cases where we were getting physical units mixed up in our code. We created small structs for frequency units like Hertz and Kilohertz that were incompatible and used them to make it clear when we were using one unit and when another. Conversions were made explicit, and it was easier to read the code of many functions.
[…]
Could I have done this in Objective-C? With blocks, yes in most cases. Swift just makes this easy, so I started thinking about problems in a different way.
