// MailChip Integration // Lottie Animations Integration
SkySpirit Labs

Believe in the power of innovation to shape the future with the technology.

How to Refactor Obj-C to Swift With Minimal Effort

WTF per minute > 5 = Start refactoring right now

What is the meaning of refactor? — Refactoring consists of improving the internal structure of an existing program’s source code, while preserving its external behavior.

Introduction

When inspecting someone else’s code I’m sure that you got your moment and thought “WTF is this?”, “WTF this do?”, “WTF, this makes no sense!!!”. Maybe not exactly this way. But if confused, dark, disappointed, and sometimes even agree, feeling run across you. Then “WTF per Minute” is the measurement for the “should you do refactor?” question.

WTF per Minuter for Refactor
WTF per Minute

Don’t get me wrong, the “spaghetti code” is not always to blame the previous developer. Maybe the developer had not enough insight into specs. Or had not enough knowledge for this challenge. It could also be that technical debt is introduced by business, manager, product owner, or investors. By rushing the developers to do something faster, than the required minimal quality was necessary for the feature. But let’s get back to the article focus and to the point where we can do something about the issues.

By the way, 5 in the title is just a representative number. Every project, team setup, project has its own value.

How Do I Start Refactor?

If you had a situation where some of the project parts have huge legacy code. You were planning to refactor it. But every time you start, you quickly realise that it has too many dependencies, too many lines. Red compiler errors blind you with every small code change. Then quickly decided it is too much hassle and energy to refactor. And then you have just dropped the changes. Delayed the refactor for some next occasion and took the next task. If this feeling is familiar to you, then this is the right place. I had the same issue as I had the impression that refactoring means that you need to do it at once and perfectly.

When we developers start to build some software, we are doing it in iterations. Breaking down the system into small, organised chunks of code. Smaller meaningful tasks and stories. Sometimes while developing you figure out that something can be done better.

This principle is the same when you want to refactor some legacy code. Don’t aim to find the perfect solution. Just start it right away when you figure out that this class has 1000 lines. Just start when you get multiple answers for the question “What this class, method job is?”. Just start and you will improve the refactor in interactions. Otherwise, it will remain a well-known technical debt. And even it will grow when new features need to be integrated on that class, system.

Code to be Refactored
Code to be Refactored
Way to Refactor Option 1
Way to Refactor Option 1

The image above is the way to refactor for languages that have no option to extend the class like in Swift language with Extensions.

Refactor in Swift Language
Refactor in Swift Language. Way easier.

How To Start Refactor Huge Legacy Files

If you don’t know how to start and don’t understand the code that you want to refactor. Add bunch of // TODO: — Description what you discovered. I know that lots of people will tell me, but methods and classes that need huge comments have bad naming, not descriptive or self explaining enough. And that is true.

But remember, readability is one of the most important things. This is maybe legacy production code that is doing its job perfectly, for now. But we don’t understand it and are afraid to change it. Or to build some feature on top of it. So add comments as much needed till it will be slowly refactored, then we can slowly remove also these comments. Our end goal is to have Clean Code at some point. Maybe it will never happen, but we will be closer and more satisfied.

Example of TODO

Often see Singletons or dependencies initialised inside the class. Let’s say we are focusing on resolving some issues.

We need to focus on our current task, feature development. All these bad code distractions that we find in our development, should not be addressed right away in most cases.

Every time you find something, time-box it to a couple of minutes, hour. If it can be fixed fast, do it right away. If you find it begins to be an endless job, stop. The code is already in better shape by 1%. Just write a comment for yourself or the next developer based on your finding and understanding. These directions will be helpful next time you wonder about the same part of the code. 1% improvement per day is ±120% improvement in 6 months if you work 5 days a week. And this is per just one person. As you can see, persistence with small changes comes to the spotlight fast.

How Refactor Huge Legacy Code With Help of Swift Extensions

Start to create an extension of the class that you want to refactor. In Swift it is an easy way to separate some logic. Create “shadow” methods and slowly extract out the content.

Files in Project. Extension of Refactor class
Files in Project. Extension of Refactor class
func someBadMethod() {} // This is what need to Refactor
func wrapperSomeBadMethod {} // New Shadow method

Even if we don’t refactor it fully, at least not implement new changes in already considered technical debt files, classes. All new changes would go into these shadow methods.

In the case of Objective-C it is a bit more complicated to configure. It is just a couple of steps more.
Make sure that ModulName-Bridging-Header.h is added to the project.
Make sure that #import “ModulName-Swift.h” is included into .m file what we refactor. As otherwise swift classes will be no visible by objective-c files.

Obj-C File and “someBadMethod” to Refactor

Refactored Obj-C class

All new changes then go into extension.

Swift Extension of Obj-C File

In case we need to extract some of the lifecycle methods.

Lifecycle Method call of Extension ShadowMethod

ShadowMethod

I call it the “Shadow” method. You can call it Wrapper or any prefix. Important is that you are consistent and your team understands the principle.

When this first step is done and your Obj-c UIViewController or Service is almost clean. Then just convert to swift class and copy the changes from shadow methods back. It is just like splitting into smaller parts to be able to reshape faster in a better way.

Tools for Obj-C Refactor

The best tool that I have used is Swiftify. It has the ability to convert Objective-C code to Swift. In the free version, you can convert a small part of the code. If you want to convert whole classes at once then a paid version is required. In my case, it really speeds up the refactor.

Online Tool Swiftify for Refactoring
Online Tool Swiftify

Code Refactoring Best Practices

Based on my experience I have some rules that helped me to speed up the refactor or to generate neat clean code.

  • Functions should only do one thing
  • Use private, public access control for easier code readability. Lots of developers neglect this and just create default functions. Just by dropping a look, we can’t decide if this is some internal logic function or public interface.
  • Make your conditionals descriptive enough. Comment if you simply did not find the right naming for method, class. You will forget and slowly nobody will know what it is, it’s a job.
  • Don’t make everything constant. If something is used just once it should stay at it. If it is used on more occasions then it is configuration/constant.

Tips

  • Create after every feature Code Cleanup task. So management knows that you need some time allocation for this. If you figure out that your code is already perfect, even better, then just skip the task. Important is that you have a reminder that every time do one more small assessment while everything is fresh
  • Have something like R&D Friday. You try to improve something or introduce some new tool, feature, to implement some idea fast. This code does not need to be clean or fully finished. Just to see PoC that is something achievable and the direction. If you can prove that something has value or benefit, usually it will be accepted to be developed.

Outro

In the end, refactor aim is to get to the clean code perfection or at least close as possible with our ability. Clean code is something that we never achieve but want to get as close as possible to it. Better to do it all the time, after every feature small code cleanup / refactors.

Otherwise, at some point, you will look the code and say “WTF is this” while figuring out that you wrote this part of the code a couple of years ago.

If you got to this point, thanks for reading. You deserve a coffee ☕️. 🙂 If you like the content please 👏, share, subscribe, buy a coffee, it means to me. If you have some suggestions or questions please feel free to comment.

Next Post

Previous Post

Leave a Reply

© 2025 SkySpirit Labs

Theme by Anders Norén