Skip to content
All books
New

Controlled Change: architecture, reliability, and evolution for mobile systems

60 chapters in pressure order, from decision discipline and data under failure to AI on mobile and a nine-case casebook.

A mobile architecture book for staff iOS and Android engineers

Most architecture material begins in a clean room. Mobile systems live on constrained devices, across operating-system generations, behind app-store review, with old client versions still running and releases that cannot be recalled.

This book treats those facts as the center of architecture. It discusses Clean Architecture, MVVM, MVI, Redux, TCA, VIPER, RIBs, Workflow, feature modules, Domain-Driven Design, reactive systems and dependency injection, and presents none of them as a destination. Each is examined as a response to pressure.

It is written in pressure order rather than pattern order, around Atlas, a fictional marketplace and field-operations product that grows from a two-engineer prototype into a multi-team platform with offline work, progressive rollout and an AI assistant.

What you get

  • A decision discipline: characteristics, budgets and evidence, the economics of abstraction, and ADRs with revisit triggers
  • Data under failure: Swift concurrency and Kotlin coroutines as architecture, process death, offline-first, a sync engine, conflicts and schema evolution
  • Scale and teams: feature modules, the module graph, platform engineering, cross-platform with escape hatches, SDKs and legacy migration
  • Production systems: failure-model testing, performance, observability, security, release architecture, feature flags and kill switches, server-driven UI
  • AI on mobile: on-device, cloud and hybrid routing, context and RAG, a governed tool gateway for agentic apps, model lifecycle and evaluation
  • Staff practice, a nine-case casebook and nine appendices, including 12 example ADRs, 10 migration playbooks and a Staff+ interview bank

Where mobile architecture loses control of change

Well illustrated, not well architected

A cleanly separated app that cannot be migrated, observed, released safely or understood by the team is a diagram, not an architecture.

Abstraction borrowed without a return

A layer template repeated across seventy trivial features creates hundreds of types whose purpose is structural compliance.

The release you cannot recall

Old clients stay installed for months, share the backend with new ones, and meet every contract change you ship.

The response lost after commit

A retry without operation identity turns a timeout into a duplicate charge or a false confirmation.

Modules that always change together

A uniform module template looks enforceable until most product changes touch three or four modules of the same capability.

A decision you did not get to make

The framework, the date and the vendors were fixed before any architecture review, and the open questions are still yours.

Good architecture did not predict the future. It made being wrong affordable.
From Controlled Change

What changes when you use it

You stopYou stop asking what pattern the app uses.

You startYou ask how cheaply and safely the product can absorb the next important change.

You stopYou stop borrowing abstractions without naming the return.

You startYou test each boundary for volatility, consequence, multiplicity and coordination.

You stopYou stop marking checkout complete when the payment sheet closes.

You startYou wait for the authority's canonical result and show a pending state until it arrives.

You stopYou stop describing a rewrite by its destination.

You startYou describe coexistence, migration, rollback and deletion.

You stopYou stop relitigating a decision that was imposed on you.

You startYou decide everything the decision did not.

Signs the architecture costs more than it buys

  • A shared module gains consumers faster than owners, and every edit to it rebuilds most of the app.
  • Release flags have no owner and no removal date.
  • A remote UI payload has grown conditions, validation and actions that chain other actions.
  • Retry three times is the whole failure policy.
  • A migration cannot finish without stopping the release train.
  • Nobody can say which representation wins when local intent, cache and the server disagree.

Why this book exists

I tried to write the book I wanted when I was the one holding the decision and the pager at the same time.

Where the book makes a consequential claim, it states what evidence would challenge it. Where it states a trade-off, it names what the trade-off costs, not only what it buys.

Where a large company's practice is instructive, I kept the lesson and dropped the logo. The point was never that a famous team did it. The point is whether the pressure that justified their choice exists in your product.

The book is dedicated to the engineers who inherited the diagram after the people who drew it had left.

A page from the book

Copied as printed, so you can judge the format before you buy.

Chapter 4, page 31

The boundary test

Before adding an abstraction, ask four questions.

Volatility

Are the two sides likely to change for different reasons? A pricing rule and a JSON decoder are. A view-specific date string and its text label usually are not.

Consequence

What happens if change leaks? Payment, identity, local migrations, and remote commands justify stronger containment than a decorative card.

Multiplicity

Are there real alternative implementations or consumers? “We might replace this someday” is weak. iOS, Android, background work, widgets, and tests may create real multiplicity.

Coordination

Will different teams or release clocks own the sides? An organizational seam can justify a technical contract even when the code is currently simple.

Want more pages?

Before and after

An architecture that was imposed on you

Before

I disagree.

After

I will deliver this, and here are the conditions under which it stays reversible.

Server authority is unchanged, risky capabilities stay behind a native boundary, contracts come first, and vendors sit behind ports.

A checkout that says Booked

Before

The payment sheet closed, so show Booked.

After

The client never marks checkout completed just because the payment sheet closed successfully. It waits for the booking authority’s canonical result.

Until then the screen shows a pending receipt state with a status lookup: slightly more complex, but truthful and recoverable.

Failure handling in a system design answer

Before

Retry three times.

After

The send command includes the client ID and idempotency key.

Receiving the same event by socket and by pull is expected. Event IDs and sequence numbers make applying it idempotent.

Choose your edition

Both editions are on one Gumroad page: you pick the edition there, before you pay. Every edition includes free lifetime updates.

Book

The complete book

$59

The complete Controlled Change book, to read and apply without the companion code.

  • PDF
  • EPUB
  • 60 chapters in eight parts
  • 9 appendices
  • Lifetime book updates
Choose Book, $59

Secure checkout on Gumroad. Instant PDF and EPUB download. Lifetime updates.

Pro

Book and Atlas reference system

$69

The book with the Atlas engineering system's native, Kotlin Multiplatform, backend and contract code.

  • Controlled Change
  • Runnable iOS and Android code
  • Kotlin Multiplatform and backend code
  • Contract schemas
Choose Pro, $69

Secure checkout on Gumroad. Instant PDF and EPUB download. Lifetime updates.

Extended

Everything in Pro, plus more platforms

$99

Everything in Pro, plus React Native, Flutter and the sync simulator that injects duplicate events, reordered writes, process death and model failure.

  • Everything in Pro
  • React Native code
  • Flutter code
  • The sync simulator
Choose Extended, $99

Secure checkout on Gumroad. Instant PDF and EPUB download. Lifetime updates.

Nine cases, from prototype to the imposed decision

The casebook and the Atlas reference system are fictional. They combine common engineering pressures so the trade-offs can be argued without exposing any organization's systems. In each case several architectures can be defensible, provided their assumptions are explicit.

Chapter 52

Atlas: from prototype to platform

  • Five stages, from two engineers to 150 across mobile and backend
  • Seven decisions that carry most of the outcome
  • Three decisions Atlas had to reverse
  • A three-release migration exercise

Chapter 53

The offline field operation

  • Inspectors offline for days on shared devices
  • Per-artifact durable operations and one submission command
  • Saved on this device is not Submitted
  • A fourteen-case failure test plan

Chapter 54

The global checkout

  • Limited inventory in many currencies and regions
  • Confirmation bound to an exact quote
  • One booking command, orchestrated by the backend
  • A pending receipt instead of an optimistic Booked

Chapter 55

The messaging system

  • Offline compose with no duplicates after retry
  • Ordering per conversation, not global
  • Live channel, push hint and cursor pull
  • No direct Send tool for the model

Chapter 56

The regulated finance app

  • Several jurisdictions with different disclosures and retention
  • Only trusted server systems authorize a transfer
  • Biometric success does not authorize a transfer
  • Incident: an unknown status mapped to Failed

Chapter 57

The cross-platform rewrite

  • Sixty native engineers and an eighteen-month rewrite proposal
  • Measure the delay before choosing a framework
  • Kotlin Multiplatform for selected domain rules, native UI kept
  • Stop conditions for expansion

Chapter 58

The AI trip operator

  • A task inventory that places authority task by task
  • Trip-scoped context policy
  • Typed tools with prepare, confirm and execute
  • A prompt injection rejected at the tool gateway

Chapter 59

The mobile platform program

  • Twelve product teams and five flag wrappers
  • A year-one sequence, quarter by quarter
  • Golden paths teams can trim
  • A year that ends with removed systems

Chapter 60

The imposed decision

  • A React Native partner app announced before any review
  • What the decision fixed, and what is still open
  • Every consequence classified by reversibility
  • Survivable, not optimal

What is inside

  1. 1Architecture Is Controlled Changep. 15
  2. 2Why Mobile Is Differentp. 20
  3. 3Characteristics, Budgets, and Evidencep. 25
  4. 4The Economics of Abstractionp. 30
  5. 5Decisions, ADRs, and Revisit Triggersp. 35
  6. 6Architecture Across Product Stagesp. 40
  7. 7From Screen to Featurep. 46
  8. 8Dependency Direction Without Ceremonyp. 51
  9. 9Domain-Driven Mobile Boundariesp. 56
  10. 10State Ownership and Unidirectional Flowp. 61
  11. 11The Pattern Laboratoryp. 66
  12. 12Navigation, Lifecycle, and Restorationp. 71
  13. 13Dependencies, Composition, and Injectionp. 75
  14. 14Swift Concurrency as Architecturep. 80
  15. 15Kotlin Coroutines as Architecturep. 85
  16. 16Process Death, Background Work, and Timep. 90
  17. 17Data Authority and Repository Designp. 95
  18. 18Local Data, Cache, and Freshnessp. 100
  19. 19Offline-First Is a Product Decisionp. 105
  20. 20Building a Sync Enginep. 112
  21. 21Conflicts, Idempotency, and Reconciliationp. 120
  22. 22Schema Evolution and Version Skewp. 127
  23. 23Real-Time and Event-Driven Mobilep. 134
  24. 24Feature-Based Modularizationp. 142
  25. 25Designing the Module Graphp. 148
  26. 26When Modularization Goes Wrongp. 154
  27. 27Team Topologies and Ownershipp. 160
  28. 28Build Architecture and Feedback Loopsp. 166
  29. 29Mobile Platform Engineeringp. 173
  30. 30Cross-Platform with Escape Hatchesp. 180
  31. 31SDK Architecture and Compatibilityp. 187
  32. 32Migrating Legacy Mobile Systemsp. 194
  33. 33Testing the Failure Modelp. 201
  34. 34Performance as an Architecture Characteristicp. 208
  35. 35Observability, Reliability, and Field Truthp. 215
  36. 36Security, Privacy, and Trust Boundariesp. 222
  37. 37Accessibility, Adaptivity, and Device Diversityp. 229
  38. 38Release Architecturep. 235
  39. 39Feature Flags, Experiments, and Kill Switchesp. 242
  40. 40Server-Driven UI and Remote Experiencesp. 249
  41. 41The AI-Native Mobile Stackp. 257
  42. 42On-Device, Cloud, and Hybrid Routingp. 265
  43. 43Context, Memory, RAG, and Multimodalityp. 272
  44. 44Agentic Apps, Permissions, and Toolsp. 279
  45. 45Offline AI, Model Lifecycle, and Evaluationp. 287
  46. 46Architecture Reviews That Workp. 296
  47. 47Fitness Functions, Governance, and Debtp. 302
  48. 48Influence, RFCs, and Architecture Roadmapsp. 308
  49. 49Incident-Led Architecturep. 314
  50. 50Mobile System Design Interviewsp. 320
  51. 51Designing Systems That Can Be Replacedp. 326
  52. 52Atlas: From Prototype to Platformp. 333
  53. 53The Offline Field Operationp. 343
  54. 54The Global Checkoutp. 350
  55. 55The Messaging Systemp. 357
  56. 56The Regulated Finance Appp. 364
  57. 57The Cross-Platform Rewritep. 371
  58. 58The AI Trip Operatorp. 377
  59. 59The Mobile Platform Programp. 382
  60. 60The Imposed Decisionp. 387
  61. Appendix A. Mobile Architecture Decision Canvasp. 397
  62. Appendix B. ADR Libraryp. 404
  63. Appendix C. Architecture Review Rubricp. 413
  64. Appendix D. Migration Playbooksp. 419
  65. Appendix E. Testing and Failure Catalogp. 425
  66. Appendix F. Performance and Reliability Budgetsp. 431
  67. Appendix G. Security and Privacy Checklistp. 448
  68. Appendix H. Staff+ Interview Bankp. 453
  69. Appendix I. Glossaryp. 459

Mobile architecture books: where Controlled Change fits

Most architecture material begins in a clean room: the requirements are legible, the network responds, the database is empty and the team agrees. Controlled Change starts from what makes mobile different: old client versions still running, app-store review, operating-system generations, and releases that cannot be recalled like a server deployment.

It is a book about architectural judgment, not an implementation encyclopedia, a framework manual or a catalog of universal patterns. It assumes you can already build and ship a mobile app, and begins where judgment becomes the harder problem.

Which of my architecture books do you need?

Three books, three different jobs.

  1. Mobile System Design Blueprint. Practice. 20 decision chapters, 12 system scenarios and 50 exercises with answer keys, for rehearsing the decisions behind evolving, migrating, releasing and operating mobile systems.
  2. Altitude. Staff systems beyond the app. 364 pages and 28 chapters on backend contracts and BFFs, security and identity, observability, cloud and incidents, with the app as one node in a larger system.
  3. Controlled Change. The architecture inside the app, across its whole life. 472 pages and 60 chapters on boundaries, state ownership, offline sync, version skew, modularization, release control and AI on mobile.

MVVM, MVI, TCA, Redux, VIPER and RIBs, compared not crowned

Chapter 11, the pattern laboratory, runs the same Atlas checkout through several patterns and compares the cost of change: direct state, MVVM, MVI, Redux, The Composable Architecture, VIPER, RIBs and Workflow. For each one the question is the same: what pressure does it answer, what does it cost, and what signal says it no longer pays.

None is presented as a destination. Direct state is treated as an appropriate starting point with an explicit extraction trigger, not as amateur architecture.

Where this shows up on salari.dev

Free articles on this site that point to Controlled Change as the place to go deeper.

Early reader reviews

Five engineers with 5 to 15 years of experience in iOS, Android, frontend, mobile, staff and tech lead roles are reading it now. Their reviews appear here in their own words as they arrive.

Read the sample while you wait

Who this is for

This is for you ifyou can build the app; the hard part now is deciding which boundary is worth its cost and changing a live system without losing control.

  • You can already build a mobile app: you have shipped features, fixed the crash, argued about MVVM in a pull request.
  • You decide which boundary is worth its cost, and which migration can run without stopping the release train.
  • You want decisions that will still be defensible in three years, when the person who made them has left.
  • You are a Staff or Principal mobile engineer, a mobile architect, a platform lead, or the engineering manager who funds their decisions.

Not for

  • Engineers learning their first architecture
  • Anyone looking for a code walk-through that teaches dependency injection from scratch
  • Anyone looking for a folder template to copy
  • Anyone who wants one framework crowned as the answer
The library pathWhere this fits
  1. 01Get foundThe Silent Rejection
  2. 02Build the record and negotiateThe iOS Engineer Playbook · Leverage
  3. 03InterviewThe iOS interview blueprint · The senior signal · Top 300 React Native interview questions · 500 Flutter interview questions · The senior SDET interview handbook
  4. 04Answer practice and live roundsThe 24-hour iOS interview answer book · The 24-hour Android interview answer book · Share your screen
  5. 05Architecture and qualitySwiftUI under load · Mobile System Design blueprint · Security is a feature · The Second Pass
  6. 06Staff systems and ownershipAltitude · Ticket taker, outcome owner
  7. 07Build with AIBuild with your brain on (coming soon)
  8. 08LeadBefore the Room
  9. 09ArchitectControlled ChangeYou are here
Portrait of Mike Salari

About the author

Mike Salari

Staff mobile engineer · 500+ technical interviews from the hiring side.

I have spent 15 years in mobile and sat through 500+ technical interviews from the hiring side. At staff level the strong answers do not name the most patterns. They say which boundary is worth its cost, what it costs, and what evidence would change the decision. I wrote this book for the engineer who holds that decision.

15 years building production mobile software, with experience across Apple, Adobe, Cisco, Mastercard and Visa.

Read the full story

Before or after you buy

FAQ

Controlled Change: questions before you buy

What is Controlled Change about?

Controlled Change is a 472-page, 60-chapter book on mobile architecture for staff and principal mobile engineers, mobile architects and platform leads. It treats Clean Architecture, MVVM, MVI, Redux, TCA, VIPER, RIBs and feature modules as responses to pressure, not destinations, and is written in pressure order around Atlas, a fictional marketplace app.

What is the difference between Book, Pro and Extended?

Book is the book alone, PDF and EPUB with lifetime updates. Pro is the book with the Atlas reference system: native iOS and Android, Kotlin Multiplatform, backend and contract code. Extended adds React Native, Flutter and the sync simulator that injects duplicate events, reordered writes, process death and model failure.

Does it cover AI on mobile?

Yes. Part VI covers on-device, cloud and hybrid routing, context and RAG, agents and tools, and model lifecycle and evaluation.

Is Controlled Change an iOS or an Android architecture book?

Both. The iOS and Android implementations stay native where platform mechanics matter, and Swift concurrency and Kotlin coroutines each get a chapter. Kotlin Multiplatform, React Native and Flutter are treated as boundaries of shared code, in a chapter on cross-platform with escape hatches and a casebook chapter on a cross-platform rewrite.

Does it cover offline-first and sync?

Yes. Part III, Data under failure, covers process death and background work, data authority, cache and freshness, offline-first as a product decision, building a sync engine, conflicts, idempotency and reconciliation, schema evolution and version skew, and real-time events.

How is it different from Mobile System Design Blueprint and Altitude?

Mobile System Design Blueprint is practice: decision chapters, system scenarios and exercises with answer keys. Altitude is staff systems beyond the app: backend contracts, security, observability and incidents. Controlled Change is the architecture decisions inside the app across its whole life.

Is it for beginners?

No. It assumes you can already build and ship a mobile app, and starts where architectural judgment becomes the harder problem.

Share this book

XLinkedInBlueskyThreadsHacker News