--- title: Android Architecture Is Quietly Moving Beyond ViewModel... description: Android architecture is evolving away from treating ViewModel as the universal state holder. With Jetpack Compose and Navigation 3, each type of state now has... canonical: https://daily.dev/posts/android-architecture-is-quietly-moving-beyond-viewmodel-as-a-state-holder-0e2pkua20 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Android Architecture Is Quietly Moving Beyond ViewModel as a State Holder | daily.dev og:description: Android architecture is evolving away from treating ViewModel as the universal state holder. With Jetpack Compose and Navigation 3, each type of state now has... og:url: https://daily.dev/posts/android-architecture-is-quietly-moving-beyond-viewmodel-as-a-state-holder-0e2pkua20 og:image: https://api.daily.dev/og/posts/0e2PkUA20.png og:image:alt: Android Architecture Is Quietly Moving Beyond ViewModel as a State Holder og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Android Architecture Is Quietly Moving Beyond ViewModel as a State Holder **[ProAndroidDev](https://daily.dev/sources/pand)** · 6 min read · 12 upvotes · 0 comments ## Summary Android architecture is evolving away from treating ViewModel as the universal state holder. With Jetpack Compose and Navigation 3, each type of state now has a more appropriate owner: UI state lives in composables via `remember`/`rememberSaveable`, navigation state belongs to `NavKey`, and ViewModel is increasingly a producer of presentation logic rather than a container for all mutable state. Google's official guidance now distinguishes between business logic state holders (ViewModel) and UI logic state holders (plain classes), encouraging developers to ask 'who naturally owns this state?' rather than defaulting everything to ViewModel. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Should UI state like dialog visibility or scroll position always be stored in a ViewModel in Jetpack Compose? No, current Android architecture guidance recommends keeping such UI-only state closest to where it is consumed, using remember or rememberSaveable inside the composable rather than moving it into a ViewModel. ViewModel is now described as a business logic state holder responsible for coordinating repositories and exposing UI state, not for owning transient UI element state like text field values, dialog visibility, or selected tabs. _Developers refactoring Compose screens can follow evolving state-holder guidance surfaced on daily.dev._ ### How does Navigation 3 handle screen-specific UI state compared to older Navigation approaches that relied on ViewModel? Navigation 3 gives each navigation entry ownership of its own state: navigation arguments belong to a NavKey data class, while UI state tied to a destination can be preserved using rememberSerializable instead of being pushed into a ViewModel. This removes navigation-related state responsibilities from ViewModel, leaving it focused on presentation logic and repository coordination. _Teams migrating to Navigation 3 can track this kind of architectural guidance via daily.dev._ ## Similar posts on daily.dev - [Android Architecture Is Moving from Event-Driven UI to State-Driven UI](https://daily.dev/posts/android-architecture-is-moving-from-event-driven-ui-to-state-driven-ui-dbg3ivujp) · ProAndroidDev · 15 upvotes · 2 comments - [AppState in Jetpack Compose: The Missing Piece for Building Large-Scale Android Apps](https://daily.dev/posts/appstate-in-jetpack-compose-the-missing-piece-for-building-large-scale-android-apps-gsrhvyqeq) · Medium · 2 upvotes · 1 comments - [Stop Passing ViewModels to Your Composables?](https://daily.dev/posts/stop-passing-viewmodels-to-your-composables--lshjhtw8a) · ProAndroidDev · 4 upvotes · 0 comments --- Tags: [#android](https://daily.dev/tags/android), [#jetpack-compose](https://daily.dev/tags/jetpack-compose) [View this post on daily.dev](https://daily.dev/posts/android-architecture-is-quietly-moving-beyond-viewmodel-as-a-state-holder-0e2pkua20) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Android Architecture Is Quietly Moving Beyond ViewModel as a State Holder","url":"https://daily.dev/posts/android-architecture-is-quietly-moving-beyond-viewmodel-as-a-state-holder-0e2pkua20","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/android-architecture-is-quietly-moving-beyond-viewmodel-as-a-state-holder-0e2pkua20"},"datePublished":"2026-07-31T09:11:43.659Z","dateModified":"2026-09-13T19:30:06.852Z","description":"Android architecture is evolving away from treating ViewModel as the universal state holder. With Jetpack Compose and Navigation 3, each type of state now has...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/5aa2443601f4efb1c57650e1b0dfaf0e?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/5aa2443601f4efb1c57650e1b0dfaf0e?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"ProAndroidDev","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"ProAndroidDev","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/656c1eb1f1ef4f91936e86fc16545114","url":"https://daily.dev/sources/pand"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/android-architecture-is-quietly-moving-beyond-viewmodel-as-a-state-holder-0e2pkua20","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":12},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"android,jetpack-compose","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"ProAndroidDev","item":"https://daily.dev/sources/pand"},{"@type":"ListItem","position":3,"name":"Android Architecture Is Quietly Moving Beyond ViewModel as a State Holder"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/android-architecture-is-quietly-moving-beyond-viewmodel-as-a-state-holder-0e2pkua20#faq","mainEntity":[{"@type":"Question","name":"Should UI state like dialog visibility or scroll position always be stored in a ViewModel in Jetpack Compose?","acceptedAnswer":{"@type":"Answer","text":"No, current Android architecture guidance recommends keeping such UI-only state closest to where it is consumed, using remember or rememberSaveable inside the composable rather than moving it into a ViewModel. ViewModel is now described as a business logic state holder responsible for coordinating repositories and exposing UI state, not for owning transient UI element state like text field values, dialog visibility, or selected tabs. Developers refactoring Compose screens can follow evolving state-holder guidance surfaced on daily.dev."}},{"@type":"Question","name":"How does Navigation 3 handle screen-specific UI state compared to older Navigation approaches that relied on ViewModel?","acceptedAnswer":{"@type":"Answer","text":"Navigation 3 gives each navigation entry ownership of its own state: navigation arguments belong to a NavKey data class, while UI state tied to a destination can be preserved using rememberSerializable instead of being pushed into a ViewModel. This removes navigation-related state responsibilities from ViewModel, leaving it focused on presentation logic and repository coordination. Teams migrating to Navigation 3 can track this kind of architectural guidance via daily.dev."}}]} ```