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.
✅ 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.
関連記事 | Related Posts
We are hiring!
【KINTO FACTORYバックエンドエンジニア(リーダークラス)】KINTO FACTORY開発G/東京・大阪
KINTO FACTORYについて自動車のソフトウェア、ハードウェア両面でのアップグレードを行う新サービスです。トヨタ/レクサス/GRの車をお持ちのお客様にOTAやハードウェアアップデートを通してリフォーム、アップグレード、パーソナライズなどを提供し購入後にも進化続ける自動車を提供するモビリティ業界における先端のサービスを提供します。
【ソフトウェアエンジニア(リーダークラス)】共通サービス開発G/東京・大阪
共通サービス開発グループについてWebサービスやモバイルアプリの開発において、必要となる共通機能=会員プラットフォームや決済プラットフォームなどの企画・開発を手がけるグループです。KINTOの名前が付くサービスやKINTOに関わりのあるサービスを同一のユーザーアカウントに対して提供し、より良いユーザー体験を実現できるよう、様々な共通機能や顧客基盤を構築していくことを目的としています。