I modernize legacy iOS codebases — Objective‑C → Swift migration, test coverage from 20% to 80%, modular architecture — without stopping feature delivery.

10+ years of iOS engineering · Jakarta (UTC+7) · works remote
Case study 01

An Objective-C → Swift migration, owned end to end

Quadrant · iOS Engineer · 2020–2022

Sole iOS engineer on a codebase that was framework code — no UI — distributed to partner companies under formal agreements, so API stability and documentation mattered more than pixels. All of it was Objective-C. Nothing was on fire, which is exactly why nobody had touched it: obsolete, harder to maintain, harder to hire for — and every year of waiting made the migration more expensive.

I made the business case for Swift myself, then executed it: a complete rewrite in about two months, keeping the frameworks stable for the partners consuming them. Solo meant owning every step — proposal, plan, code, docs.

The result: a 100% Swift codebase with lower maintenance overhead. The point isn't scale — it's having run the full migration lifecycle, pitch to done, and knowing where the traps are.

Case study 02

Test coverage 20% → 80% on a large telco app

Aleph-Labs · iOS Engineer · 2024–2025 · client unnamed by agreement
Context

The self-care app of a major telecommunications provider — quota, balance, packages, top-ups, bills. A large, legacy-heavy codebase with an active release train that could not stop.

Problem

Coverage sat at 20%. Much of the code wasn't written to be testable, which blocked automated testing and threw the load onto manual QA.

Approach

Built the missing test infrastructure first — helpers like method swizzling for test targets that made untestable legacy code testable without rewriting it — then documented standards so new code stayed testable by default.

Outcome

Regressions dropped, QA got faster, maintainability improved — all delivered alongside key features and critical bug fixes, not instead of them.

20→80%
unit-test coverage
Case study 03

Developer tooling for a 20-engineer iOS team

Style Theory 2018–2020 · Ruangguru 2022
Context

Product teams where the bottleneck wasn't features — it was the developer experience around them: manual processes, scattered CLI tools, knowledge locked in one person's head.

Approach

Introduced tooling and design patterns with the trade-offs laid out, set up CI/CD with Jenkins, and worked on an internal CLI that unified multiple tools — proposing a Swift rewrite of its Rust core so any of 20+ iOS engineers could extend it.

Outcome

Tooling the team actually used, a working CI/CD pipeline, and — the informal metric — being the person other iOS engineers came to when they were stuck.

Tooling a 20-person team can extend beats tooling only one person can maintain.

How to work with me

Three ways, pick what fits

01

Full-time iOS role

Senior engineer for a team with a large existing codebase that needs modernizing while features keep shipping.

02

Contract modernization

A scoped engagement: Obj-C → Swift migration, test infrastructure, CI, or Tuist/XcodeGen modularization on your codebase.

03

iOS instructor

Led a 3-month Swift & UIKit bootcamp at Phincon Academy; authored training materials and workshops at IMA Studio.

Email me Not sure which? Describe your codebase.
From the lab

I think in products

Some ideas stay concepts; some graduate. The shipped ones are live.

migration plannerconceptStatic analyzer that maps an Obj-C codebase and orders files by migration cost and risk.
testability doctorconceptScores an iOS codebase's testability and points at the seams to attack first.
module mapperconceptReads an Xcode project's dependency graph and proposes a Tuist/XcodeGen module split — the modularization work, sketched before you touch a file.
Writing

The Modernization Log

RSS
Making legacy Objective-C testable without rewriting it
More soon — the log runs on Obj-C migrations, not a schedule.