Why did you choose this architecture?

This question is really testing whether you can reason about tradeoffs, not whether you know a “correct” architecture. Interviewers have heard “I used MVVM because it’s Apple’s recommended pattern” a hundred times — it signals you memorized a term rather than made a decision. Here’s how to structure a strong answer.

The shape a senior answer should take

1. Context first — what was the project (team size, timeline, app complexity, existing codebase)?
2. The actual constraints that drove the decision — not textbook reasons, but the real ones: testability needs, team’s SwiftUI/UIKit mix, how much business logic vs. pure display logic, whether you inherited legacy code, deadline pressure.
3. What you considered and rejected — this is the part most candidates skip, and it’s the part that actually shows seniority.
4. What you’d do differently now — shows growth, not just justification.

A concrete example of what this sounds like

“On [project], I went with MVVM + Coordinators over plain MVC. The driving factor wasn’t ‘MVC is a massive view controller’ — that’s true but generic. The specific problem was that we had five different navigation flows sharing the same onboarding screens, and MVC scattered that flow logic across prepareForSegue calls in ways that were basically untestable. Coordinators let us unit test navigation decisions separately from view logic, and MVVM gave us a place to put business logic that didn’t depend on UIKit at all, so those tests didn’t need a simulator.

I considered VIPER, since a couple of team members had used it before — but for our team size (4 iOS devs) the ceremony wasn’t worth it. VIPER’s win is enforcing separation on a large team where people can’t be trusted to keep view logic out of controllers; at our size, code review handled that fine, and VIPER would have meant 5 files for every screen for marginal benefit.

If I were starting today with a SwiftUI-first team, I’d lean more toward a lighter MV pattern with @Observable and push more logic into models directly — MVVM’s ViewModel-per-screen boilerplate is less necessary when SwiftUI’s own state management already does a lot of that job.”

Why this structure works

• It’s anchored to a specific problem (five shared onboarding flows), not an abstract principle. Concrete detail is what separates “I read about this” from “I lived this.”
• It shows an alternative considered (VIPER) and a real reason for rejecting it (team size vs. ceremony) — this is the single biggest signal of seniority. Anyone can name the pattern they used; explaining what you didn’t choose and why shows you understand the tradeoff space.
• It ends with retrospective honesty (“if I were starting today…”) — interviewers read this as intellectual honesty rather than defensiveness about a past decision.

A framework you can adapt live in the interview, if asked about a project you haven’t pre-scripted:

Ask yourself out loud (this is fine to do in an interview):

• What was actually hard about this app? (state management, navigation complexity, offline sync, testability, team size, SwiftUI/UIKit interop)
• What did the architecture need to make easy? (usually: testing business logic without UI, isolating a specific pain point)
• What’s the cost you paid for that? (boilerplate, learning curve, indirection)
• Would you pay that cost again at a different team size / complexity?

One trap to avoid: don’t frame it as “X architecture is the best.” Senior engineers get flagged when they sound dogmatic about MVVM vs. MVC vs. TCA vs. Clean Architecture as if one is universally correct. The stronger signal is “here’s what problem this solved for this context, and here’s where I’d choose differently.”