compose-multiplatform-patterns
Compose Multiplatform and Jetpack Compose patterns for KMP projects — state management, navigation, theming, performance, and platform-specific UI. Use when building Compose or Jetpack Compose UI, state, navigation, or theming in a KMP project.
By affaan-m · 2,902 installs
npx skills add affaan-m/ecc --skill compose-multiplatform-patterns
Source repository · Upstream listing
Compose Multiplatform Patterns
Patterns for building shared UI across Android, iOS, Desktop, and Web using Compose Multiplatform and Jetpack Compose. Covers state management, navigation, theming, and performance.
When to Activate
Building Compose UI (Jetpack Compose or Compose Multiplatform)
Managing UI state with ViewModels and Compose state
Implementing navigation in KMP or Android projects
Designing reusable composables and design systems
Optimizing recomposition and rendering performance
State Management
ViewModel + Single State Object
Use a single data class for screen state. Expose it as StateFlow and collect in Compose:
Collecting State in Compose
Event Sink Pattern
For complex screens, use a sealed interface for events instead of multiple callback lambdas:
Navigation
Type Safe Navigation (Compose Navigation 2.8+)
Define routes as @Serializable objects:
Dialog and Bottom Sheet Navigation
Use dialog() and overlay patterns instead of imperative show/hide:
Composable Design
Slot Based APIs
Design composables with slot parameters for flexibility:
Modifier Ordering
Modifier order matters — apply in this sequence:
KMP Platform Specific UI
expect/actual for Platform Composables
Performance
Stable Types for Skippable Recomposition
Mark classes as @Stable or @Immutable when all properties are stable:
Use key() and Lazy Lists Correctly
Defer Reads with derivedStateOf
Avoid Allocations in Recomposition
Theming
Material 3 Dynamic Theming
Anti Patterns to Avoid
Using mutableStateOf in ViewModels when MutableStateFlow with collectAsStateWithLifecycle is safer for lifecycle
Passing NavController deep into composables — pass lambda callbacks instead
Heavy computation inside @Composable functions — move to ViewModel or remember {}
Using LaunchedEffect(Unit) as a substitute for ViewModel init — it re runs on configuration change in some setups
Creating new object instances in composable parameters — causes unnecessary recomposition
References
See skill: android clean architecture for module structure and layering.
See skill: kotlin coroutines flows for coroutine and Flow patterns.