What's the difference between MVVM and MVI, and when would you choose each?
Design patternsMid-level
In shortIn MVVM the view observes a ViewModel's state and calls its methods; in MVI the view sends intents, and a pure reducer turns the current single immutable state into the next one. MVI is stricter and easier to trace and test; MVVM has less ceremony.
Model answer
MVVM: the ViewModel exposes observable state (often several properties, or one UI state object) and methods the view calls (onEmailChange, logIn). It has no reference to the view, so it survives screen recreation and is testable with fakes. Changes can happen in any method.
MVI: the screen has one immutable state. The view sends intents; a pure reducer computes (state, intent) → state; side effects (network, storage) run outside the reducer and report back as new intents. Every change goes through one function, in one direction, which makes bugs traceable (log the intents) and transitions trivially testable.
Choosing: MVVM for small and medium apps where speed of development matters; MVI (or TCA, Redux) when many people work on many screens, when you need consistent conventions and traceability, or when state transitions are complex. Either way, keep observable state immutable, and treat one-off events (navigation, toasts) separately from state, consumed by id or delivered as a non-replayed stream.
What they're looking for
How state and changes flow in each, the testability and traceability benefits of a reducer, the cost in boilerplate, and handling of one-off events.
Common mistakes
- Saying MVI is just MVVM with a different name.
- Ignoring one-off events like navigation and toasts.
- Choosing by fashion instead of team and app needs.