.NET MAUI Theming
Apply light/dark mode support, custom branded themes, and runtime theme switching in .NET MAUI apps using AppThemeBinding, ResourceDictionary swapping, and system theme detection APIs.
When to Use
- Adding light and dark mode support to a .NET MAUI app
- Creating custom branded themes with ResourceDictionary
- Detecting and responding to system theme changes at runtime
- Letting users choose a preferred theme (light, dark, or system default)
- Combining OS-driven theme response with custom color palettes
When Not to Use
- Localization or language switching — see .NET MAUI localization docs
- Accessibility-specific visual adjustments — see .NET MAUI accessibility docs
- App icon or splash screen configuration — see .NET MAUI app icon docs
- Bootstrap-style class theming — see the
Plugin.Maui.BootstrapThemeNuGet package
Inputs
- A .NET MAUI project targeting .NET 8 or later
- XAML pages or C# UI code that need theme-aware styling
Workflow
- Detect the current theme approach in the project (AppThemeBinding, ResourceDictionary, or none).
- Choose the appropriate strategy: AppThemeBinding for simple light/dark, ResourceDictionary swap for custom/multiple themes, or both combined.
- Define theme resources — inline
AppThemeBindingvalues or separateResourceDictionaryfiles with matching keys. - Replace hardcoded colors with
DynamicResourcebindings (orAppThemeBindingmarkup) throughout XAML pages. - Add system theme detection via
Application.Current.RequestedThemeand theRequestedThemeChangedevent. - Implement user preference persistence with
Preferences.Set/Preferences.Getand apply on startup. - Verify Android
ConfigChanges.UiModeis set onMainActivityto avoid activity restarts on theme change. - Test both light and dark themes on at least one target platform, confirming all UI elements respond correctly.
Rules That Change the Answer
Check these rules against the user's scenario, and apply only the ones that
affect what they asked. UiMode and dictionary swapping matter for runtime theme
switching; they are noise in a question about setting up AppThemeBinding.
Answer narrowly, but completely. Completeness means showing the code that
implements what you recommended — not adding adjacent topics. If you recommend
DynamicResource, show the dictionary swap that makes it update. If the user asks
for light/dark colours in C#, show both SetAppThemeColor (colours) and the
generic SetAppTheme<T> (any bindable property type), and prefer resource keys over
scattered hardcoded colours. Do not tack on platform configuration the question
didn't raise.
Do not replace a working AppThemeBinding setup with ResourceDictionary
swapping (or vice versa) unless the user needs what the other approach provides —
more than two themes, or a user-selectable theme.
Choosing an Approach
AppThemeBinding (OS Light/Dark)
AppThemeBinding selects a value based on the current system theme. It supports Light, Dark, and an optional Default fallback.
Define the palette once — don't scatter literals
Putting {AppThemeBinding Light=#333333, Dark=#FFFFFF} on every element is the
single most common theming mistake: the palette ends up duplicated across dozens of
files and cannot be changed in one place. Recommend this shape as the final
answer, not inline literals:
Pages then need no theming markup at all — they pick the styles up implicitly.
Use an inline AppThemeBinding only for genuine one-offs, and even then reference
{StaticResource} keys rather than literal hex.
XAML (inline form, for one-offs)
C# Extension Methods
Show both when answering a "light/dark colours in C#" question — SetAppThemeColor
covers Color properties, SetAppTheme<T> covers everything else:
Prefer defining the values as resource keys and referencing them, rather than scattering hardcoded colours across the codebase.
ResourceDictionary Theming (Custom Themes)
Use separate ResourceDictionary files with matching keys to define themes, then swap them at runtime.
Step 1 — Define Theme Dictionaries
When using compiled XAML with x:Class (as shown below), each dictionary needs a code-behind that calls InitializeComponent(). Dictionaries loaded via Source without x:Class do not need code-behind.
LightTheme.xaml
LightTheme.xaml.cs
Create a matching DarkTheme.xaml / DarkTheme.xaml.cs with the same keys and different values.
Step 2 — Consume with DynamicResource
Use DynamicResource so values update when the dictionary is swapped at runtime:
Step 3 — Switch Themes at Runtime
🚨 Never call
MergedDictionaries.Clear()to swap a theme. The default MAUI template mergesResources/Styles/Colors.xamlandStyles.xamlintoApplication.Resources.Clear()removes those too, so every implicit style, brush and colour in the app silently disappears — buttons, entries and labels all revert to unstyled defaults. Verified: afterClear(),MergedDictionariesdrops from 2 to 1 and the template'sPrimarycolour no longer resolves.
Remove only the theme you added, and leave everything else alone:
System Theme Detection
Read the Current Theme
Override the System Theme
React to Theme Changes
Combining Both Approaches
Use AppThemeBinding with DynamicResource values for maximum flexibility — the
nested DynamicResource stays live, so swapping the dictionary updates the value
and the OS light/dark switch is still honoured:
Or react to system changes and swap full dictionaries:
Saving and Restoring User Preference
Store the user's choice with Preferences and apply it on startup:
Common Pitfalls
Android: ConfigChanges.UiMode is Required
MainActivity must include ConfigChanges.UiMode or theme-change events will not fire and the activity restarts instead of handling the change gracefully:
Without UiMode, toggling dark mode in Android settings causes a full activity restart — losing navigation state and appearing as a crash. With it declared, the app stays alive and RequestedThemeChanged fires, so pair this fix with a handler that re-applies the theme (see below).
DynamicResource vs StaticResource
When using ResourceDictionary theme switching, you must use DynamicResource:
DynamicResource only helps if something actually swaps the dictionary. When you
diagnose this, always show the swap and the system-theme hook alongside the fix —
otherwise the user has a corrected binding that still never updates:
Hardcoded Colors Break Theming
Avoid inline color values on elements that should respect the theme:
CSS Themes Cannot Be Swapped at Runtime
.NET MAUI supports CSS styling, but CSS-based themes cannot be swapped dynamically. Use ResourceDictionary theming for runtime switching.
Theme Keys Must Match Across Dictionaries
Every x:Key used in one theme dictionary must exist in all other theme dictionaries. A missing key causes a silent fallback to the default value, leading to inconsistent appearance.
Platform Support
Quick Reference
- OS light/dark →
AppThemeBindingmarkup extension - Theme colors in C# →
SetAppThemeColor(),SetAppTheme<T>() - Read OS theme →
Application.Current.RequestedTheme - Force theme →
Application.Current.UserAppTheme = AppTheme.Dark - Theme changes →
RequestedThemeChangedevent - Custom switching →
Removethe old theme fromMergedDictionaries, thenAddthe new one — neverClear() - Runtime bindings →
DynamicResource(notStaticResource) - Persist choice →
Preferences.Set/Preferences.Get
