Version 10 targets four native platform families
.NET MAUI 10 lets one C# and XAML project target Android, iOS, Mac Catalyst, and Windows. Shared controls, layouts, resources, navigation, data binding, graphics, and device APIs cover much of an ordinary application. Developers can drop into native platform APIs when the common layer is insufficient. That balance makes sense for an existing .NET team whose product genuinely needs mobile and desktop packages, especially when business logic already lives in C#.
A shared project does not produce identical applications without effort. Android uses its own .NET runtime path, iOS compiles ahead of time to native ARM code, macOS uses Mac Catalyst, and Windows uses WinUI 3. The framework keeps project structure and much UI code together while platform folders hold divergent implementation. Release 10.0.101 itself contains separate fixes for Android back handling, iOS safe areas and button styling, and Windows content assignment.
.NET 10 support depends on the development host
The .NET 10 platform table starts at Android 5.0, iOS 12.2, macOS 12 through Mac Catalyst, and Windows 10 version 1809. MAUI Blazor raises some floors, including iOS 16.4 and Android 7.0. There is no Linux desktop target in that official list. Samsung supplies additional Tizen support, but it sits outside the four primary targets Microsoft documents for the framework.
Build access changes with the host operating system. Windows can build Windows and Android applications locally. A networked Mac is required for iOS, and Apple builds need Xcode. macOS can build Android, iOS, and Mac Catalyst. Linux development supports Android through the maui-android workload. The b96aa03 checkout offered no Dockerfile that could flatten these host rules into our standard container process.
What happened when we ran it
Our lab did not execute installation, compilation, or tests for commit b96aa03. The harness had no supported ecosystem path for the repository's C# language, and the checkout had no Dockerfile. There are therefore no timings, dependency totals, test counts, or vulnerability results to report. Treating another npm folder or a partial script as the project would have created a number without answering whether MAUI itself builds.
The measurement setup was an unprivileged sandbox allocated 3 CPUs and 8 GB of RAM, with no secrets. Those resources never became a MAUI test environment because the required C# route was absent. This is a coverage limit in our lab, not evidence that the framework fails to build. It also means our score cannot benefit from a clean install or passing suite, and it should not be read as an independent performance result.
Visual Studio 17.12 is only the start for contributors
The source development guide requires Visual Studio 17.12 or newer on Windows, while Mac contributors use Visual Studio Code with the MAUI extension. Android work adds OpenJDK 17 and Android SDK components. Before opening the main solution, contributors must restore tools and build Microsoft.Maui.BuildTasks.slnf. The main branch pins the latest stable .NET SDK in global.json, regardless of whether Microsoft labels that SDK as long-term support.
Building an app is easier than changing the framework, but target setup still matters. A missing MAUI template requires installing the workload. Android needs SDK licenses and a device or emulator. Apple device and store deployment adds a compatible Mac, the matching Xcode release, and an Apple developer account. The 3-CPU and 8 GB lab allocation tells us nothing about emulator responsiveness, Xcode signing, or paired-Mac reliability because none of those paths ran.
Large changes also need coordination before code. The contributing guide asks authors to discuss substantial features with the core team, complete a contribution license agreement, and obtain two team reviews. Performance changes should include real-application profiling and benchmark evidence where possible. These rules are sensible for a framework beneath shipped apps, though they make drive-by contributions slower than a small library patch.
Release 10.0.101 fixes regressions on every major UI stack
Version 10.0.101 was published September 7, 2026 with 17 commits. Its notes cover an iOS button-style regression introduced in 10.0.80, Android media picker completion, Windows dynamic content assignment, Android root-page back handling, iOS safe-area behavior, and unreadable Android status icons under Material 3. A patch this specific is useful operationally: upgrade testing should revisit navigation, layout, system chrome, and custom control handlers on each target.
GitHub showed 23,321 stars, 3,925 combined issues and pull requests, and a last push on September 10, 2026. Current activity included release-readiness work for .NET 10 and .NET 11 plus fresh Android and iOS reports. The large open count is not a defect total, but active issue traffic and frequent platform fixes show the maintenance burden of wrapping several native UI systems behind one API.
The target list should decide the framework choice
MAUI deserves first consideration when a team already writes C#, needs native Android or iOS, and also wants Windows or Mac Catalyst. Its MIT license, Microsoft ownership, current September release, and large contributor queue make it a safer organizational bet than a young UI toolkit. That does not reduce the need for physical devices, a Mac build path, signing credentials, accessibility checks, and per-platform release testing.
Avalonia is a better opening bid for a C# product centered on Windows, macOS, and Linux desktop, with mobile or WebAssembly also in view. Uno adds web and embedded targets to a C# and XAML approach. Flutter trades .NET reuse for Dart and its own rendering stack. Since our lab produced 0 execution results for MAUI, teams should create a representative screen and ship it through every intended store before committing the wider application.