As part of my internship at Oberon — a software company in Amsterdam — I have recently rewritten the business logic of an iOS app from Objective-C to Swift. The app is My T-Mobile. The Swift version was 3.0 at the time. In addition to rewriting the business logic, I wrote a research paper on the impact of Swift.
To put it into context, Swift is now the de facto development language at Oberon in iOS since the release of Swift 2.0. Since the My T-Mobile app is one of Oberon’s longest running apps and written in Objective-C for 80%. Oberon felt that the software quality would increase when the app runs on Swift. And so it fell to me to rewrite the business logic, as it is the most used part of the app, but unlikely to get rewritten to Swift during the natural course of development.
DEFINING SOFTWARE QUALITY
For my research paper on the impact of Swift I needed to define software quality. I decided to use the CISQ (Consortium for IT Software Quality) model. The standards for CISQ are based on the ISO standards but put more emphasis on the source code, which matched my project perfectly, as I was working with and rewriting source code.
The CISQ model puts its focus on four characteristics: Reliability, Performance effeciency, Security and Maintainability.
I decided to focus on the Maintainability aspect of the model, because Swift’s features and standards have the highest impact on those aspects of software quality:
- Unstructured and duplicated code
- High cyclomatic complexity
- Hard coding of literals
- Excessive component size
- Duplicated business logic
- Compliance with initial architecture design
- Strict hierarchy of calling between architectural layers
In this article I won’t be putting focus on these points as these are only needed for a little bit of context.
THE PROCESS
Because a lazy programmer is an efficient programmer, I started by looking into Objective-C -> Swift converters.
There were quite a few:
They each had problems, however. The first two options aren’t free and can only convert a couple of dozen lines at a time. The last could not be used with Xcode 8, because plugins have been deprecated for Xcode.
Even with the converted code, it always felt to me that it was a direct translation from Objective-C to Swift. For example, a converter can never translate Objective-C code in a way to display guard statements or let patterns to provide safer code.
Another thing one needs to take into account is that Swift and Objective-C have different coding paradigms, so one would, by using a converter, not be able to achieve that and would also have to review the code and change it in a way that is more Swifty. Sounded like a lot more work to me than beginning from scratch.
In short, I decided to rewrite and refactor the app by hand, instead of using a tool.
As a person who had no experience with this project, understanding the code was difficult. For example, the old Objective-C code, when using types like NSArray or NSDictionary, was harder to infer what kind of objects went in.
During the refactoring process I noticed that functions and properties became clearer as their types were declared explicitly, especially for arrays and dictionaries.
Another advantange was that Swift’s single files made navigating through the whole project window more pleasant than with the Objective-C two-file counterpart.
After the whole business logic was refactored I had to find out what kind of impact it had on the software quality.
Since this article is about the impact of the use of Swift, I decided to use a tool called SonarQube, an open source platform to inspect the code quality.
The initial results looked like this:
As you can see, maintainability, security and reliability were exactly the same. The Swift version had 1000 lines of code fewer, and a bit less duplication, but these differences weren’t exactly earth-shattering. So I dove a bit deeper into the SonarQube findings.
I discovered the following:
If you ignore the new code smells — you don’t get new code smells when you don’t change the code — you can see that the Swift version has fewere code smells than its Objective-C counterpart.
I took a look into the code smells and and discovered there was one code smell completely absent from the Swift version: Cognitive complexity.
Cognitive complexity attempts to put a number on how difficult the control flow of a method is to understand, and therefore to maintain.
SonarQube marked the above snippet of Objective-C as too complex, mainly because it rates nested logic harshly.
Swift allows removal of type and null checks without compromising type and null safety. That way the cognitive complexity is lowered significantly.In Swift needing to check if object y is a kind of class x is not needed as specified arguments in functions can never be of another type (Type safety in Swift.).
In the end refactoring the app from Objective-C provides the company with numerous pros, but also cons.
PROS:
- One is less prone to code smells when writing in Swift.
- At our place it’s harder to find iOS developers nowadays and the new iOS developers often start with only Swift knowledge. They can pick up the project more easily if it is written in Swift. Swift is also a lot less intimidating than Objective-C when recruiting developers for iOS within the company.
- With developers able to pick up the project faster in Swift, clients don’t lose much time on knowledge transfer which in turn means that developers are able to develop faster which also in turn saves up money for clients.
CONS:
- Rewritten classes need to be retested. This can be time consuming.
- One is prone to mistakes when rewriting classes.
- New versions of Swift are released regularly and often have breaking changes. This adds maintenance times several times a year. Objective-C is stable as a language and no breaking changes have been introduced in over a decade.
THE VERDICT
For us at Oberon, it was worth it. I received very positive feedback from co-workers, especially that the business logic of My T-Mobile is now much more pleasant to work with.
In addition, several co-workers are much more adept at Swift than Objective-C and this conversion saves them from the investment of learning an extra language. Based of the SonarQube analysis I would also say that the app has improved from a maintainability perspective.
Despite these positive experiences, I would like to offer a caveat. I have not looked at other quality aspects, such as performance metrics or security. Therefor I cannot recommend a rewrite for any other reasons than readability and maintainability, and even there, your mileage may vary.
