Home / iOS architecture interview questions

Architecture

iOS architecture interview questions

Architecture rounds test judgment, not pattern trivia. Interviewers want to see how you reason about structure, testability, and change over time. This overview links the deep dives.

What architecture questions cover

Expect patterns like MVC, MVVM, VIPER, and unidirectional state, dependency injection, modularization and boundaries, and how you keep a large codebase testable and buildable. Questions are usually applied: structure this feature, make this class testable, or justify splitting this app into modules.

Answering with judgment

Avoid pattern tribalism. Explain that architecture is about managing dependencies and change, choosing the simplest structure that keeps code testable and features independent. Name the trade-offs of each choice, and be willing to say a heavy pattern is overkill for a small app. That pragmatism, over reciting VIPER diagrams, is the senior signal.

MVVM or TCA: how do you answer the comparison question?

The spoken answer: "MVVM gives me testable presentation logic with almost no ceremony: a view model owns state, the view binds to it, and I can unit test the model without UI. TCA gives me a single state tree, exhaustive tests of every state transition, and composable features, at the cost of a steep learning curve and boilerplate on simple screens. For a small team on a mid sized app I default to MVVM; I reach for TCA when the app has complex shared state and the team is bought in."

The trap: "Where does MVVM fall apart?" Candidates who defended MVVM a moment earlier often cannot name its failure mode, which reads as loyalty rather than judgment. The recovery line: "MVVM under-specifies everything outside the view model: navigation, dependencies between features, and shared state end up ad hoc, and every team reinvents them differently." The senior differentiator is knowing the mirror question too: TCA's costs are real, reducer boilerplate on trivial screens, a dependency on a third party library at the core of the app, and onboarding time for every new hire.

Make this class testable

A common applied exercise: a view controller that creates its own URLSession, reads UserDefaults, and formats dates with Date(). The spoken answer: "The class is untestable because it constructs its own dependencies and reads ambient global state. I invert that: define narrow protocols for the network and storage, inject them through the initializer, and inject the clock as a function or protocol so time is controllable. Then tests pass fakes and assert behavior."

The trap: "Why not just mock URLSession with a stubbing library?" Reaching for tooling first fails, because the question is about design, not test frameworks. The recovery line: "A stubbing library patches the symptom; the design problem is that the class knows about URLSession at all." The senior differentiator is scope control: injecting three narrow protocols where they are used, not building a generic dependency container for a single class. Interviewers watch whether your fix is proportional to the problem.

When is a heavy architecture the wrong call?

The spoken answer: "When the ceremony costs more than the risk it removes. A three screen utility app with VIPER has five files per screen and no benefit, because there is no complexity to isolate. Architecture pays off where change is frequent, state is shared, and multiple people touch the same code. I scale the structure to those pressures, not to the pattern's diagram."

The trap: "So how do you know when to add structure?" Vague answers about team size fail. The recovery line names observable triggers: "When tests need heavy setup to cover simple logic, when two features cannot change independently, or when build times push people into one module, that is the signal to introduce a boundary." The senior differentiator is describing migration rather than rewrite: you introduce the new boundary in the next feature you touch, and let the old code migrate as it changes, because big bang rewrites of working apps mostly fail.

The 3 signals architecture interviewers score

• Trade-offs stated unprompted. Every pattern you praise should come with the cost you accept. One sided answers read as tribal, and I have written no hire on strong engineers for exactly that.
• Dependency direction. Whatever the pattern, you should be able to say which layer knows about which, and why the domain layer imports nothing. That one sentence carries more weight than naming five patterns.
• Proportion. Matching the weight of the solution to the size of the problem is the whole job. Saying "this app does not need that" at the right moment scores higher than any diagram.

The architecture round is a conversation, not a quiz. Expect your first answer to be challenged, and treat the pushback as the actual question.