Most mobile apps don’t become messy because of one bad decision. They get messy because nobody decided where the state lives.

A login button gets a loading spinner. Then an error message. Then a “remember me” toggle. A few weeks later, the screen’s logic is spread across three files and a rotation bug is wiping out half of it. Architecture patterns exist to stop this slide.

In this article I’ll walk through four patterns you’ll meet in mobile development: MVC, MVP, MVVM and MVI. I’ll focus on three questions for each:

1. Where does the data and state live?
2. How do user actions travel through the app?
3. How easy is it to test and maintain?

I’ll use one running example, a simple login screen, with Kotlin/Android-flavored snippets. The ideas apply equally to iOS and Flutter.

The core problem: state and separation of concerns

State is everything the screen needs to know to draw itself right now: the text in the fields, whether a request is in flight, whether there’s an error.

Separation of concerns means UI code draws things, business logic makes decisions, and data code talks to the network or database. All four patterns are different answers to the same question: how do these pieces talk to each other without becoming tangled?

1. MVC (Model-View-Controller)

The oldest of the four. It was the default for early iOS (UIKit) and still shows up everywhere.

• Model: data and business rules
• View: what the user sees
• Controller: takes input, updates the model, picks the view

In practice: the Controller and View end up tightly coupled. On Android, an Activity is both the View and the Controller. On iOS, you get the famous “Massive View Controller,” a file with 2,000 lines doing everything.

Good: simple, quick to learn, fine for small apps.
Bad: hard to unit test (logic is trapped in UI classes), state lives in scattered view properties, and it falls apart as screens grow.

2. MVP (Model-View-Presenter)

MVP exists to fix MVC’s biggest flaw: it pulls logic out of the View.

• View: a dumb interface. It only displays and forwards events.
• Presenter: holds the logic, tells the View exactly what to do
• Model: data and rules

Good: the Presenter is plain Kotlin, so you can unit test it with a fake View. Responsibilities are clear.
Bad: lots of boilerplate (an interface per screen), the Presenter and View hold references to each other (a leak risk if you forget to detach), and state is still scattered. The Presenter commands the View step by step, so it’s easy for the screen to drift out of sync.

3. MVVM (Model-View-ViewModel)

MVVM flips the relationship. The ViewModel doesn’t know the View exists. It just exposes state, and the View observes it.

The View just reacts:

Good: no View reference in the ViewModel (fewer leaks, easier tests), it survives configuration changes like rotation, and it fits naturally with Jetpack Compose and SwiftUI. This is why it’s the officially recommended approach on Android.
Bad: a ViewModel can bloat into a mini god-class. And if you expose several separate observables (isLoading, error, data), they can get out of sync with each other, and one-off events like “show a toast” are awkward to model.

4. MVI (Model-View-Intent)

MVI takes MVVM’s observable idea and adds strictness: one state object, one direction, and every change goes through a defined path.

• Intent: what the user wants to do (LoginClicked, EmailChanged)
• Model: the single, immutable state of the screen
• View: renders the state, nothing else

Good: state is predictable. There’s one source of truth, so any bug can be reproduced by replaying the intents. It’s great for complex screens with lots of interacting inputs, and the logs read like a story of what the user did.
Bad: more code and more concepts for simple screens (a tiny settings page doesn’t need sealed intents), copying large state objects can feel heavy, and the learning curve is steeper for beginners.

So which one should you use?

My honest take:

• Tiny app or prototype? MVC is fine. Don’t over-engineer a weekend project.
• Maintaining an older codebase? You’ll likely meet MVP. Understand it, and migrate gradually if you can.
• Building a typical modern app? Go with MVVM. It’s the best balance of structure and simplicity, and it’s what the platforms themselves push.
• Complex, interaction-heavy screens (forms with dependent fields, real-time data, chat, checkout flows)? Use MVI, or MVVM with a single-state-object discipline. In practice, many teams end up with something in between.

The pattern matters less than the principle underneath all four: keep logic out of the UI, and make it obvious where state lives and how it changes. A well-disciplined MVVM beats a sloppy MVI every time.

Final thoughts

These patterns aren’t rival religions; they’re stages in the same evolution. MVC separated data from display. MVP pulled logic out of the UI. MVVM made the UI react to state instead of being commanded. MVI made that state a single, predictable truth.

If you’re starting out, learn MVVM well, then try rebuilding one screen in MVI to see the difference. That exercise will teach you more than any article, including this one.

Medium tips: paste the code blocks as code blocks (type ``` on a new line), turn the ASCII diagrams into clean images if you have time (draw.io or Excalidraw works), and add 4 or 5 tags like Android, Software Architecture, MVVM, Mobile Development. Since the deadline is today, publish first and polish after, because you only need to submit the URL.