Why UI Patterns Are Not Mobile Architecture
Most mobile teams say they have an “architecture.”
What they actually have is a UI pattern:
- Unidirectional Data Flow (UDF)
- ViewModel State UI
- Reducers and Intents
This isn’t architecture. It’s a screen-level tactic.
Confusing the two leads to dogma - where teams prioritize code consistency over system reliability.
The Fundamental Difference
UI patterns and Architecture solve entirely different problems.
UI Patterns ask:
How does this screen react to a button click?
Architecture asks:
- How does the app behave during a 12-hour sync?
- What happens when the OS kills the process mid-transaction?
- How do two independent features coordinate a shared resource?
- How does the app recover from a partial network failure?
UI patterns are about rendering. Architecture is about behavior under constraints.
The UDF Trap
It’s tempting to say “Our architecture is UDF.” It’s visible. It’s easy to document. It feels like order.
But UDF is a local optimization. It governs the boundary between user input and visual state.
It says nothing about:
- Data ownership and persistence.
- Background execution limits.
- Lifecycle coordination.
- Feature boundaries.
Calling UDF “architecture” is like calling a database schema “distributed systems design.” It’s an important piece, but it’s not the system.
Architecture Should Reduce Complexity
When a UI pattern is mistaken for architecture, simple features become heavy.
A single API call suddenly requires:
- An Intent class, a State class, a Reducer, a Mapper, and a Sealed Hierarchy.
This is ceremony without necessity.
The Rule: Good architecture makes simple things simple and complex things manageable. Bad architecture makes everything equally heavy.
Mobile is a Hostile Environment
A mobile app is not a website. It lives in a world of:
- Unpredictable process death.
- Aggressive battery management.
- Intermittent connectivity.
Real Architecture is the strategy for these “Modes of Operation.”
It defines the contracts between layers and the rules for survival. UI patterns live inside the architecture - not the other way around.
The Architecture Test
If your “architecture” cannot answer these three questions, you don’t have one:
- What happens to the data when the app is killed in the background?
- How do we handle a state transition triggered by a System Event (e.g., Location) when no UI exists?
- How do we prevent two features from corrupting the same local database?
UDF is good engineering. It is not system design.
Architecture lives where the app meets reality. And reality is messier than a ViewModel.