iOS Architecture at Scale

I spent a decade building iOS at scale, at Google Drive and then as the platform tech lead for Reddit's hundred-plus engineer iOS org. The recurring lesson is that architecture is a migration, not a decision. Modularization, declarative UI, dependency inversion: you do not choose them once, you move toward them continuously, and the abstractions that do not enforce boundaries are just suggestions.

Build time is the most underpriced cost in mobile, and the dependency graph is the real lever, not the caching strategy bolted on top. Declarative UI was clearly the future early, which is why I built SliceKit and Minerva before SwiftUI was production-ready, and why I keep writing about where SwiftUI is and is not ready yet.

Platform shifts are bets you place years ahead: Apple Silicon, Swift Concurrency, privacy as a product concern, the cost of cross-platform code. The posts below trace those bets and where they landed.

Reading path (28 posts)

Frequently Asked Questions

Is modularizing an iOS codebase a one-time decision?

No. Jeff Adler frames modularization as a migration you move toward continuously, with enforced module boundaries, not a single architectural choice you make once.

What is the biggest hidden cost in mobile engineering?

Build time. Jeff Adler argues it is the most underpriced cost in mobile, and that the dependency graph (not just build caching) is the lever that controls it.

More topics: Agentic Engineering | Engineering Leadership | All posts | About Jeff Adler