StackLayout performance degrades in .NET MAUI (1s) vs Xamarin (0.5s) with 100+ labels in Release Mode

[PleatMan]

Description

We’re seeing a significant performance difference in page creation time between Xamarin and MAUI, resulting in what feels like a freeze when navigating pages — a very noticeable and not user-friendly experience.

🎥 https://youtube.com/shorts/MTms2MMd4Yc

Background

Due to Xamarin being deprecated and mobile platform requirements for updated SDKs, we were forced to migrate to MAUI. After years of effort refining our Xamarin app, MAUI has unfortunately felt like starting over.

After migrating our production app to MAUI (initially v8, now v9), we noticed that each page creation takes 2–3 seconds — which is an unacceptable user experience and would be a noticeable regression for our existing Xamarin users.

We initially suspected something in our app, but after extensive testing and community research, we created a controlled sample app and were able to confirm the same performance issue.

Test Setup

We created identical apps in Xamarin and MAUI with 3 pages:

• Page 1 → 100 bindings
• Page 2 → 200 bindings
• Page 3 → 300 bindings

Each test logs:

• InitializeComponent time
• ViewModel creation/binding
• OnAppearing execution time

Devices tested:

• iPhone 11 – iOS 18.5
• Xiaomi 12 – Android 13
• Samsung M31 – Android 14

Performance Comparison

Quick overview

Phone	App	Log line	Page 1	Page 2	Page 3
iPhone 11	Xamarin	OnAppearing total time	112 ms	147 ms	188 ms
iPhone 11	MAUI	OnAppearing total time	820 ms	1551 ms	2300 ms
Xiaomi 12	Xamarin	OnAppearing total time	240 ms	348 ms	501 ms
Xiaomi 12	MAUI	OnAppearing total time	683 ms	1193 ms	1533 ms
Samsung M31	Xamarin	OnAppearing total time	691 ms	790 ms	1078 ms
Samsung M31	MAUI	OnAppearing total time	1691 ms	2609 ms	3659 ms

Detailed data table

Detailed data table

Phone	Page	Log line	Xamarin	MAUI
iPhone 11	Page 1	InitializeComponent	12 ms	317 ms
iPhone 11	Page 1	OnAppearing time	91 ms	486 ms
iPhone 11	Page 1	OnAppearing total time	112 ms	820 ms
iPhone 11	Page 2	InitializeComponent	26 ms	622 ms
iPhone 11	Page 2	OnAppearing time	113 m	905 ms
iPhone 11	Page 2	OnAppearing total time	147 ms	1551 ms
iPhone 11	Page 3	InitializeComponent	28 ms	930 ms
iPhone 11	Page 3	OnAppearing time	152 ms	1336 ms
iPhone 11	Page 3	OnAppearing total time	188 ms	2300 ms
Xiaomi 12	Page 1	InitializeComponent	36 ms	363 ms
Xiaomi 12	Page 1	OnAppearing time	188 ms	301 ms
Xiaomi 12	Page 1	OnAppearing total time	240 ms	683 ms
Xiaomi 12	Page 2	InitializeComponent	58 ms	665 ms
Xiaomi 12	Page 2	OnAppearing time	270 m	503 ms
Xiaomi 12	Page 2	OnAppearing total time	348 ms	1193 ms
Xiaomi 12	Page 3	InitializeComponent	103 ms	930 ms
Xiaomi 12	Page 3	OnAppearing time	367 ms	561 ms
Xiaomi 12	Page 3	OnAppearing total time	501 ms	1533 ms
Samsung M31	Page 1	InitializeComponent	96 ms	944 ms
Samsung M31	Page 1	OnAppearing time	537 ms	697 ms
Samsung M31	Page 1	OnAppearing total time	691 ms	1691 ms
Samsung M31	Page 2	InitializeComponent	170 ms	1604 ms
Samsung M31	Page 2	OnAppearing time	536 m	946 ms
Samsung M31	Page 2	OnAppearing total time	790 ms	2609 ms
Samsung M31	Page 3	InitializeComponent	225 ms	2245 ms
Samsung M31	Page 3	OnAppearing time	727 m	1316 ms
Samsung M31	Page 3	OnAppearing total time	1078 ms	3659 ms

Repository & Resources

🔗 GitHub repo (sample project):
https://github.com/PleatMan/MauiOpenPagePerformanceIssue

🔍 Speedscope traces:

• MAUI Android release speedscope
• MAUI iOS release speedscope

📦 Ready-to-test APKs:

• MAUI Android APK
• Xamarin Android APK

If others want to help test, please post your results and phone/OS details in the comments.

Sample Code Snippet

public partial class Page1 : ContentPage
{
....
    protected override async void OnAppearing()
    {
        base.OnAppearing();

        // Give the UI time to render before stopping the stopwatch
        await Task.Delay(50); // Optional but helps with accuracy

        _stopWatch.Stop();
        _stopWatchTotal.Stop();

        _viewModel.PageOnAppearingTime = $"Page OnAppearing time: {_stopWatch.ElapsedMilliseconds} ms";
        _viewModel.PageOnAppearingTotalTime =  $"Page OnAppearing total time: {_stopWatchTotal.ElapsedMilliseconds} ms";
    }
}

Full code

Final Thoughts

Huge thanks to @Nikita for the amazing work on DotNet.Meteor. It allowed us to include the profiling.

🙏 And thank you @jfversluis, your youtube channel has been instrumental throughout our MAUI journey.

We’re hopeful this issue will gain traction — and that a performance fix can be prioritised. Let us know if any more diagnostics or logs are needed.

Steps to Reproduce

1. Install Xamarin App
2. Open App and tap on menu for each page and note the timings reported
3. Install Maui app
4. Open app and tap on menu for each page and note the timings reported

Expected result: Timings to be similar
Actual result: Maui App timings are much slower than the Xamarin App

Link to public reproduction project repository

https://github.com/PleatMan/MauiOpenPagePerformanceIssue

Version with bug

9.0.90 SR9

Is this a regression from previous behavior?

Yes, this used to work in Xamarin.Forms

Last version that worked well

Unknown/Other

Affected platforms

iOS, Android

Affected platform versions

iOS 18.5, Android 13, Android 14

Did you find any workaround?

No

Relevant log output

[similar-issues-ai]

We've found some similar issues:

• Slow Collectionview Rendering performance in Maui compared to Xamarin #24224 , similarity score: 83%
• Maui Performance Issues #14227 , similarity score: 83%

If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue.

Note: You can give me feedback by 👍 or 👎 this comment.

[PureWeen]

@PleatMan are you running all your tests in release mode?

Debug mode is slower on maui compared to xf but release mode should perform the same or better

[albyrock87]

@PleatMan it seems like you're running in Debug mode given your speedscope shows clear sign of XAML loading.

I think it's really great you created this comparison, it will really be helpful if you can provide release-mode speedscopes so we can se where we can eventually improve :)

Edit: capturing time in OnAppearing is unfortunately not reliable as (you probably noticed) it does not include the layout/rendering time.

[mucco]

@PleatMan are you running all your tests in release mode?

Debug mode is slower on maui compared to xf but release mode should perform the same or better

I just ran this test on release mode on my android device:

App	Page 1	Page 2	Page 3
Xamarin	479ms	549ms	841ms
MAUI	562ms	1195ms	2310ms

So I can also definitely see a degradation

[PureWeen]

@PleatMan are you running all your tests in release mode?
Debug mode is slower on maui compared to xf but release mode should perform the same or better

I just ran this test on release mode on my android device:

Xamarin: 479-549-841 ms MAUI: 562-1195-2310 ms

So I can also definitely see a degradation

Can you log a new issue with a repro ?

https://github.com/dotnet/maui/wiki/Profiling-.NET-MAUI-Apps#feature-xyz-was-faster-in-xamarinforms

[PleatMan]

Hi @albyrock87, @PureWeen

Thank you so much for looking into this.

Sorry, you are right, when I build the tables with the timing and the speedscopes I was in debug mode.
The Android APKs added to the repository are in release mode, if you have Android phone and have a chance to try, it would be great.

So far based on @mucco and my data it seems that on Page 3 opening time in Maui release is almost 3x higher.

🔍 I updated the repo with release Speedscope traces:
MAUI Android release speedscope
MAUI iOS release speedscope

Also, I added the screen recording so you can quickly view the difference in performance running the release APKs in the repository. 🎥 https://www.youtube.com/shorts/BhY7IYENKdE

What I think it's very strange is that on Maui on page 3 the initialise component takes 681ms.

For convenience bellow are the timings reported in the video:

Phone	App	Log line	Page 1	Page 2	Page 3
Xiaomi 12	Xamarin release	OnAppearing total time	179 ms	224 ms	348 ms
Xiaomi 12	MAUI release	OnAppearing total time	254 ms	573 ms	1007 ms

---

Debug mode is slower on maui compared to xf but release mode should perform the same or better

@PureWeen I was hoping for that but unfortunately this doesn't seem to be the case. By the way such lags I also seen in other demo apps out there. (for example: https://www.syncfusion.com/demos/maui)

---

Edit: capturing time in OnAppearing is unfortunately not reliable as (you probably noticed) it does not include the layout/rendering time.

@albyrock87 Do you have any suggestions for better metrics?

[albyrock87]

@PleatMan alright, so constructing Page3 takes 47ms

where the majority of time seems to be spent in setting the style and applying resources.. we may have some room for improvement there.

maui/src/Controls/src/Core/Style.cs

Lines 161 to 180 in 1ce36ff

	ConditionalWeakTable<BindableObject, object> specificities = new();
	void ApplyCore(BindableObject bindable, Style basedOn, SetterSpecificity specificity)
	{
	if (basedOn != null)
	((IStyle)basedOn).Apply(bindable, specificity.AsBaseStyle());
	#if NETSTANDARD2_0
	specificities.Remove(bindable);
	specificities.Add(bindable, specificity);
	#else
	specificities.AddOrUpdate(bindable, specificity);
	#endif
	foreach (Setter setter in Setters)
	setter.Apply(bindable, specificity);
	((AttachedCollection<Behavior>)Behaviors).AttachTo(bindable);
	((AttachedCollection<TriggerBase>)Triggers).AttachTo(bindable);
	}

maui/src/Controls/src/Core/ResourcesExtensions.cs

Lines 52 to 69 in 1ce36ff

	public static bool TryGetResource(this IElementDefinition element, string key, out object value)
	{
	while (element != null)
	{
	if (element is IResourcesProvider ve && ve.IsResourcesCreated && ve.Resources.TryGetValue(key, out value))
	return true;
	if (element is Application app && app.SystemResources != null && app.SystemResources.TryGetValue(key, out value))
	return true;
	element = element.Parent;
	}
	//Fallback for the XF previewer
	if (Application.Current != null && ((IResourcesProvider)Application.Current).IsResourcesCreated && Application.Current.Resources.TryGetValue(key, out value))
	return true;
	value = null;
	return false;
	}

The remaining time is spent on mapping the virtual view to the platform view (413ms)

Going down the rabbit hole we see that the majority of time is (obviously) spent on mapping Label properties, especially around MapText*

Looking in the code we can see an outlier:

This is definitely a bad actor, because in the initial mapping, it causes the re-run of all other mappers.

maui/src/Core/src/Handlers/Label/LabelHandler.iOS.cs

Lines 73 to 83 in d11465f

	public static void MapFormatting(ILabelHandler handler, ILabel label)
	{
	// Update all of the attributed text formatting properties
	handler.UpdateValue(nameof(ILabel.LineHeight));
	handler.UpdateValue(nameof(ILabel.TextDecorations));
	handler.UpdateValue(nameof(ILabel.CharacterSpacing));
	// Setting any of those may have removed text alignment settings,
	// so we need to make sure those are applied, too
	handler.UpdateValue(nameof(ILabel.HorizontalTextAlignment));
	}

Thanks to #27259 we could now skip those calls in the initial mapping, making it a lot faster: @PureWeen this seems a very easy win :)

Your demonstration focuses purely on Label which cannot represent a "global" performance comparison between MAUI and Xamarin, but it represents a valid "label" performance comparison for which we can surely improve the current situation.

My analysis is only on iOS here, but we should do similar checks also on Android.

[bnSonic]

From my experience so far, on Android it's way slower. If you can optimize that, our clients would be very happy - an ME TOO :D

BTW: I've tried to speed Android release build up by using AOT and LLVM but the Performance is the same (for any human … I have not stopped milliseconds ;)) - So currently I stay away from AOT/LLVM so at least I have a faster build time :D

Any hints/tips/solution to make the UI way faster on Android are appreciated :)

[albyrock87]

@PleatMan, regarding Android if I replace Page3's <Label>s with this, the InitializeComponent time goes down to 39ms from ~333ms.

        for (var i = 1; i <= 300; i++)
        {
            var label = new Label();
            // NOTE: this is not even a compiled binding
            label.SetBinding(Label.TextProperty, new Binding("Text" + i.ToString("000")));
            Vsl.Add(label);
        }

Looking at the speedscope we can see how CompileMethod takes a lot of time.

That method is the .NET JIT compiler which is trying to compile your 9000 lines of code inside InitializeComponent :)
That is so big because you have a XAML with 300+ nodes in it.
In a real world, you should never do that, which means that AOT compilation (which is enabled by default in Release mode) should take into consideration your normal InitializeComponent a compile it during the build time leading to acceptable timings.
A 9000 lines of code method cannot be compiled during build time.

Long story short, to run a real comparison, we need a real world application.

Would you mind retrying collecting Xamarin and MAUI speedscopes using best practices like the for loop above (or eventually a BindableLayout)?

Regarding iOS, I've opened #30864

@bnSonic if you want to share an android speed scope of your application with me (on Discord DM) I'd be fine taking a look to see where we could improve things.

[bnSonic]

Hm. If I understand that right, @PleatMan has built that Repro with 3 pages to show the speed from Maui in comparison with Xamarin. I think the page3 is not necessarily what anyone would do in a real world app and the goal is not to find a workaround to do exactly this faster with code behind?!
My understanding was that it shows that with Maui the speed degrades a lot more (see the speed comparison in the posting above - it starts a lot slower with page1 and then calculate the percentage from 1 to 2 and to 3 …)

I think it’s legit to build such extreme to show a case - isn’t it? :)

I can just say: with Maui, navigating from page to page it’s slower than with Xamarin. But of course you notice it more with complex page layouts!

If you take a ContentPage + Grid + 2 labels + a CollectionView with 10 strings in it - you might not understand this 🙃

If you have:
ContantPage with Grid with some borders in the cells with some controls in it that are built by grid+border+svg+Label

• a ContentView inside the grid that have more grids, informations in cells build with grids/borders/Labels and ore svg
• a ListView / CollectionView inside a Border with 50 or 200 items that are represented with a bit more complex layout with variable height …

… and if that Page creates 3 Complex views for the user to switch between in a tool bar …

Than you will notice that it is a bit on the slow side.
It wasn’t super fast with Xamarin anyway but with Maui it’s remarkably slower.

I haven’t had the time to test with Maui 9.0.90 though! I can talk about up to 9.080

Currently I’m all in to migrate 4 Apps from Xamarin to Maui for iOS and Android. I really don’t find the time to produce exact metrics for you I’m sorry.
I’m a bit sad as I chased “a lot” Maui bugs and problems lately, trying to find solutions or workarounds. It costs unbelievable amount of time but what should i do 😅 no realistic chance to go on with Xamarin (Xcode support not anymore)

Don’t read this in an angry way - it’s just to say I think it’s obvious that there are some serious performance and layout problems with Maui. No problem - that can happen and I’m sure you all had good reasons to change and renovate things on a low level! That should be considered a good think.

I just wish that you had the chance to accept that so many of us are telling and showing that there are problems and you - the team - say something like: “so now, put everything aside. Let’s look at the basic layout system. Something is odd here” 😅

I really hope you can improve Maui soon! I hate all this trouble and workarounds and that the forced switch to Maui feels a bit rushed (not you fault personally I’m sure) but I LOVE to be able to write Android and iOS apps with c# and a nice xaml layout language. That’s really cool and hope you understand that I REALLY honor you work!!