Rapidly Bringing iOS App Development In-House

Introduction

Hi, I'm Hinomori, an iOS engineer in the Mobile Development Group. With over 10 years of experience in iOS app development, I work as a senior engineer handling day-to-day development tasks. Today, I’d like to share how simply going about my usual work eventually led to full in-house development.

The Situation at the Time

With only two months left until release, development was being handled mostly by an external vendor, who reported the project was already 70–80% complete. However, the management team was new to smartphone app development and seemed uncertain about how to provide clear direction. In that situation, two iOS engineers, including myself, were brought in to join the development team.

It was in this situation that two iOS engineers including myself, were brought in to join the development team.

Pinpointing What Needed Improvement

I still remember feeling slightly dizzy when I first opened the repository. What I found was an impressively tangled mess of spaghetti code.

Jumping straight into a major refactor right after joining and trying to coordinate that with an external vendor would have come with a huge communication cost. So instead, we let the vendor continue development as planned while we focused on understanding the specifications and working on the refactor in parallel.

At that point, there were three major areas for improvement in the code:

⛔ An underutilized CI environment

⛔ No consistent architecture

⛔ Singleton classes were being called from everywhere without control

There were plenty of other smaller issues too, but we decided to start by tackling these three as our main improvement tasks.

Large-Scale Refactor

Once we had a rough plan in place, we decided to start with improvements that didn't directly touch the code. From there, we gradually worked our way deeper into the internals.

✅ An underutilized CI environment

The CI environment technically existed, but it was barely being used. So we set up a proper CI workflow that could regularly handle the following two tasks:

• Static code analysis
• Running unit tests

At the time, the unit test coverage rate was 0%. Since increasing it immediately wasn’t realistic, we started by simply displaying the coverage rate and focused on establishing a basic review environment.

✅ No consistent architecture

While there were traces of an MVVM structure, in practice, the processing wasn’t properly separated from the View. In most cases, the ViewModel was just a placeholder and didn’t function as part of a real architectural pattern. To address this, we introduced Clean Architecture principles into the existing MVVM setup. We implemented a consistent pattern across all ViewControllers and ViewModels, where the ViewModel handled Publishers using clearly defined Inputs and Outputs. We also moved unnecessary logic out of the View and into the appropriate ViewModel or Model layer.

Koyama-san wrote an article that covers the development approach we used. If you're interested, it's a great resource for understanding the structure in more depth.

https://blog.kinto-technologies.com/posts/2022_12_07_Combineを使ってMVVMを実現した話/

✅ Singleton classes being called from everywhere without control

The Singleton pattern is convenient and easy to use, but it is also often misunderstood. When misused, it can quickly lead to tight coupling, increased complexity, and poor testability. Without careful handling, it can quickly become a black box. This pattern can be especially risky in a team-based development, so we began removing classes that were being used as uncontrolled singletons

By completing these three tasks all at once over the course of a month, the overall visibility of the codebase improved dramatically. As a result, we were finally able to trace the actual specs incorporated in the code, and feature additions became much smoother and more manageable.

Moving into Team Development

Once the large-scale refactor was done, it naturally became faster for us to handle development ourselves rather than relying on the vendor. At that point, we were able to fully take over the development work. That said, all we had at that stage was a solid foundation for team development. There was still a lot left to do, such as expanding the lacking unit tests, organizing data flow, refactor the UI, and more. With a solid foundation, PR rules, branching strategy, and review flow in place, the team gradually built a consistent coding philosophy. Even as the team grew, the code stayed clean and manageable and members' review feedback became more focused. I feel we've become a self-sufficient team.

👨‍💻👩‍💻

Currently, we're taking on the challenge of SwiftUI and modern architecture as a team, learning through trial and error so we can all grow with today's development methods.

Finally

At KINTO Technologies, we are actively looking for teammates to take on new challenges with us. We look forward to the day we can build a team together.