Choosing the Right Framework for Your Cross-Platform Development

In today's fast-paced development landscape, selecting the right cross-platform framework is key to building successful applications. With options like Uno Platform, Flutter, MAUI, React Native, and others, how do you decide which one fits your project's needs? This session will explore the strengths and weaknesses of popular frameworks, considering factors such as performance, ecosystem, and development experience. Whether you're targeting mobile, web, or desktop, we'll help you navigate the pros and cons to make an informed decision for your next cross-platform project.

Target Audience: Developers and technical decision-makers evaluating cross-platform frameworks for their projects.
First Public Delivery: Based on my session "Migrating Xamarin Forms apps to .NET 8 – you got options!" from Techorama 2023
Preferred Session Duration: 45 minutes with a 15-minute Q&A.
Additional Info: Covers a comparative analysis of major frameworks, highlighting when each may be a better fit based on project requirements and constraints.

Migrating Xamarin Forms apps to .NET 8 – you got options!

Xamarin.Forms are nearing its end-of-life on May 1, 2024. You should be thinking of migrating your apps to .NET 8. Of course, you can and should consider .NET MAUI, but how about other .NET mobile ecosystem options you have, options which can help you accomplish migration goal faster?

In this session we will explore the pros and cons of the options you have. We will discuss important architectural considerations, as well as key considerations, such as UI/UX adjustments, non-UI APIs, platform-specifics, and improving your new app performance along the way.

We will guide you through the essential steps and best practices for migrating your Xamarin.Forms applications to Uno Platform and convert a sample app from Xamarin Forms to Uno Platform right before your eyes.

Gain insights, ask questions, and be better equipped for important migration conversations to come.

I Compared Cross-Platform Frameworks. Then I Went to Work on Two of Them.

A couple of years ago I built a talk comparing .NET MAUI, Uno Platform, Flutter, Avalonia and React Native. I had tables, pros and cons, and a winner for almost every scenario. Then I started working on two of them.

Since then I've done tooling and NativeAOT work on .NET MAUI, and implemented controls, accessibility and platform APIs in Uno. I should say up front that I now work on MAUI, so treat my scoring with suspicion - which is roughly what I'm going to argue you should do with anybody's framework comparison, including my old one.

What changed isn't the ranking, it's the questions. Who actually owns the control you're using, and what happens the day you need it to do something its author never intended? What do you do when the accessibility tree, the native view tree and the XAML tree disagree about what is on screen? A demo that looks identical on six devices tells you almost nothing about month six of the project.

So: real bugs, public pull requests, and a proper look at native versus drawn UI, plus the evaluation questions I'd ask now instead of the ones I asked then. There is no universal winner. I checked twice.

For developers and technical decision-makers evaluating or maintaining cross-platform applications. This is a new follow-up to my earlier framework-comparison talk, now based on public implementation work in .NET MAUI and Uno Platform. No product pitch. Preferred duration: 60 minutes including Q&A.

Semantics Lost in Translation: Accessibility Beyond XAML

Setting AutomationProperties.Name is a good start. It is not an accessibility strategy.

A cross-platform control has to turn into UI Automation on Windows, NSAccessibility on macOS, ARIA in the browser, UIAccessibility on iOS and AccessibilityNodeInfo on Android, and then survive contact with VoiceOver, TalkBack, NVDA and whatever the user has actually configured. Roles that look equivalent often aren't. Focus moves differently on every one of them. Virtualized controls vanish and come back as something slightly different. Fairly often the screen reader is reading a tree the app developer has never seen.

Drawing on accessibility work in Uno Platform and its Toolkit, and on native-tree inspection in .NET MAUI, I'll walk through cases where the intent made it across and cases where it quietly didn't: a TabBar announced as a generic group, a virtualized item that disappears from the automation tree, a popup with no dismiss action, and a high-contrast theme that updates only part of the page.

Less about which properties exist, more about why setting them correctly still isn't enough. The bar isn't parity between platforms. It's someone getting through your app.

For UI developers who know basic accessibility properties and want to understand the native layer beneath them. Includes screen-reader and automation demonstrations using public Uno Platform and .NET MAUI work. Preferred duration: 60 minutes including Q&A.

Who Owns the Click? When Humans and Agents Share a Running App

A browser inspector, a VS Code extension, a CLI and a coding agent all connect to the same running app. Reading state is easy. The trouble starts when two of them decide to tap the button.

Working on the shared inspector behind .NET MAUI DevFlow, we kept hitting problems that belonged in a distributed systems talk rather than a UI tooling one: a screenshot from 400ms ago paired with bounds from now, two clients mutating at once, a client that disconnected without telling anybody, a webview we had no reason to trust, and a recording that had to keep working when it changed hands mid-session.

I'll go through what we ended up with and what it cost us - mainly an app-scoped lease, so only one client can mutate at a time, and immutable snapshots, so nobody acts on a view of the app that stopped being true two frames ago. Both are less convenient than they sound. I'll also reproduce a couple of the races live, including my favorite category of bug, where the click lands on precisely the wrong element and every layer of the stack cheerfully reports success.

Very little of this turned out to be MAUI-specific. Mostly it was about deciding who is allowed to touch the app, and being willing to say when we didn't know.

For developers building agentic tools, IDE integrations, test infrastructure or remote inspectors. Based on the public experimental .NET MAUI DevFlow architecture. Preferred duration: 60 minutes including Q&A.

A Text Box Is Never Just a Text Box: Rich Editing Across Platforms

Most controls are manageable until text editing shows up. Then you inherit selection, caret movement, IME composition, touch handles, clipboard, formatting, spell checking, undo, scrolling, accessibility, and a startling number of opinions from every operating system involved.

I implemented RichEditBox for Uno's Skia targets, and I also maintain Storylines, my own writing app, which means I get to be both the person who ships the bug and the person it happens to. Rich text turned out not to be a control. It's a small platform hiding in a rectangle.

We'll follow a single keystroke the whole way down: input, document model, layout, render. Then the places that path comes apart - an IME caught mid-composition, a selection dragged with a finger rather than a mouse, an undo stack that has to agree with the platform's own idea of undo. I'll show what I managed to share across platforms and where I gave up and went native, which happened considerably more often than I expected going in.

If you thought a text box was the easy part, I have bad news and some quite good diagrams.

For UI and framework developers interested in text input, rendering and accessibility. Based on public Uno Platform RichEditBox work and lessons from maintaining Storylines. Preferred duration: 60 minutes including Q&A.