dotnet-trace<\/code> and\ndotnet-gcdump<\/code> respectively. These can give insights into performance\nproblems in your application, NuGet packages, or even something we\nshould look into for .NET MAUI.<\/p>\nBackground<\/h2>\n
By default, .NET MAUI applications on iOS and Android use the\nfollowing settings:<\/p>\n
\n- “Self-contained”, meaning a copy of the BCL and runtime are included\nwith the application.<\/li>\n<\/ul>\n
<\/i>Note<\/strong><\/p>This makes .NET MAUI applications suitable for running on “app stores” as no prerequisites such as installing a .NET runtime are required.<\/div><\/p>\n\n- Partially trimmed (
TrimMode=partial<\/code>), meaning that code within\nyour applications or NuGet packages are not trimmed by default.<\/li>\n<\/ul>\n<\/i>Note<\/strong><\/p>This is a good default, as it is the most compatible with existing code and NuGet packages in the ecosystem.<\/div><\/p>\nFull Trimming<\/h2>\n
This is where full-trimming (TrimMode=full<\/code>) can make an impact on\nyour application’s size. If you have a substantial amount of C# code\nor NuGet packages, you may be missing out on a significant application\nsize reduction.<\/p>\nTo opt into full trimming, you can add the following to your .csproj<\/code> file:<\/p>\n<PropertyGroup>\r\n <TrimMode>full<\/TrimMode>\r\n<\/PropertyGroup><\/code><\/pre>\nFor an idea on the impact of full trimming:<\/p>\n
![\"Impact](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2025\/02\/android-full-trimming.svg\")
<\/p>\n
<\/i>Note<\/strong><\/p> MyPal<\/a> is a sample .NET MAUI application that is a useful comparison because of its usage of several common NuGet packages.<\/div><\/p>\nSee our trimming .NET MAUI documentation<\/a> for more\ninformation on “full” trimming.<\/p>\nNativeAOT<\/h2>\n
Building upon full trimming, NativeAOT both relies on libraries being\ntrim-compatible and<\/em> AOT-compatible. NativeAOT is a new runtime that\ncan improve startup time and reduce application size compared to\nexisting runtimes.<\/p>\n<\/i>Note<\/strong><\/p>NativeAOT is not yet supported on Android, but is available on iOS, MacCatalyst, and Windows.<\/div><\/p>\nTo opt into NativeAOT:<\/p>\n
<PropertyGroup>\r\n <IsAotCompatible>true<\/IsAotCompatible>\r\n <PublishAot>true<\/PublishAot>\r\n<\/PropertyGroup><\/code><\/pre>\nFor an idea on the impact of NativeAOT and application size:<\/p>\n
![\"Impact](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2025\/02\/nativeaot-filesize.svg\")
<\/p>\n
And startup performance:<\/p>\n
![\"Impact](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2025\/02\/nativeaot-startup.svg\")
<\/p>\n
<\/i>Note<\/strong><\/p>macOS<\/code> on the above graphs is running on MacCatalyst<\/code>, the default for .NET MAUI applications running on Mac operating systems.<\/div><\/p>\nSee our NativeAOT deployment documentation<\/a> for more\ninformation about this newly supported runtime.<\/p>\nNuGet Package Authors<\/h2>\n
As a NuGet package author, you may wish for your package to run in\neither fully trimmed or NativeAOT scenarios. This can be useful for\ndevelopers targeting .NET MAUI, mobile, or even self-contained ASP.NET\nmicroservices.<\/p>\n
To support NativeAOT, you will need to:<\/p>\n
\n- Mark your assemblies as “trim-compatible” and “AOT-compatible”.<\/li>\n
- Enable Roslyn analyzers for trimming and NativeAOT.<\/li>\n
- Solve all the warnings.<\/li>\n<\/ol>\n
Begin with modifying your .csproj<\/code> file:<\/p>\n<PropertyGroup>\r\n <IsTrimmable>true<\/IsTrimmable>\r\n <IsAotCompatible>true<\/IsAotCompatible>\r\n<\/PropertyGroup><\/code><\/pre>\nThese properties will enable Roslyn analyzers as well as include\n[assembly: AssemblyMetadata]<\/code> information in the resulting .NET\nassembly. Depending on your library’s usage of features like\nSystem.Reflection, you could have either just a few warnings or\npotentially many<\/em> warnings.<\/p>\nSee the documentation on preparing libraries for\ntrimming<\/a> for more information.<\/p>\nXAML and Trimming<\/h2>\n
Sometimes, taking advantage of NativeAOT in your app can be as easy as\nadding a property to your project file. However, for many .NET MAUI\napplications, there can be a lot of warnings to solve. The NativeAOT\ncompiler removes unnecessary code and metadata to make the app smaller\nand faster. However, this requires understanding which types can be\ncreated and which methods can and cannot be called at runtime. This is\noften impossible to do in code which heavily uses System.Reflection.\nThere are two areas in .NET MAUI which fall into this category: XAML\nand data-binding.<\/p>\n
Compiled XAML<\/h3>\n
Loading XAML at runtime provides flexibility and enables features like\nXAML hot reload. XAML can instantiate any class in the whole app, the\n.NET MAUI SDK, and referenced NuGet packages. XAML can also set values\nto any property.<\/p>\n
Conceptually, loading a XAML layout at runtime requires:<\/p>\n
\n- Parsing the XML document.<\/li>\n
- Looking up the control types based on the XML element names using
Type.GetType(xmlElementName)<\/code>.<\/li>\n- Creating new instances of the controls using
Activator.CreateInstance(controlType)<\/code>.<\/li>\n- Converting the raw string XML attribute values into the target type of the property.<\/li>\n
- Setting properties based on the names of the XML attributes.<\/li>\n<\/ol>\n
This process can not only be slow, but it presents a great challenge\nfor NativeAOT. For example, the trimmer does not know which types\nwould be looked up using the Type.GetType<\/code> method. This means that\neither the compiler would need to keep all the classes from the whole\n.NET MAUI SDK and all the NuGet packages in the final app, or the\nmethod might not be able to find the types declared in the XML input\nand fail at runtime.<\/p>\nFortunately, .NET MAUI has a solution – XAML compilation<\/a>.\nThis turns XAML into the actual code for the InitializeComponent()<\/code>\nmethod at build time. Once the code is generated, the NativeAOT\ncompiler has all the information it needs to trim your app.<\/p>\nIn .NET 9, we implemented the last remaining XAML features that the\ncompiler could not handle in previous releases, especially compiling\nbindings. Lastly, if your app relies on loading XAML at runtime,\nNativeAOT might not be suitable for your application.<\/p>\n
Compiled Bindings<\/h3>\n
A binding ties together a source property with a target property. When\nthe source changes, the value is propagated to the target.<\/p>\n
Bindings in .NET MAUI are defined using a string<\/code> “path”. This path\nresembles C# expressions for accessing properties and indexers. When\nthe binding is applied to a source object, .NET MAUI uses\nSystem.Reflection to follow the path to access the desired source\nproperty. This suffers from the same problems as loading XAML at\nruntime, because the trimmer does not know which properties could be\naccessed by reflection and so it does not know which properties it can\nsafely trim from the final application.<\/p>\nWhen we know the type of the source object at build time from\nx:DataType<\/code> attributes, we can compile the binding path into a simple\ngetter method (and a setter method for two-way bindings). The compiler\nwill also ensure that the binding listens to any property changes\nalong the binding path of properties that implement\nINotifyPropertyChanged<\/code>.<\/p>\nThe XAML compiler could already compile most bindings in .NET 8 and\nearlier. In .NET 9 we made sure any binding in your XAML code can be\ncompiled. Learn more about this feature in the compiled bindings\ndocumentation<\/a>.<\/p>\nCompiled bindings in C#<\/h3>\n
The only supported way of defining bindings in C# code up until .NET 8\nhas been using a string<\/code>-based path. In .NET 9, we are adding a new\nAPI which allows us to compile the binding using a source generator:<\/p>\n\/\/ .NET 8 and earlier\r\nmyLabel.SetBinding(Label.TextProperty, \"Text\");\r\n\r\n\/\/ .NET 9\r\nmyLabel.SetBinding(Label.TextProperty, static (Entry nameEntry) => nameEntry.Text);<\/code><\/pre>\nThe Binding.Create()<\/code> method is also an option, for when you need to\nsave the Binding<\/code> instance for later use:<\/p>\nvar nameBinding = Binding.Create(static (Entry nameEntry) => nameEntry.Text);<\/code><\/pre>\n.NET MAUI’s source generator will compile the binding the same way the\nXAML compiler does. This way the binding can be fully analyzed by the\nNativeAOT compiler.<\/p>\n
Even if you aren’t planning to migrate your application to NativeAOT,\ncompiled bindings can improve the general performance of the binding.\nTo illustrate the difference, let’s use BenchmarkDotNet<\/code> to measure\nthe difference between the calls to SetBinding()<\/code> on Android using the\nMono runtime:<\/p>\n\/\/ dotnet build -c Release -t:Run -f net9.0-android\r\n\r\npublic class SetBindingBenchmark\r\n{\r\n private readonly ContactInformation _contact = new ContactInformation(new FullName(\"John\"));\r\n private readonly Label _label = new();\r\n\r\n [GlobalSetup]\r\n public void Setup()\r\n {\r\n DispatcherProvider.SetCurrent(new MockDispatcherProvider());\r\n _label.BindingContext = _contact;\r\n }\r\n\r\n [Benchmark(Baseline = true)]\r\n public void Classic_SetBinding()\r\n {\r\n _label.SetBinding(Label.TextProperty, \"FullName.FirstName\");\r\n }\r\n\r\n [Benchmark]\r\n public void Compiled_SetBinding()\r\n {\r\n _label.SetBinding(Label.TextProperty, static (ContactInformation contact) => contact.FullName?.FirstName);\r\n }\r\n\r\n [IterationCleanup]\r\n public void Cleanup()\r\n {\r\n _label.RemoveBinding(Label.TextProperty);\r\n }\r\n}<\/code><\/pre>\nWhen I ran the benchmark on Samsung Galaxy S23, I got the following results:<\/p>\n