Given a new mobile app screen with a handful of simple, mostly-static fields versus a complex form with many interdependent, frequently changing fields, how would you decide between MVP and MVVM for each, and what's the actual cost you're trading off?

## The two variables Choosing between MVP and MVVM is fundamentally a bet about two variables: 1. how much displayed state a screen has, and 2. how often that state changes in response to other state. These two variables determine which pattern's cost curve is lower for a given screen, and the mistake many teams make is picking one pattern as a blanket standard for an entire app regardless of how individual screens differ on these axes. ## How MVP's cost scales Mechanically, MVP's cost is proportional to the number of distinct View-interface methods needed, because every piece of state the View must display requires: - a method on the **View interface**, - an implementation of that method in the **concrete View**, - and an explicit **call site in the Presenter**, correctly sequenced relative to every other call. For a login screen with a username field, a password field, and a submit button — a handful of states total — that's a handful of methods, trivially reviewable, and a debugger can step through the Presenter method line by line and see exactly what happens and in what order. This explicitness is a genuine asset: when something's wrong, you set a breakpoint on the suspect call and you're done. ## How MVVM's cost scales MVVM's cost, by contrast, is roughly flat per additional field: adding a new bound property to a ViewModel is typically one new observable declaration plus one binding expression in the View's markup, with no growth in imperative call-sequencing code, because the binding engine handles propagation regardless of how many properties exist. For a checkout form with quantity fields, per-item subtotals, a running total, a discount code field that revalidates other fields, and conditional visibility on a dozen elements, hand-writing MVP-style explicit calls for every interdependency becomes both verbose and a common source of ordering bugs. MVVM collapses that to declaring computed/derived observables that the binding layer keeps current automatically, and every bound View element just reflects whatever the observable currently holds. ## The real trade-off is debuggability shape The real trade-off, then, is not raw code volume alone but debuggability shape. | Pattern | What tracing a bug looks like | |---|---| | MVP debugging | linear and imperative — you can literally step through the Presenter's method top to bottom | | MVVM debugging | a dependency graph — understanding why a value changed means tracing backward through however many transformation operators sit between the root mutation and the bound UI element, which is a fundamentally different mental model, especially for engineers unfamiliar with reactive composition | Teams sometimes underestimate this cost until a production bug in a long observable chain takes hours to trace versus minutes for an equivalent MVP call-sequencing bug. ## Platform and toolkit alignment A second, often-decisive factor is platform/toolkit alignment rather than pure architecture merit. Modern declarative UI toolkits — SwiftUI, Jetpack Compose, WPF/XAML — are built with first-class binding and expect a reactive state-holder as the natural shape of screen code; forcing MVP's explicit-interface-and-imperative-call style onto them means fighting the platform's grain. Conversely, on a toolkit with no meaningful binding support, hand-rolling an observable layer just to do MVVM adds framework-building overhead MVP wouldn't need. In practice, most real teams choose per-platform default rather than per-screen, because consistency across a codebase has its own value, but the underlying reasoning for that platform default is exactly the state-complexity/toolkit-alignment trade-off described above, not fashion. ## A concrete illustration A concrete illustration: Google's own Android guidance shifted from MVP, recommended circa 2015-2017 when Architecture Components didn't exist and Fragments/Activities needed a mockable interface for JVM unit tests, to MVVM from 2017 onward once ViewModel plus LiveData shipped as first-class, lifecycle-aware, testable primitives — a platform-level tooling change, not a change in what 'good architecture' means, and it illustrates that this decision should be revisited when the underlying toolkit's capabilities change, not treated as permanent doctrine.