Kotlin Jetpack Compose Design Patterns

What this prompt does

This prompt scaffolds a modern Android app in Jetpack Compose using current design patterns. It moves through six steps: setting up a layered architecture, implementing state management, building type-safe navigation, creating a Material 3 design system, applying accessibility practices, and optimizing recomposition performance. The result is a coherent foundation where screens stay stateless and predictable as the app grows, which is what keeps a multi-module project from drifting into spaghetti.

The variables tailor the scaffold to your project. [architecture_pattern] and [dependency_injection] set the structural backbone, [module_count] defines the multi-module layout, and [state_approach] decides how UI state flows. [screen_count] and [nav_graph_count] shape the navigation graph, [brand_name] and [font_family] drive theming, [touch_target_size] enforces accessibility minimums, and [profiling_tool], [image_library], and [frame_budget] govern the performance pass. Each variable maps to a concrete decision you would otherwise make ad hoc on day one.

When to use it

• You are starting a native Android app and want a Compose architecture decided up front.
• You need a stateless-screen, hoisted-state pattern instead of logic scattered in composables.
• You want type-safe navigation across [screen_count] screens and nested graphs.
• You are building a Material 3 theme with light, dark, and dynamic color support.
• You want accessibility handled deliberately rather than retrofitted before launch.
• You need a concrete plan for hunting unnecessary recompositions and hitting a frame budget.

Example output

Expect a module structure for a multi-module project, a BaseViewModel exposing UI state via StateFlow and one-time events via SharedFlow, and a sealed UiState with Loading/Success/Error variants. From there you get a type-safe navigation graph with bottom navigation and deep linking, a Material 3 theme definition with light/dark color schemes and a typography scale, reusable composable components, accessibility annotations, and a recomposition-optimization checklist. It is a mix of architecture description and Kotlin code spread across the presentation, domain, and data layers, with the state-hoisting pattern applied so that screens receive state plus event callbacks rather than owning logic themselves.

Pro tips

• Match [architecture_pattern] and [state_approach] to your team's experience; MVI with StateFlow is powerful but adds ceremony for small apps, so weigh the overhead against the size of the project.
• Set [module_count] to reflect real feature boundaries, not an arbitrary number, so the module graph stays meaningful.
• Make sure [screen_count] and [nav_graph_count] are consistent with the flows you actually have, including auth and onboarding back-stack handling.
• Keep [touch_target_size] at the platform minimum or above; accessibility scanners flag anything smaller.
• Use [profiling_tool] early and feed real findings back into the prompt; recomposition wins come from removing wasted work, not adding code.
• Pick an [image_library] you already use so lazy loading integrates cleanly with your existing build and caching setup.