01 / Audit
A baseline on your devices
Startup, slow screens and sync, timed on the phones, tablets or terminals your users have.
.NET MAUI apps that start fast and don't freeze.
We find out why your .NET MAUI app is slow. We measure it on real devices, fix the causes, and measure again. You see before and after numbers from the same build type.
9.1 s → 1.9 s wait for Home after login,
Android debug build
Android debug build
8–17 s → 0 UI stalls, sync stress
test, debug build
test, debug build
Where .NET MAUI apps get slow.
Most .NET MAUI performance optimization starts in one of these four places. The examples come from a field-service app we have built since 2024.
Startup [first screen · after login]
Work that runs before the first screen: pages built at launch, data loaded before first paint, database calls on the UI thread. After login, the wait for the Home screen dropped from 9.1 s to 1.9 s. We measured it with adb and logcat on an Android phone, in a debug build.
UI thread [freezes · jank]
The app shared one SQLite connection, so sync writes blocked UI reads. We gave each database context its own pooled connection. In an 80-second stress test of 410 rows on a device, in a debug build, stalls of 8 to 17 seconds went to zero. There were zero "database is locked" errors.
Sync and local data [sqlite · datasync]
On a real account, auto-generated dashboard snapshots were about 64% of synced bytes and 73% of synced records. Automatic recalculations now save a snapshot only when its value changes. Logging back in on the same device syncs only what changed.
Memory and crashes [ios · mac]
On iOS and Mac, we traced crashes on the .NET finalizer thread to native objects that were already freed. We now dispose native image objects on time. This work continues.
How we measure .NET MAUI performance.
Numbers first, then code changes.
Slow startup: timed on real devices, not simulators
Simulators run on a desktop CPU with plenty of memory. They hide the slow startup and freezes your users see on a mid-range Android phone. So we measure on physical devices, ideally the models your users carry.
Rugged scanners and payment terminals often have less memory than a new phone. We work with that hardware on our .NET MAUI POS projects.
On Android, we read timing logs with adb and logcat. That is how we timed the wait for the Home screen above.
UI freezes and memory crashes: traces, heap dumps and Sentry
Timings show where the app is slow. Profilers show why.
- dotnet-trace: where CPU time goes during startup or on a slow screen.
- dotnet-gcdump: which objects stay in memory after a page closes.
- Xcode Instruments: time profiles, allocations and freed native objects on iOS and Mac.
- Sentry: the crashes your users hit in production.
For .NET MAUI SQLite performance, we also check how many connections the app opens and what waits on what.
Debug and release numbers are different
A debug build is set up for the debugger, not for speed. A release build of the same app gives different numbers. So we never compare a debug "before" with a release "after".
Our 9.1 s → 1.9 s and 8–17 s → 0 results come from debug builds, and we say so. When release numbers matter to you, we measure release builds.
Why an app can feel slower after a Xamarin or UWP migration
Teams moving from Xamarin.Forms or UWP often ask if .NET MAUI is slower. Mario Galván, founder:
"MAUI is not slower by itself, but it is stricter than UWP, especially on Android. Some patterns that worked in UWP can now block the UI and make the app feel slow."
So when a migrated app feels slow, we look for those patterns before anyone talks about a rewrite. Still planning the move? See how we move Xamarin and UWP apps to .NET MAUI.
Hiring a .NET MAUI performance consultant
We are senior .NET MAUI engineers in Colima, Mexico. We work US business hours, in your repository, through pull requests your team reviews. If speed is one problem among several, start with rescue work on late .NET MAUI projects. Our other services are on the .NET MAUI experts home page.
Want these numbers for your own app? Ask for a performance audit. We measure on your device models first.
What a performance audit gives you.
We measure the app on real devices and give you a ranked list of fixes with before numbers.
02 / Audit
A ranked list of causes
Where each cause lives in the code and what it costs your users. The most expensive come first.
03 / Audit
Fixes with before and after numbers
Small pull requests, then the same measurement on the same build type, so you can compare.
04 / Audit
Checks that keep it fast
Unit tests around the changed code, and a pull request check that fails when new code hides an exception.
The app behind these numbers.
The client stays anonymous. Each number says how we measured it.
01 2026
A faster Home screen after login, and no UI stalls in a sync stress test.
One .NET MAUI codebase builds white-label apps for Android, iOS, Windows and Mac. After login, the wait for the Home screen dropped from 9.1 s to 1.9 s, measured on a physical Android phone in a debug build. In a sync stress test on a device, also in a debug build, main-thread stalls of 8 to 17 seconds went to zero.
9.1 s → 1.9 s
wait for Home after login, Android debug
8–17 s → 0
UI stalls, sync stress test, debug build
4 days
.NET 10 upgrade, first commit to merge
.NET MAUI.NET 10SQLiteMac Catalyst
Want numbers like these for your app?
Audit my app's performanceFrom symptoms to numbers.
01 ───
Call about the symptoms
Which screens feel slow, which devices your users have, how you build releases. You get a straight answer on fit.
Before any work
02 ───
Audit and baseline
We time and profile the slow paths on real devices. You get a baseline and a ranked list of causes.
Before numbers
03 ───
Fix the top causes
The most expensive causes first, each in a small pull request your team reviews.
In your repo
04 ───
Measure again and hand over
Same devices, same build type, same steps. You get before and after numbers and notes on what changed.
After numbers
Questions about slow .NET MAUI apps.
Q.01
Not by itself. But .NET MAUI is stricter than UWP, especially on Android. Patterns like database calls on the UI thread can freeze an app after the move. We find and fix them one at a time. Planning the move? See Xamarin to .NET MAUI migration.
Q.02
Yes. The results on this page came from targeted changes. For example, one shared SQLite connection became a pooled connection per database context.
Q.03
Not to start. We test on physical Android and iOS devices. But an older phone or a rugged scanner shows problems that a new phone hides, so tell us the models your users carry.
Q.04
Our 9.1 s → 1.9 s result (the wait for the Home screen after login) and our sync stress test are from debug builds. A release build gives different numbers, so we compare the same build type and label it. Need release numbers? We measure release builds.
Q.05
Yes. Some crashes are memory problems, like the iOS and Mac finalizer crashes above, and they fit in a performance audit. If the app crashes in many places or is late for a date, start with rescue for a late .NET MAUI project.
Which screen makes
your users wait?
// reach-us
contact@lemonlabs.mx +1 (779) 232-9848 Av. de los Diamantes 53–9
Residencial Esmeralda Nte.
28017 Colima, Colima, México