What is the difference between the View system and Jetpack Compose?

What the interviewer is testing

This question sounds like it's comparing two UI toolkits, but that's rarely what the interviewer cares about.

They're looking for whether you understand the shift from manually updating the UI to describing it from state. If your answer focuses on XML versus Kotlin or Views versus composables, you've probably missed the engineering decision behind Compose.

A strong answer explains the change in responsibility first. The terminology comes afterwards.

❌ Common mistake

If they ask you to elaborate

Imagine an order screen that can be loading, showing an order, or showing an error.

With the View system, you might receive a new state and then update several existing Views:

progressBar.isVisible = state.isLoading
contentGroup.isVisible = state.order != null
errorView.isVisible = state.error != null
ordersAdapter.submitList(state.items)

There's nothing inherently wrong with that. The important point is that your code is coordinating those mutations.

As the screen grows, there are more things to keep synchronized. If one update is forgotten, the View hierarchy can end up showing a combination that doesn't match the application's actual state.

Compose approaches the same problem from the other direction. Instead of describing how to move the old UI into the new state, you describe the UI for the state you have now:

when (state) {
    OrderUiState.Loading -> LoadingScreen()
    is OrderUiState.Content -> OrderScreen(state.order)
    is OrderUiState.Error -> ErrorScreen(state.message)
}

Now the code says what each state looks like. Compose takes responsibility for updating the UI when that state changes.

That's why declarative UI becomes easier to reason about on state-heavy screens: state is the input, UI is the result.

This doesn't mean Compose redraws the whole screen every time something changes. How Compose keeps track of the UI, and how it decides what work needs to run again, are separate questions. Those are where Composition and recomposition come in.

Production thinking

The difference becomes much more valuable as a screen grows.

A simple login screen only has a few pieces of state. A production screen might have loading, cached data, pull-to-refresh, dialogs, permissions, paging, connectivity changes, and navigation events happening at the same time.

In a View-based screen, your code often coordinates multiple UI updates to keep everything synchronized. In Compose, you describe what the screen should look like for the current state, which makes complex screens easier to reason about.

Compose doesn't decide where that state comes from. That's still the job of your architecture. Views and Compose can even coexist in the same application—the rendering toolkit doesn't change who owns application state.

Follow-up questions

What separates a senior answer

Key takeaways

Learn more