What is unidirectional data flow in a mobile UI, and why do modern frameworks like SwiftUI and Jetpack Compose lean on it?

technical-conceptual · Junior level · software-engineering

What the interviewer is really asking

Probes whether the candidate understands the state-drives-UI model behind declarative mobile frameworks and why it reduces a class of UI-consistency bugs.

What to say

• Define it plainly: state flows down into the UI and events flow up; the UI is a function of state, so you change state and the framework re-renders the view to match.
• Contrast with the old imperative style where you mutate widgets directly from many places, which lets the screen and the underlying data drift out of sync.
• Explain the payoff in declarative frameworks: a single source of truth makes the UI predictable and easier to reason about and debug, since the same state always produces the same screen.

What to avoid

• Don't confuse it with two-way binding where the view and model freely mutate each other — that's the bidirectional model UDF avoids.
• Don't describe it as just 'reactive magic' without naming state-down / events-up.
• Don't claim it's only relevant to one platform; it underpins both SwiftUI and Compose (and React).

Example answers

Strong: Unidirectional data flow means state flows down into the UI and events flow up: I hold a single source of truth, the view is rendered as a function of that state, and a user action sends an event that updates the state, which re-renders the view. In SwiftUI and Compose I'm not poking widgets imperatively from ten places, so the screen can't drift out of sync with the data. The big win is predictability — the same state always produces the same UI, which makes bugs far easier to trace.

Weak: It's the way SwiftUI and Compose handle state automatically. You set up bindings and the UI just updates itself, so you don't really have to think about the data flow.