MVVM, MVI, TCA, Redux or VIPER? The senior answer names the pressure first

In a full system design round this is a short segment, not the whole hour. Spend it in this order and the pattern name lands as a conclusion the interviewer has already watched you reach.

Before any pattern, find out which pressure dominates. Each one comes with a question you can ask out loud:

Most features have one or two dominant pressures. A settings toggle has none worth a framework. A checkout has state, ownership and failure pressure at once. Saying which pressures matter here is the move that turns a quiz into a design discussion.

The book's chapter on state ownership opens with the line I would most like candidates to internalize: "Most mobile architecture arguments are state arguments in disguise." The decisive questions are who owns mutable state, how changes enter, how effects are represented, and what happens when what you observe and what is authoritative disagree.

So show the state before the pattern. Give each piece of mutable state one owner, and make impossible combinations unrepresentable instead of guarding against them with booleans:

sealed interface CheckoutState {
    data class Editing(val draft: Draft) : CheckoutState
    data class Submitting(val operationId: String, val draft: Draft) : CheckoutState
    data class OutcomeUnknown(val operationId: String, val draft: Draft) : CheckoutState
    data class Confirmed(val bookingId: String) : CheckoutState
    data class RequiresAction(val reason: String) : CheckoutState
}

OutcomeUnknown is the state that wins the point. A request can reach the server, commit, and lose its response on the way back. A model built from isLoading, error and booking fields has nowhere honest to put that case, so it usually ends up as an error and invites a second booking. Once the states are named, the pattern question becomes concrete: which mechanism owns these transitions with the least ceremony for this team.

Each pattern is a compressed trade-off. Name the trade, the way it fails, and the signal that it no longer pays:

The last row is the one candidates miss. VIPER and RIBs answer team pressure more than feature complexity. Without that organizational scale, the ceremony is paid on every screen and returns little. Saying that out loud shows you know why the pattern exists, not only what its letters stand for.

Unidirectional flow is a constraint, not a framework: events come in, a transition decides the new state, effects run, results come back as events. The book's point is that this "can be implemented with a ViewModel, reducer, actor-owned store, coroutine state holder, TCA feature, Workflow, or custom state machine." Then: "The value is not the acronym; it is deterministic ownership and explicit effect boundaries."

enum CheckoutState: Sendable, Equatable {
    case editing(Draft)
    case submitting(operationID: String, Draft)
    case outcomeUnknown(operationID: String, Draft)
    case confirmed(bookingID: String)
}

enum CheckoutEvent: Sendable {
    case intentPersisted(operationID: String)
    case responseLost
    case receiptArrived(bookingID: String)
}

// Pure: no I/O, no clock, no framework. A ViewModel, an MVI store
// or a TCA reducer can all call it, and one test covers all three.
func reduce(_ state: CheckoutState, _ event: CheckoutEvent) -> CheckoutState {
    switch (state, event) {
    case let (.editing(draft), .intentPersisted(id)):
        return .submitting(operationID: id, draft)
    case let (.submitting(id, draft), .responseLost):
        return .outcomeUnknown(operationID: id, draft)   // not .failed
    case (.submitting, .receiptArrived(let booking)),
         (.outcomeUnknown, .receiptArrived(let booking)):
        return .confirmed(bookingID: booking)
    default:
        return state
    }
}

This changes the interview. Instead of defending MVVM against TCA, you show the rule that must hold whichever pattern hosts it, and the pattern becomes a decision about tooling, team familiarity and exit cost. Do not push every value through this loop either: text-field focus, animation phase and a disclosure toggle can stay next to the view.

Each effect needs an owner, a cancellation rule and a route for its result. A search request can be cancelled when the query changes. A durable booking submission must not be cancelled because a view disappeared: the screen stops observing, and an owner with a longer lifetime keeps the work.

This is where the platforms come in, and where a candidate shows depth without trivia. On iOS, main-actor isolation for UI state and actor-owned services for shared mutable state. On Android, a viewModelScope for feature UI work and WorkManager for durable, constraint-aware work. Neither MVVM nor TCA nor MVI decides those lifetimes for you. An answer that names the pattern and skips the lifetimes has answered the easy half.

Controlled Change runs one checkout through several patterns in a chapter it calls the pattern laboratory, and its fictional reference app ends up mixing them on purpose: search uses local state and a ViewModel, booking uses an explicit reducer and state machine, offline field work uses durable workflow state, and the application shell owns navigation and session composition. The book's conclusion: "Consistency comes from shared invariants for ownership, effects, and authority, not from one acronym."

That is a strong position to take in an interview, especially for a lead or staff role. Standardize the decision process, the integration boundaries, the lifecycle rules and the test expectations. Permit bounded variation where complexity differs. Mandating one pattern for every feature makes the simple screens pay the cost of the hardest one.

Every pattern choice is also a future migration. Say how a feature would leave the pattern before you recommend it. For TCA the book is specific: because the coupling is deep, plan the exit at adoption and keep public feature contracts free of framework types, so a feature can leave without its callers changing. The same rule protects an MVI store or a Redux slice.

If the team is unsure, propose an experiment instead of a mandate. Implement one representative slice in two or three patterns and measure concepts and files, transition-test clarity, effect cancellation, restoration, onboarding time, changed lines for a new requirement and how much code is framework-specific. Use the difficult state, a response lost after commit, deep-link restoration or two concurrent edits, not a toy counter. Then pilot on one non-critical feature with real state pressure, with success and exit criteria written first.

And if the answer moves to migrating an existing feature from MVVM to a reducer or back, the book's playbook starts with a map of current state, actions and effects, and the actual failures, before anything is rewritten. Its warning applies to every pattern debate: watch for architecture migration as an identity campaign.

Sometimes the right answer is the least impressive one. If the scenario is an early product with two engineers, say so: one application module, simple state and a direct data boundary, with explicit states only where money or inventory already demand them. Direct state is not amateur architecture; it is a starting point with a named trigger for extracting more.

The book's chapter on system design interviews lists "choosing MVVM before requirements" among the common weak answers, and ends its advice on over-design in three words: "Restraint is senior behavior." For the same idea from the SwiftUI side, see SwiftUI vs UIKit: architecture is state ownership.

The staff column does not know more patterns. It knows when each one stops paying, and it leaves the team able to change its mind.

• "Where would you not use it?" Tests whether you can argue against your own choice.
• "The ViewModel is 2,000 lines." Tests splitting ownership instead of adding a layer.
• "A second team now edits this feature every sprint." Tests team pressure and boundaries.
• "The request timed out. Did the booking happen?" Tests the unknown outcome state.
• "We want to adopt TCA across the app." Tests pilot, exit and framework-free contracts.
• "It's a two-person startup." Tests restraint.

Prepare one sentence for each. If a follow-up makes you switch patterns, your first answer was a preference. If it makes you point at a pressure you already named, you are having the conversation the question is for.

Which architecture should I say I would choose in a mobile interview?

Do not lead with a name. Ask about the feature, the team and the failure cases, name the pressure that dominates (state, ownership, failure, team, delivery or change), place state and effects, and only then pick a pattern for that feature. Close with what it costs and how a feature would leave it.

Is MVVM a weak answer?

No. MVVM fits forms, lists and workflows with straightforward transitions, and it is cheap to adopt and to leave. It becomes a weak answer when it is chosen before the requirements, or when the ViewModel turns into the place where navigation, networking, analytics and database code all end up.

Is TCA worth it?

It can be, for teams willing to adopt its model deeply and for features with rich state and effects, where exhaustive tests and composition pay. The cost is framework coupling and a learning curve, so plan the exit at adoption: keep public feature contracts free of framework types.

Can one app use several patterns?

Yes, and a strong answer says so. Simple screens keep local state, consequential flows get an explicit state machine, and consistency comes from shared rules for ownership, effects and authority rather than from one acronym everywhere.