.NET MAUI Data Binding
Wire UI controls to ViewModel properties with compile-time safety, correct change notification, and minimal overhead. Prefer compiled bindings everywhere and treat binding warnings as build errors.
When to Use
- Adding
x:DataTypecompiled bindings to a new or existing page - Implementing
INotifyPropertyChangedor CommunityToolkitObservableObject - Creating or consuming
IValueConverter/IMultiValueConverter - Choosing the correct
BindingModefor a control property - Setting
BindingContextin XAML or code-behind - Using relative bindings (
Self,AncestorType,TemplatedParent) - Applying
StringFormat,FallbackValue, orTargetNullValue - Writing AOT-safe code bindings with
SetBindingand lambdas (.NET 9+)
When Not to Use
- CollectionView layouts / templates — use the
maui-collectionviewskill - Shell navigation parameters — use the
maui-shell-navigationskill - Service registration / DI — use the
maui-dependency-injectionskill - Property-change-triggered animations — use built-in .NET MAUI animation APIs
Inputs
- A .NET MAUI project targeting .NET 8 or later
- XAML pages or C# code-behind where bindings are declared
- A ViewModel class (or plan to create one)
Rules That Change the Answer
Apply these to every binding answer — they are the differences between "it compiles" and "it actually updates the UI".
Do not restructure a ViewModel or add a converter that the user did not ask for
and that fixes no real defect. Adding x:DataType is different: when you are
already editing a page's bindings, recommending compiled bindings is in scope.
Compiled Bindings — x:DataType Placement
Compiled bindings are 8–20× faster than reflection-based bindings and are
required for NativeAOT / trimming. Enable them with x:DataType.
Placement rules
Set x:DataType only where BindingContext is set:
- Page / View root — where you assign
BindingContext. - DataTemplate — which creates a new binding scope.
Do not scatter x:DataType on arbitrary child elements. Adding
x:DataType="x:Object" on children to escape compiled bindings is an
anti-pattern — it disables compile-time checking and reintroduces reflection.
DataTemplate always needs its own x:DataType
Enforce binding warnings as errors
These four codes are verified against .NET 10 / .NET 11 MAUI (
Build.Tasks/BuildException.cs,ErrorMessages.resx). Diagnostic numbering is SDK-band-sensitive — re-check againstBuildException.csbefore relying on it on a newer SDK.
Add to the .csproj:
If you promote XC0025 without enabling that switch, make sure the project has no
Source= / RelativeSource bindings — otherwise they will be reported.
Binding Modes
Set Mode explicitly only when overriding the default. Most properties
already have the correct default:
BindingContext and Property Paths
Every BindableObject inherits BindingContext from its parent unless
explicitly set. Property paths support dot notation and indexers:
Set BindingContext in XAML:
Or in code-behind (preferred with DI):
INotifyPropertyChanged and ObservableObject
Manual implementation
CommunityToolkit.Mvvm (recommended)
The source generator creates the Title property, PropertyChanged raise,
and LoadDataCommand automatically.
Value Converters — IValueConverter
Implement Convert (source → target) and ConvertBack (target → source):
Declare in XAML resources and consume:
ConverterParameter is always passed as a string — parse inside Convert:
Multi-Binding
Combine multiple source values with IMultiValueConverter:
Relative Bindings
StringFormat
Use Binding.StringFormat for simple display formatting without a converter:
Wrap the format string in single quotes when it contains commas or braces.
Binding Fallbacks
- FallbackValue — used when the binding path cannot be resolved or the converter throws.
- TargetNullValue — used when the bound value is
null.
.NET 9+ Code Bindings (AOT-safe)
Fully AOT-safe, no reflection:
Threading
MAUI automatically marshals PropertyChanged to the UI thread — you can raise
it from any thread. However, direct ObservableCollection mutations
(Add / Remove) from background threads may crash:


