A user reported that the app kept resetting to light mode on every restart even though they'd set it to dark.
The bug was embarrassingly simple: I was only updating a StateFlow. The ViewModel emitted the new theme, Compose recomposed, everything looked correct — until the process died. On the next cold start, the MutableStateFlow initialised with a hardcoded default and the persisted preference was never read.
That's the most common Compose dark mode bug. This post covers the full production pattern that prevents it.
Start With an Enum, Not a Boolean
A Boolean gives you light or dark. Users need a third option: follow the system.
enum class ThemeMode(val value: Int) {
LIGHT(0), DARK(1), SYSTEM(2)
}
SYSTEM as the default (value = 2) is the right out-of-the-box experience. Storing .value as an Int keeps SharedPreferences simple.
Persist With SharedPreferences
object ThemePreferences {
private const val PREFS_NAME = "com.example.theme_prefs"
private const val KEY = "theme_mode"
private const val DEFAULT = ThemeMode.SYSTEM.value
private fun prefs() = App.context
.getSharedPreferences(PREFS_NAME, Context.MODE_PRIVATE)
var theme: Int
get() = prefs().getInt(KEY, DEFAULT)
set(value) { prefs().edit().putInt(KEY, value).apply() }
}
Don't use PreferenceManager.getDefaultSharedPreferences() — it's deprecated in the AndroidX Preference library. Call getSharedPreferences() directly.
Don't reach for DataStore either. Its async read means you need a splash or loading state to avoid a first-frame flicker. SharedPreferences' synchronous getInt() completes before the first frame — exactly what you want for a theme preference.
ThemeViewModel: Two Writes, Not One
class ThemeViewModel : ViewModel() {
private val _themeMode = MutableStateFlow(
ThemeMode.entries.first { it.value == ThemePreferences.theme }
)
val themeMode: StateFlow<ThemeMode> = _themeMode.asStateFlow()
fun setTheme(mode: ThemeMode) {
ThemePreferences.theme = mode.value // survives process death
_themeMode.value = mode // drives recomposition now
}
}
This is where most tutorials stop — they emit to the StateFlow and call it done. Without the SharedPreferences write, the theme resets on every cold start.
AppCompatDelegate is intentionally absent here. It belongs in the Activity, not the ViewModel. More on that in a moment.
AppTheme: Resolve the Boolean, Build the Scheme
@Composable
fun AppTheme(
themeMode: ThemeMode,
content: @Composable () -> Unit
) {
val darkTheme = when (themeMode) {
ThemeMode.LIGHT -> false
ThemeMode.DARK -> true
ThemeMode.SYSTEM -> isSystemInDarkTheme()
}
val customColors = if (darkTheme) DarkAppColors else LightAppColors
val colorScheme = if (darkTheme) {
darkColorScheme(
primary = Color(0xFF2C3638),
secondary = Color(0xFFBDBDBD),
background = Color(0xFF1E1F25),
surface = Color(0xFF1E1F25),
onPrimary = Color.White,
error = Color(0xFFB00020),
)
} else {
lightColorScheme(
primary = Color(0xFFFBFBFB),
secondary = Color(0xFF276EF7),
background = Color(0xFFFBFBFB),
surface = Color(0xFFFBFBFB),
onPrimary = Color.Black,
error = Color(0xFFB00020),
)
}
MaterialTheme(colorScheme = colorScheme) {
CompositionLocalProvider(
LocalCustomColors provides customColors,
LocalIsDarkTheme provides darkTheme,
) {
content()
}
}
}
Use darkColorScheme() / lightColorScheme() — not the ColorScheme(...) constructor directly. The factory functions supply safe defaults for all 30 M3 roles; the constructor requires every single role to be explicitly set or it won't compile.
isSystemInDarkTheme() is Compose-aware — reading it inside a composable automatically triggers recomposition when the system mode changes. No manual observer needed.
Why Two Color Systems? (The Part Most Tutorials Skip)
M3 gives you 30 color roles. If your app has more than 30 semantic colors — cardBackgroundColor, dividerColor, inputFieldBorderColor, sectionHeaderColor, and so on — you have two bad options:
-
Overload M3 roles: now
surfacemeans three different things in different contexts. -
Nest
MaterialThemeat the component level: causes unnecessary recomposition and makes the theme graph confusing.
The right answer is a second color system via CompositionLocal:
data class AppColors(
val colorPrimary: Color,
val backgroundColor: Color,
val cardBackgroundColor: Color,
val dividerColor: Color,
val primaryTextColor: Color,
val sectionHeaderColor: Color,
// ...
)
val LightAppColors = AppColors(
colorPrimary = Color(0xFF276EF7),
backgroundColor = Color(0xFFFBFBFB),
cardBackgroundColor= Color(0xFFFFFFFF),
dividerColor = Color(0xFFE0E0E0),
primaryTextColor = Color(0xFF212121),
sectionHeaderColor = Color(0xFF757575),
)
val DarkAppColors = AppColors(
colorPrimary = Color(0xFFBDBDBD),
backgroundColor = Color(0xFF1E1F25),
cardBackgroundColor= Color(0xFF2C3638),
dividerColor = Color(0xFF3A3A3A),
primaryTextColor = Color(0xFFEEEEEE),
sectionHeaderColor = Color(0xFF9E9E9E),
)
val LocalCustomColors = staticCompositionLocalOf { LightAppColors }
val LocalIsDarkTheme = staticCompositionLocalOf { false }
Use staticCompositionLocalOf — not compositionLocalOf. For a root-level theme that changes rarely, staticCompositionLocalOf invalidates the entire subtree on change (correct for a full theme swap) and has lower per-frame overhead since there's no per-consumer tracking.
Expose the colors through a single access object:
object AppThemeColor {
val colors: AppColors
@Composable
@ReadOnlyComposable
get() = LocalCustomColors.current
}
Screens call AppThemeColor.colors.cardBackgroundColor instead of MaterialTheme.colorScheme.surface. Clean semantics, no ambiguity, and M3 components still get their roles via the partial ColorScheme mapping.
MainActivity: Where AppCompatDelegate Lives
If your app has any XML-based Activities or dialogs, AppCompatDelegate.setDefaultNightMode() must stay in sync with the theme. It belongs in the Activity reacting to the StateFlow — not in the ViewModel (wrong layer, threading risk).
class MainActivity : AppCompatActivity() {
private val themeViewModel: ThemeViewModel by viewModels()
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
lifecycleScope.launch {
themeViewModel.themeMode.collect { mode ->
AppCompatDelegate.setDefaultNightMode(
when (mode) {
ThemeMode.LIGHT -> AppCompatDelegate.MODE_NIGHT_NO
ThemeMode.DARK -> AppCompatDelegate.MODE_NIGHT_YES
ThemeMode.SYSTEM -> AppCompatDelegate.MODE_NIGHT_FOLLOW_SYSTEM
}
)
}
}
setContent {
val themeMode by themeViewModel.themeMode.collectAsStateWithLifecycle()
AppTheme(themeMode = themeMode) {
AppNavigation(themeViewModel = themeViewModel)
}
}
}
}
collectAsStateWithLifecycle() requires androidx.lifecycle:lifecycle-runtime-compose — add it if it's not already in your dependencies.
Critical: the lifecycleScope collector runs after the first frame. To avoid a flicker on cold start, restore AppCompatDelegate in Application.onCreate() synchronously:
class App : Application() {
override fun onCreate() {
super.onCreate()
AppCompatDelegate.setDefaultNightMode(
when (ThemeMode.entries.first { it.value == ThemePreferences.theme }) {
ThemeMode.LIGHT -> AppCompatDelegate.MODE_NIGHT_NO
ThemeMode.DARK -> AppCompatDelegate.MODE_NIGHT_YES
ThemeMode.SYSTEM -> AppCompatDelegate.MODE_NIGHT_FOLLOW_SYSTEM
}
)
}
}
The Settings Toggle
@Composable
fun ThemeSettingsSection(
currentTheme: ThemeMode,
onThemeSelected: (ThemeMode) -> Unit
) {
val options = listOf(
ThemeMode.LIGHT to "Light",
ThemeMode.DARK to "Dark",
ThemeMode.SYSTEM to "System default"
)
Column {
Text(
text = "App theme",
style = MaterialTheme.typography.labelLarge,
color = AppThemeColor.colors.sectionHeaderColor
)
Spacer(modifier = Modifier.height(8.dp))
options.forEach { (mode, label) ->
Row(
modifier = Modifier
.fillMaxWidth()
.clickable { onThemeSelected(mode) }
.padding(vertical = 12.dp, horizontal = 16.dp),
verticalAlignment = Alignment.CenterVertically
) {
RadioButton(selected = currentTheme == mode, onClick = { onThemeSelected(mode) })
Spacer(modifier = Modifier.width(12.dp))
Text(text = label, color = AppThemeColor.colors.primaryTextColor)
}
}
}
}
For conditional values outside AppThemeColor — like an icon tint — read LocalIsDarkTheme.current instead of calling back into the ViewModel:
val isDark = LocalIsDarkTheme.current
val iconTint = if (isDark) Color.White else Color.Black
Mistakes That Bite in Production
Only emitting to StateFlow. Without the SharedPreferences write, the theme resets on every cold start. This is the original bug.
Putting AppCompatDelegate in the ViewModel. It must run on the main thread. The lifecycleScope collector guarantees that. A ViewModel function can be called from coroutines on any dispatcher.
Skipping the Application.onCreate() startup call. The lifecycleScope collector fires after the first frame. Without the startup call, Activities briefly flash the wrong theme before the collector updates it.
Caching the isSystemInDarkTheme() result. It's a Compose state read — it must be called inside the composition. Cache it outside and you'll miss system mode changes.
FAQ
Does this work on Android below API 29?
isSystemInDarkTheme() returns false on API 28 and below — those versions don't support system dark mode. ThemeMode.SYSTEM effectively behaves like ThemeMode.LIGHT on pre-Q devices. Users can always manually select DARK from Settings.
Do I need to add android:configChanges="uiMode"?
No — for most apps, omit it. Without that flag, the system recreates XML Activities automatically on a uiMode change, which is correct. Adding it suppresses recreation and forces you to handle onConfigurationChanged() yourself.
How do I preview both themes in Android Studio?
@Preview(name = "Dark", uiMode = Configuration.UI_MODE_NIGHT_YES)
@Preview(name = "Light", uiMode = Configuration.UI_MODE_NIGHT_NO)
@Composable
fun MyScreenPreview() {
AppTheme(themeMode = ThemeMode.DARK) { MyScreen() }
}
ThemeMode is a plain enum — no fake ViewModel needed in previews.
Originally published at suridevs.com