What if you could launch your mobile apps 40% faster, reduce their size by 25%, and simplify your development workflow, all with a single migration?

That’s exactly what developers achieve by moving from Xamarin to .NET MAUI. But here’s the catch: while Microsoft ended Xamarin support in May 2024, many teams are still stuck in the old ecosystem, missing out on these game-changing performance improvements.

In this guide, we’ll show you not just how to migrate, but how to do it strategically to maximize your performance gains while avoiding the common pitfalls that trip up 70% of migration projects.

Easily build cross-platform mobile and desktop apps with the flexible and feature-rich controls of the Syncfusion .NET MAUI platform.

Explore Now

Migration challenges and how to overcome them

Relearning the project structure

Xamarin: Developers are used to creating separate projects for each platform, such as Android and iOS, which often results in platform-specific folders and logic.

.NET MAUI: You can create cross-platform applications (Windows, Android, iOS, and macOS) with a single project and shared codebase.

Challenge: Teams used to platform-specific folders in Xamarin.Forms and logic must now adapt to .NET MAUI’s consolidated format.

Tip: Start with a new .NET MAUI template and migrate features gradually. This helps to clean up legacy code and adopt the .NET MAUI way of structuring apps.

Custom renderer to handler transition

Xamarin.Forms:  Multiple projects require the creation of custom renderers for platform-specific UI.

.NET MAUI: Introduces handlers for better performance, flexibility and reducing time consumption.

Challenge: Need to reimplement the custom renderers using the new handler architecture in .NET MAUI.

Tip: Identify frequently customized controls and prioritize converting them to handlers in .NET MAUI.

Third-party library gaps

Challenge: Not all Xamarin.Forms libraries have migrated to .NET MAUI.

Tip: Check your NuGet dependencies early. If replacements aren’t available, consider writing custom solutions or temporarily isolating such features.

Platform-specific code rework

Challenge: Code using Xamarin’s platform APIs, like DependencyService, might not port directly.

Tip: Leverage #if directives carefully for any unavoidable platform code.

Syncfusion .NET MAUI controls are well-documented, which helps to quickly get started and migrate your Xamarin apps.

Read Now

Performance wins that make it worthwhile

Despite the hurdles, moving to .NET MAUI delivers significant runtime and developer productivity gains:

Faster app launch time

.NET MAUI supports Ahead-of-Time (AOT) compilation, resulting in significantly faster cold and warm starts than Xamarin.Forms.

Smaller app size

Thanks to .NET MAUI optimization and trimming features, .NET MAUI apps often ship with a reduced footprint across all platforms.

Syncfusion .NET MAUI controls allow you to build powerful line-of-business applications.

Explore Now

Better memory management

.NET MAUI apps show improved memory usage, leading to smoother performance on lower-end devices.

Smoother UI interactions

The new handler architecture removes renderer overhead and improves responsiveness in touch, animation, and transitions.

To make it easy for developers to include Syncfusion .NET MAUI controls in their projects, we have shared some working ones.

Explore Now

Best practices for a successful migration

• Start clean: Don’t try to “upgrade in place.” Create a new .NET MAUI project and migrate components selectively.
• Test constantly: Use physical devices across platforms and form factors to catch behavioral inconsistencies early.
• Refactor incrementally: Begin with core logic, then bring views and platform features.
• Engage with the .NET MAUI community: Microsoft’s GitHub, Discord, and .NET MAUI documentation are active and resourceful.

FAQs

Q: Why migrate from Xamarin to .NET MAUI?
A: .NET MAUI offers faster app launches, smaller sizes, better memory management, and a unified codebase for cross-platform development.

Q: What are the main challenges when migrating from Xamarin to .NET MAUI?
A: Developers often face issues with project structure, custom renderers, and third-party library compatibility.

Q: How can I ensure a smooth migration to .NET MAUI?
A: Start with a clean project, test frequently, and engage with the .NET MAUI community for support.

Q: What performance benefits does .NET MAUI offer over Xamarin?
A: .NET MAUI provides faster app launch times, smaller app sizes, better memory management, and smoother UI interactions.

Q: What platforms does .NET MAUI support?
A: .NET MAUI supports Android, iOS, macOS, and Windows from a single codebase.

Q: Is .NET MAUI production-ready for enterprise applications?
A: Yes, .NET MAUI is supported by Microsoft and is suitable for building robust, enterprise-grade applications.

Q: Can I reuse my existing Xamarin.Forms code in .NET MAUI?
A: Yes, especially business logic and view models. However, UI and platform-specific code may need adjustments.

Q: How does .NET MAUI handle platform-specific functionality?
A: It uses a unified API supporting platform-specific code via partial classes and dependency injection.

Q: How is the community and support ecosystem for .NET MAUI?
A: .NET MAUI is open source, actively updated on GitHub, and supported by Microsoft through Microsoft Learn, Q&A, and official documentation.

Supercharge your cross-platform apps with Syncfusion's robust .NET MAUI controls.

Try it Now FREE

Conclusion

Ready to Transform Your Mobile Development Strategy? The migration from Xamarin to .NET MAUI isn’t just about staying current; it’s about giving your apps a competitive edge with faster performance, smaller footprints, and streamlined development. Don’t let this opportunity slip by. While your competitors struggle with outdated Xamarin apps, you can build the next generation of cross-platform applications.

Ready to build high-performance apps with ease? Explore Syncfusion’s .NET MAUI components, built to help developers like you deliver smooth, fast, and modern cross-platform experiences.

Yesterday, I wrote about how to test custom events in Playwright.

In building out the tests for Kelp’s web components, I ran into an interesting challenge on the ready events I emit when the component is first instantiated.

Today, I wanted to explain the problem, and how I fixed it. Let’s dig in!

The challenge

Kelp uses an HTML Web Component approach for most of it’s components, but there are a few exceptions where that doesn’t make sense.

For example, the <kelp-toc> component generates a table of contents from the headings on the page. There’s no meaningful fallback state for that, so it starts out as an empty HTML element.

<kelp-toc></kelp-toc>

Typically in Playwright, you…

1. Use one of the page.locator() methods to get your element.
2. Wait for it to be found/loaded.
3. Wait for your event to run.

const component = page.locator('kelp-toc');
const readyEvent = await component.evaluate((element) => {
		return new Promise((resolve) => {
			return element.addEventListener('kelp-toc-ready', () => {
				return resolve(true);
			});
		})
	});
await expect(readyEvent).toBeTruthy();

That works great for HTML Web Components, but fails on step 2 for JS-rendered ones like <kelp-toc>.

Timing issues

Step 2—wait for it to be found/loaded—doesn’t run until the element has a visible bounding rectangle.

Because custom elements are treated like a <span>, and <kelp-toc> is empty by default, it has a height and width of 0. To Playwright, it’s not loaded yet.

By the time Playwright recognizes it—after the content has been rendered—the event has already fired, and the event listener/promise never resolves. The test fails.

There’s a simple fix!

One of the things I love about Playwright is that it tests real HTML files.

I’m using it for component testing rather than end-to-end, so each test spec has a corresponding HTML file with the markup hard-coded into it. I like this a lot better than having to dynamically inject HTML with JS for testing!

|-- /tests
|   |-- /toc
|       |-- index.html
|       |-- toc.spec.js

In the test HTML, I add an event listener for the ready event before the web component JavaScript is loaded.

When the event fires, I log ready to the console. This is actually an import part of the test!

<script>
	// Ensures we can test the ready event
	document.addEventListener('kelp-toc-ready', (event) => {
		console.log('ready');
	});
</script>

<script type="module" src="../../js/components/kelp-toc.js"></script>

Over in my test file, I…

1. Define an isReady variable as false.
2. Use the Playwright page.on('console') method to listen for console events. If the console text is ready, set isReady to true.
3. Navigate to the test index.html file
4. Check if isReady is true.

test('component instantiates', async ({ page }) => {
	let isReady = false;
	page.on('console', msg => {
		if (msg.text() !== 'ready') return;
		isReady = true;
	});
	await page.goto('/tests/toc');
	expect(isReady).toEqual(true);
});

Is it silly? Yes! Does it work? Also yes!

This wouldn’t be a great solution in an end-to-end test, where you’d be logging this stuff in the actual app. But for unit/component testing, it works great!

Like this? A Lean Web Club membership is the best way to support my work and help me create more free content.

A customer called the Format­Message function with the FORMAT_MESSAGE_ALLOCATE_BUFFER flag, and they weren’t sure what to do if the function fails (by returning 0). Do they have to free the buffer by calling Local­Free?

No, you don’t have to free the buffer. In fact, on failure, there is no buffer. The function failed to perform the desired operation, so there is nothing to clean up.

You can make things easier on yourself by pre-initializing the output pointer to NULL. That way, if the function fails, the pointer is still null. Then your logic can be “Go ahead and free the buffer,” because the Local­Free function allows you to pass NULL, and it just ignores it. (This trick allows things like wil::unique_hlocal_string to work with FormatMessage.)

Thinking about the original question: You can’t tell whether the reason for the function failure is that something went wrong during formatting or that something went wrong during allocation of the final output buffer. You could call Get­Last­Error(), but if it returns ERROR_OUT_OF_MEMORY, you still don’t know whether it ran out of memory during the formatting phase or during the final buffer allocation phase. Therefore, even if you wanted to free the buffer, you don’t know whether you even got one in the first place.

The post If the <CODE>Format­Message</CODE> function fails, and I requested that it allocate a buffer, do I have to free the buffer? appeared first on The Old New Thing.

A couple of weeks ago, the AI terminal app Warp released its 2.0 product, which it is calling an “Agentic Development Environment.” I will be reviewing this product shortly, but in the meantime, I carried out an email interview with Warp CEO Zach Lloyd. I’ve been a long-time fan (and user) of Warp, mainly because it is a great terminal available for every OS.

While AI assistance in the terminal is useful, it had seemed that with all the major LLMs competing to get into code editors, AI would eventually pull away from the command line — that is, until the agentic era hit us. Warp seems well-placed to take advantage of agentic AI, since Claude Code resides in your aging terminal application. So I had plenty of questions for Zach.

David: The very first thing I noticed about Warp 2.0 was that it now has its own code editor. I realise it’s just for quick and dirty hacking, but how strong was the wish in the team to create a code editor in Warp?

Zach: Our philosophy is that coding by hand is going to become less common and go away entirely over time, but right now, there are definitely still times when you need to hop in and make manual changes.

The code editor in Warp isn’t designed for writing code from scratch. The main use case we’re focused on is human review of agent-written code. While most of the time people don’t need to use a code editor in Warp at all, when they do, we think there are two main ways for a human to intervene: one is by re-prompting the agent, and the other is by directly editing the code.

“Our philosophy is that coding by hand is going to become less common and go away entirely over time.”
– Zach Lloyd, Warp CEO

So the goal with the editor is to make sure you don’t have to context-switch out of Warp just to make a small change. We want to take the editing functionality far enough that it’s usable and convenient within that workflow, without needing to jump into a separate IDE.

David: It is amazingly sparse which is nice. How much functionality are you going to give it?

Zach: You’re right that our editor is intentionally sparse. That’s by design. We’re not trying to recreate a full-featured IDE. But we do plan to add what we consider table-stakes functionality for basic editing: Things like formatting on save, linting, simple LSP support — just enough to make the experience smooth when you need it.

That said, we have a real advantage on the UI side compared to other tools in the space like Claude Code, Codex CLI, or Gemini CLI. Those products can’t build a WYSWYG editor at all — let alone a great code review experience.

David: You have put LLMs in the faces of grumpy developers for some time, but even now people ask “Why do I need AI for a terminal?” Are you tempted to release a Warp Classic that removes the LLM aspect to leave a cleaner terminal?

Zach: The solution we’ve landed on is pretty simple: there’s a single toggle in Warp’s settings where you can just turn AI off. It removes all AI features from Warp. We don’t think we need to make a totally separate app that’s just a terminal without AI, since it’s easy for users to disable it if they want to.

But personally, I really believe Warp is an incredible AI tool; and if you’re not using the AI features, you’re kind of handicapping yourself as a developer. We know not everyone sees that right away, so the real challenge for us is helping users reach that aha moment. Once they do, they usually don’t want to go back.

“…if you’re not using the AI features, you’re kind of handicapping yourself as a developer.”

The most common way that happens is when someone hits an error in the terminal and Warp just fixes it for them — like your Python dependencies are messed up, or you’re stuck debugging a Docker issue, and Warp steps in and solves it. I want to keep giving even AI skeptics a chance to bump into those moments; because when they do, it can really change how they work.

David: How are you going to maximize this ADE [Agentic Development Environment] moment before the LLM creators move the action back into the cloud?

Zach: Yeah, this really feels like our moment. The zeitgeist is shifting toward terminal-based coding agents — a big move away from the traditional IDE. That’s because people are starting to get the value of the terminal interface. Whether it’s Warp’s ADE, Claude Code, Codex, Gemini CLI, or others, the idea of having a time-based log and an imperative interface — where you just tell the agent what you want and it does it — is emerging as the best way to work with AI.

That’s a much smoother experience than trying to use a side panel or chat window inside a VS Code clone. Those setups feel clunky by comparison and having the whole screen optimized for interacting with an agent just works better.

Since launching ADE, we’ve seen daily paid signups jump by about 5x — even accounting for discounts — so the traction is real.

“…the idea of having a time-based log and an imperative interface — where you just tell the agent what you want and it does it — is emerging as the best way to work with AI.”

What’s wild is that most professional developers still haven’t changed their workflows — the people trying agentic tools today are mostly hobbyists, vibe coders, or AI early adopters. Our focus is on building for pros — developers working on real codebases — and giving them the right tools to manage, edit, and review agent-written code. That requires a much deeper interface than a typical terminal app can offer.

That’s why being the outer platform — with full control over the UI — is such an advantage. We’re really one-of-a-kind right now because we’re the only purpose-built agent platform that isn’t a VS Code clone or a CLI wrapper.

As for whether the action moves back to the cloud — if the question is whether we’ll support cloud-based agents like Devin or Factory, I think we probably will. But only if we can make the transition between local and remote feel seamless. That’s the bar we’re aiming for.

David: It’s likely there will be an increased need for token use monitoring and process monitoring as agentic threads go wild. How do you plan to keep Warp’s UI advantage?

Zach: Yes, we definitely have an advantage here because we have a really nice UX for managing agent multithreading.

As people start running more agents at once, costs can climb quickly. One big piece of feedback we’ve heard is that Warp can feel “token hungry,” so we have a major engineering effort underway to make it more efficient without sacrificing quality. This includes optimizing which models we use for different tasks and possibly raising limits, so users don’t hit them so fast.

“As people start running more agents at once, costs can climb quickly.”

On the UI side, we have a big edge over CLI apps with a fully native agent management layer — including system notifications, in-tab updates, and a unified view to track all your agents. We’re going to keep pushing that further and make agent management an even more central, first-class part of the app. While the UI is still fairly minimal today, it already offers a much better way to see, control, and intervene — something only Warp can do given our place in the stack.

David: Now that Warp works in Linux, Mac and Windows, are you slowly (or fast) losing your Mac-first startup mentality?

Zach: Yes, we definitely try to be platform agnostic. Most of us started on Mac and still work on Mac daily, but we also have team members who use Warp on Windows and Linux every day.

I actually think we have a big advantage on Windows. Tools like Claude Code, Codex, and other CLI-based setups don’t really work in PowerShell as far as I know — you pretty much need WSL. So if you’re a Windows developer and you want to do agentic development without WSL, Warp is really the only great option. We definitely want to keep pushing to make Warp awesome across all platforms.

David: Is Rust helping you keep the speed you want everywhere? I noticed that the new Ladybird browser has chosen Swift over Rust.

Zach: Rust has been a pretty good choice. We looked at web tech with Electron early on, and I think there are basically two good options for cross-platform desktop development: Rust or Electron.

The big advantage of Electron is faster development time — no doubt about that. There are more libraries and a bigger ecosystem, so you have to rebuild less. We ultimately went with Rust, though, because we wanted higher performance and more control. Developing in a web sandbox can be a pain — with Rust, we get real threads, direct memory access, and much deeper system integration. You could probably do some of that with Electron, but it’s a lot more of a hassle. I also think Rust is just much faster overall.

“We ultimately went with Rust […] because we wanted higher performance and more control.”

I don’t know much about Ladybird or why they chose Swift over Rust, but my understanding is that using Swift cross-platform is still kind of a research project rather than something production-ready. I think other teams have tried it, but it hasn’t really taken off yet. So, for us, picking something truly built for cross-platform like Rust just made more sense.

David: MCP seems like a natural outlet for Warp, but so far it still feels experimental on most platforms — and a little awkward. In terms of control and UI, is Warp jumping on MCP or waiting to see how it catches on?

Zach: I’ve hooked up our crash reporting, Sentry, to Notion, and it lets me do things like tell Warp, “Hey, fix this Linear issue,” and just paste in a Linear link, or “Help me debug this server crash,” and paste in a Sentry link.

We’re fully leaning into MCP. Where it really shines for Warp is when CLI integrations don’t exist. One of the powerful things about being at the terminal layer is that our first choice is always: is there a CLI tool that can gather the context? If there is, we’ll call that since it’s faster and more native.

For example, we’re not going to use a Git MCP server when we can just run a Git command, and we’ll always prefer the GitHub CLI over using the GitHub MCP server. Basically, if there’s a good CLI, we’ll use it.

But for a lot of tools, there isn’t a solid CLI — tools like Notion or Linear are great examples. For those, having a super easy MCP integration really opens up a lot of context.

We’re definitely jumping on MCP. We’re investing heavily to make it easier to install, easier to share, and easier to debug.

A Final Note From David

Whether you are onboard with LLMs assisting development or not (and as Zach says, many professional developers have absolutely not changed their workflows), Zach’s insights should help you see why agentic developers will receive plenty of love from the professional tool community in the future.

The post Q&A: How Warp 2.0 Compares to Claude Code and Gemini CLI appeared first on The New Stack.