GO — Healthy across the board

• Last commit today
• 29+ active contributors
• Distributed ownership (top contributor 19% of recent commits)
• MIT licensed
• CI configured
• Tests present
• ⚠ Scorecard: dangerous CI workflow (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

.NET MAUI is a cross-platform UI framework for building native Android, iOS, macOS, and Windows apps from a single C# and XAML codebase. It evolved from Xamarin.Forms and enables developers to target the widest device set with unified business logic, native platform controls, and shared UI through XAML and C# code-behind. Monorepo architecture: src/Core contains platform-agnostic abstractions and XAML parsing; src/Controls defines cross-platform controls (Button, Entry, CollectionView); src/Handlers maps controls to platform-specific implementations (Android handlers in src/Handlers/src/Handlers/Android/, iOS in src/Handlers/src/Handlers/iOS/, etc.). Examples/ and src/Controls/samples/ provide runnable reference apps. Integration tests in tests/ validate multi-platform behavior.

C# developers and teams building mobile and desktop applications who want to maximize code reuse across Android, iOS, macOS, and Windows without maintaining separate platform-specific codebases. Contributors include framework engineers, platform handlers, and control developers working on the open-source foundation.

Production-ready and actively maintained. .NET MAUI shipped as the successor to Xamarin.Forms with .NET 6 (2021) and continues active development (.NET 9 released November 2024, .NET 10 underway). The repo shows extensive CI/CD pipelines (Azure DevOps, GitHub Actions), comprehensive test coverage requirements, and strong governance (CODEOWNERS, branch policies). Regular releases and stable API surface indicate enterprise-grade maturity.

Low risk for consumers; moderate complexity for contributors. The framework has heavy dependencies on platform SDKs (Android API, iOS SDK, Windows WinUI, macOS APIs) meaning breaking changes cascade across five platforms. Monorepo structure with deeply interconnected handler layers means localized changes can have platform-wide effects. Contributor velocity depends on Microsoft and community support, though governance structure and policies suggest sustainable maintenance.

.NET MAUI is actively developing features for .NET 10 (in progress) following .NET 9 release (November 2024). Ongoing work includes CollectionView improvements (see instructions/collectionview-*.instructions.md), layout system enhancements (instructions/layout-system.instructions.md), performance optimizations in hot paths (instructions/performance-hotpaths.instructions.md), and handler pattern standardization. Azure DevOps pipelines run continuous integration with Helix device testing on real hardware.

Clone: git clone https://github.com/dotnet/maui.git && cd maui. Install: Requires .NET 10 SDK preview and platform SDKs (Android SDK, Xcode for iOS/macOS, Visual Studio for Windows). Follow ./.github/DEVELOPMENT.md for detailed setup. Build: dotnet build from repo root. Create sample: dotnet new maui -n TestApp.

Daily commands: Build solution: dotnet build src/Controls/src/Controls.csproj. Run sample app on Android emulator: dotnet maui run -f net9.0-android (requires Android SDK). Run on iOS simulator: dotnet maui run -f net9.0-ios (requires Xcode). Run Windows Desktop: dotnet maui run -f net9.0-windows. Run unit tests: dotnet test src/Controls/test/UnitTests/Controls.UnitTests.csproj.

• .github/DEVELOPMENT.md — Primary development guide explaining how to set up, build, and test the MAUI framework locally—essential reading for all contributors.
• .github/CONTRIBUTING.md — Contribution guidelines and workflow standards that every contributor must follow before submitting PRs.
• .github/instructions/handler-patterns.instructions.md — Architectural documentation on MAUI's handler pattern, the core abstraction for platform-specific implementations across Android, iOS, macOS, and Windows.
• .github/instructions/layout-system.instructions.md — Core layout system documentation covering how MAUI manages cross-platform UI measurement and arrangement logic.
• .config/dotnet-tools.json — Declares required .NET tooling versions (analyzers, format checkers) that all developers must restore to maintain code consistency.
• .editorconfig — IDE formatting and code style rules enforced across the entire codebase to ensure consistency across platforms and tools.
• .github/CODEOWNERS — Defines ownership and review responsibility for critical subsystems, directing PRs to appropriate domain experts.

Add a New Control Handler (Cross-Platform)

1. Read the handler pattern specification to understand the architecture for mapping platform controls to MAUI abstractions. (.github/instructions/handler-patterns.instructions.md)
2. Implement the control interface following the handler pattern for each platform (Android in Java/Kotlin, iOS in Swift/Objective-C, Windows in XAML/C#). (.github/instructions/handler-patterns.instructions.md)
3. Create unit and integration tests following the test framework guidelines. (.github/instructions/integration-tests.instructions.md)
4. Add UI tests for the new control to verify behavior across all target platforms. (.github/instructions/uitests.instructions.md)
5. Update the public API documentation and validate according to public API guidelines. (.github/instructions/public-api.instructions.md)

Add a Platform-Specific Implementation (e.g., Android)

1. Review the Android-specific implementation patterns and conventions. (.github/instructions/android.instructions.md)
2. Implement the handler following the handler pattern to adapt native Android APIs to the MAUI abstraction. (.github/instructions/handler-patterns.instructions.md)
3. Add Android-specific unit tests to your implementation. (.github/instructions/helix-device-tests.instructions.md)
4. Test on actual Android devices or emulators using the Helix device test infrastructure. (.github/instructions/helix-device-tests.instructions.md)

Optimize a Hot Path or Fix a Performance Bottleneck

1. Profile the hot path using the framework's performance profiling tools and identify allocation/CPU hotspots. (.github/instructions/performance-hotpaths.instructions.md)
2. Review threading and async best practices to ensure the optimization doesn't introduce race conditions. (.github/instructions/threading-async.instructions.md)
3. Implement the optimization and add performance-focused unit tests to prevent regression. (.github/instructions/performance-hotpaths.instructions.md)
4. Run integration and device tests to verify the optimization doesn't break platform-specific behavior. (.github/instructions/helix-device-tests.instructions.md)

Submit a Contribution and Pass Code Review

1. Read the contribution guidelines to understand the PR workflow, branch naming, and commit message conventions. (.github/CONTRIBUTING.md)
2. Follow the development setup guide to build and test your changes locally. (.github/DEVELOPMENT.md)
3. Ensure your code follows the .editorconfig style rules and runs all linters. (.editorconfig)
4. Push your branch and create a PR; the AI expert reviewer agent will perform initial code review and suggest improvements. (.github/agents/maui-expert-reviewer.md)

• .NET 8+ / C# — Unified language for cross-platform app development; single shared codebase that compiles to each platform's native runtime.
• XAML — Declarative UI markup language enabling platform-agnostic control definitions that adapt to each platform's native controls via handlers.
• Handler Pattern (Platform Abstraction) — Maps MAUI controls to native APIs (UIView on iOS, View on Android, FrameworkElement on Windows) while maintaining a single control interface.
• Helix Device Testing — Automated device testing across real Android, iOS, and Windows devices to catch platform-specific regressions early.
• GitHub Actions & Azure DevOps Pipelines — Orchestrate multi-platform CI/CD: build validation, automated testing, and release publishing across all target platforms.
• GitHub Copilot + AI Agents — Augment developer productivity with AI-assisted code review, test generation, and PR analysis to maintain quality at scale.

• ---

  • Why: undefined
  • Consequence: undefined

Platform SDK requirements are strict: Android API 21+, iOS 11.0+, macOS 10.13+, Windows 10 Build 19041+. XAML hot reload requires specific project structure (.csproj files must reference correct target frameworks). Handler registration order matters—handlers registered in incorrect platform-specific layers may not resolve. Threading: UI updates must occur on main thread; incorrect use of Task.Run in handlers causes crashes. Some controls have platform-specific limitations (e.g., CollectionView performance cliffs on older Android versions). Build configuration 'net9.0-android' must exactly match project TFM or restore fails.

• Handler Pattern (Control → Platform Mapping) — Core architectural pattern in MAUI: each cross-platform control (Button, Entry) has a handler per platform that maps to native controls; understanding handler registration, lifecycle, and property mapping is essential for any control or platform work
• Platform-Agnostic Abstractions (IButton, IEntry, IView) — MAUI defines C# interfaces for each control's behavior independent of platform, then each handler implements platform-specific logic; knowing the interface hierarchy is critical for control design
• XAML Hot Reload — Unique to MAUI: ability to edit XAML and see changes instantly during debugging without recompiling; requires understanding XAML parser, property binding, and runtime type resolution
• Bindable Properties & Data Binding — MAUI extends .NET property system with BindableProperty for two-way binding and change notification; foundation of reactive UI updates and MVVM patterns used throughout framework
• Target Framework Monikers (net9.0-android, net9.0-ios, etc.) — MAUI uses TFM suffixes to compile platform-specific code; mismatched TFMs cause silent build failures and incorrect handler selection—critical for multi-platform test configuration
• Helix Device Testing Infrastructure — MAUI runs integration tests on real hardware via Azure Pipelines Helix; understanding how tests route to device pools and how to write device-compatible tests is essential for feature validation
• Platform Channel Interop (Java/Kotlin for Android, Objective-C/Swift for iOS) — Some controls require calling native platform APIs; MAUI provides interop layers through P/Invoke (Windows), JNI marshaling (Android), and ObjC#/Swift interop (iOS/macOS); critical for platform-specific features

• dotnet/maui-samples — Official runnable sample applications demonstrating all major .NET MAUI control types and patterns; primary learning resource for MAUI API usage
• CommunityToolkit/Maui — Community-maintained extensions to .NET MAUI with additional controls and helpers; primary companion library ecosystem
• CommunityToolkit/dotnet — MVVM Toolkit and helpers widely used with MAUI apps for separation of concerns; ecosystem standard for MAUI projects
• xamarin/Xamarin.Forms — Direct predecessor to .NET MAUI (now in maintenance mode); reference for historical control implementations and migration patterns
• dotnet/runtime — Underlying .NET runtime; critical for understanding GC behavior, threading, and platform interop used throughout MAUI

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for .github/scripts/Review-PR.ps1

The repo has Review-PR.Tests.ps1 file listed, suggesting test infrastructure exists for PowerShell scripts. Review-PR.ps1 is a critical CI/CD script that validates PRs but appears to lack corresponding test coverage. Adding comprehensive unit tests would improve reliability of the PR review automation and serve as a model for testing other scripts like Find-RegressionRisks.ps1 and Fix-MilestoneDrift.ps1.

• [ ] Review existing Review-PR.Tests.ps1 to understand the test patterns and mocking approach
• [ ] Identify untested code paths in Review-PR.ps1 (e.g., error handling, edge cases in PR validation logic)
• [ ] Add Pester test cases covering: valid PR scenarios, missing required fields, policy violations, and error conditions
• [ ] Ensure tests mock external dependencies (GitHub API calls, file system operations)
• [ ] Document test execution in .github/CONTRIBUTING.md

Create AI agent instruction file for Windows platform-specific issues

The repo has several agent instruction files in .github/agents/ (android, collectionview, handler-patterns, etc.) but is missing a dedicated instruction file for Windows platform development. Given that .NET MAUI supports Windows as a target platform and the repo has Windows-specific test instructions, an AI agent guide for Windows handler implementations and platform-specific bugs would help contributors navigate Windows-specific development patterns.

• [ ] Review existing instruction files (.github/instructions/android.instructions.md, handler-patterns.instructions.md) to understand the format and detail level
• [ ] Create .github/instructions/windows.instructions.md covering: WinUI3 handler patterns, Windows-specific layout considerations, platform capability detection
• [ ] Reference Windows test files and handler code in src/Core/src/Handlers/* to provide concrete examples
• [ ] Create corresponding .github/agents/windows-platform.instructions.md for AI-assisted issue triage
• [ ] Add link to new files in .github/instructions agent documentation

Add integration test instructions for cross-platform layout system validation

The repo has .github/instructions/layout-system.instructions.md and integration-tests.instructions.md as separate files, but no documented guidance for integration tests that validate layout behavior across all platforms (Android, iOS, Windows, macOS). This is critical since layout inconsistencies across platforms are common issues. New contributors need specific guidance on how to add and structure these multi-platform layout validation tests.

• [ ] Review existing .github/instructions/integration-tests.instructions.md and layout-system.instructions.md
• [ ] Create .github/instructions/cross-platform-layout-tests.instructions.md with: test structure for layout validation across all 5 platforms, how to use Helix device tests for platform-specific rendering checks, expected assertion patterns for multi-platform consistency
• [ ] Reference actual test examples from the codebase (find layout-related test files in src/Core/tests/)
• [ ] Document how to identify and report layout regressions in PR validation
• [ ] Add entry to .github/pr-review/pr-gate.md checklist for layout test coverage requirements

• Add missing unit tests for src/Controls/src/Controls/DatePicker.cs and src/Controls/src/Controls/TimePicker.cs across all platforms (currently incomplete coverage per test directory structure); start by reviewing existing patterns in Controls.UnitTests/ and adding platform-specific handler tests.
• Document handler pattern inconsistencies: review src/Handlers/src/Handlers/{Android,iOS,Windows,macOS}/ for handlers missing Microsoft.Maui.Handlers interface implementations, then file small PRs to standardize following instructions/handler-patterns.instructions.md.
• Expand instructions/layout-system.instructions.md with concrete examples of custom layout handler implementation; currently covers theory but lacks step-by-step code walkthrough for new contributors implementing custom layouts across platforms.

The .NET MAUI codebase demonstrates a moderately secure posture with established CI/CD infrastructure and security documentation (.github/SECURITY.md). However, several areas require attention: PowerShell automation scripts lack strict execution policies and input validation, AI/agent configuration files need stricter access controls and regular audits, dependency management automation needs verification, and CI/CD pipeline security should be reinforced with approval gates and secrets management. The large number of automation scripts and AI agent configurations create an expanded attack surface that requires careful governance. No critical vulnerabilities were detected in the visible file structure, but actual code and configuration file contents would need to be reviewed for SQL injection, XSS, hardcoded secrets, and authentication issues.

• Medium · PowerShell Scripts Without Execution Policy Validation — .github/scripts/*.ps1. Multiple PowerShell scripts in .github/scripts directory lack explicit execution policy checks and input validation. Scripts like BuildAndRunHostApp.ps1, Review-PR.ps1, and others could be vulnerable to script injection if parameters are not properly sanitized. Fix: Add Set-StrictMode -Version Latest at the beginning of all scripts, validate all input parameters, use [ValidateScript()] attributes, and implement proper error handling. Consider using script signing.
• Medium · AI Agent Configuration Files Lack Access Controls — .github/agents/, .github/copilot/. Multiple agent configuration files (.github/agents/*.md, .github/copilot/settings.json) define AI instruction sets and system prompts that could potentially be misused if an attacker gains access. These contain detailed system behavior definitions that could be leveraged for prompt injection attacks. Fix: Implement RBAC controls on these configuration files, restrict access to trusted contributors only, regularly audit agent instructions for unintended behaviors, and use branch protection rules to require code review for changes.
• Medium · Dependabot Configuration Lacks Comprehensive Security Rules — .azuredevops/dependabot.yml, .github/dependabot.yml. The dependabot.yml files (.azuredevops/dependabot.yml, .github/dependabot.yml) exist but their content is not visible. Without seeing the configuration, there may be insufficient automation for security patch management, especially for critical dependencies used in a cross-platform UI framework. Fix: Ensure dependabot is configured to: check all package dependencies daily, auto-merge critical/high security updates to a staging branch, maintain update frequencies for dev and production dependencies, and exclude beta versions unless necessary.
• Low · CI/CD Pipeline Configuration Visibility — .azuredevops/, .config/1espt/. Azure DevOps pipeline configurations (.azuredevops/policies/, .config/1espt/) are present but content is not fully visible. CI/CD pipelines in open-source projects require careful security consideration to prevent unauthorized code execution. Fix: Ensure pipeline files: require branch protection for main branch, implement approval gates for production deployments, use separate service principals with minimal permissions for different stages, audit pipeline logs regularly, and implement secrets management using Azure Key Vault.
• Low · Git Configuration Tracking — .gitconfig. Presence of .gitconfig file in repository root is unusual. If this file contains user credentials or custom git settings, it could be a security concern when checked into version control. Fix: Verify that .gitconfig does not contain credentials or sensitive configuration. Add .gitconfig to .gitignore if it's project-specific. Use git config --global instead for user-level settings.
• Low · Third-party Tool Configuration Review — .github/copilot-instructions.md, .github/plugin.json. Multiple configuration files for AI tools, copilot, and agents (.github/copilot-instructions.md, .github/plugin.json) define automated behavior that could have security implications if misconfigured. Fix: Regularly audit AI assistant configurations, implement human review requirements for AI-generated code changes, maintain clear guidelines on what AI tools can access, and document approved use cases.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/dotnet/maui shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live dotnet/maui repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dotnet/maui.

What it runs against: a local clone of dotnet/maui — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in dotnet/maui | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of dotnet/maui. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dotnet/maui.git
#   cd maui
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of dotnet/maui and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dotnet/maui(\\.git)?\\b" \\
  && ok "origin remote is dotnet/maui" \\
  || miss "origin remote is not dotnet/maui (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f ".github/DEVELOPMENT.md" \\
  && ok ".github/DEVELOPMENT.md" \\
  || miss "missing critical file: .github/DEVELOPMENT.md"
test -f ".github/CONTRIBUTING.md" \\
  && ok ".github/CONTRIBUTING.md" \\
  || miss "missing critical file: .github/CONTRIBUTING.md"
test -f ".github/instructions/handler-patterns.instructions.md" \\
  && ok ".github/instructions/handler-patterns.instructions.md" \\
  || miss "missing critical file: .github/instructions/handler-patterns.instructions.md"
test -f ".github/instructions/layout-system.instructions.md" \\
  && ok ".github/instructions/layout-system.instructions.md" \\
  || miss "missing critical file: .github/instructions/layout-system.instructions.md"
test -f ".config/dotnet-tools.json" \\
  && ok ".config/dotnet-tools.json" \\
  || miss "missing critical file: .config/dotnet-tools.json"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/dotnet/maui"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.