I’ve been working on a new commercial AI Skill for .NET MAUI developers called MemoryToolkit: Intelligence.
Its goal is to review your MAUI application source code and identify places where your app may be intersecting with known memory leak-prone conditions in the MAUI framework.
Before releasing it, I’m putting it through its paces against real-world, open-source MAUI applications to see how well it performs.
If you have a freely licensed, publicly hosted, open-source .NET MAUI application you’d like me to review, post a link in the comments and I’ll reply with the generated report.
I’m particularly interested in testing against a wide variety of application architectures, coding styles, and control groups.
Why build something like this?
One of the frustrating things about debugging memory leaks in MAUI is that many of them don’t actually look like bugs.
Sometimes the problem is clearly application code. If you create a repeating timer or subscribe to a long-lived event and never clean it up, that’s on you.
But there are also many cases where perfectly ordinary-looking code can accidentally wander into a known leak-prone area of the framework.
Examples include things like:
- assigning a long-lived
ObservableCollection to the wrong control’s ItemsSource
- dynamically rebuilding certain visual trees
- interacting with particular handler lifecycle behaviors
- replacing content in ways that have historically retained native handlers
- using combinations of controls or features that have known framework retention history
None of those are obviously “wrong” when you’re writing the code.
You might say that developing a MAUI application can sometimes feel like navigating a minefield--but that's not quite right.
When you step on a landmine, at least you have the benefit of immediately knowing something happened.
With most MAUI leak conditions, nothing obvious happens at all (not at first). You quietly arm the trap, everything appears to work perfectly, and then minutes later your app is sluggish, Android is complaining about GREF pressure, and you’re left trying to remember what changed nine navigation flows ago.
Why does this matter?
Regardless of where a leak originates, the user-facing symptoms are usually the same:
- progressively increasing memory usage
- UI sluggishness and animation jank
- increasingly aggressive garbage collection
- growing native resource pressure (especially Android GREFs)
- eventually, the operating system terminating the process
How much this matters depends entirely on your application and your users.
Some apps are only used for a few minutes at a time and may never encounter a problem.
Others are expected to remain open all day. I once consulted for a field-services customer that literally had a written requirement stating the application had to complete a specific number of consecutive workflows before crashing! (spoiler alert: GREF exhaustion)
How is this different from MemoryToolkit.Maui?
A while back I released MemoryToolkit.Maui, which helps detect leaks after they’ve already happened. It can help tell you what leaked and when it leaked, making those invisible tripwires much easier to spot at runtime.
This new Skill is intended to be proactive instead of reactive.
Rather than trying to magically determine whether your application definitely leaks, it starts from a curated knowledge base of 400+ verified MAUI memory retention conditions, organized into more than 20 architectural leak families.
It then reviews your source code looking for places where your application appears to intersect with those known conditions.
Importantly, it doesn’t say:
“You definitely have a memory leak on line 123.”
Instead it asks:
“Does this code closely resemble a historically leak-prone framework condition?”
For each finding, the report explains:
- Why the pattern was flagged
- The technical impact if the condition is real (retained pages, visual trees, BindingContexts, native handlers, Android GREF pressure, etc.)
- Why the chosen severity and confidence levels make sense
- The closest matching known framework condition
- Links to relevant repro projects and MAUI issues
- Suggested mitigations
- How I would empirically validate the finding with runtime profiling
- What successful validation should look like after the mitigation
The goal isn’t to replace memory profilers.
It’s to teach AI years of hard-earned .NET MAUI memory debugging experience and help developers identify historically dangerous patterns before they become production issues.
Again, if you’d like me to run the preview against your public .NET MAUI repository, post a link below and I’ll reply with the generated report.
I’m especially interested in repositories that make the Skill look silly 🙂
