A ViewModel test can tell us that saving a valid task adds an item to a collection. But does the Save button execute the right command? Can the user see the validation message? Does navigation bring us back to a usable task list?

These questions sit between our application logic and the native UI.

For this sample, I wanted a small set of tests that interact with a .NET MAUI app in the same order as a user: open a page, enter a title, save it, and check the result.

In this post, we will look at the UI-testing concept, introduce Maestro, write a flow, and see how to run it locally on Android and iOS. The second part will take the same flows into GitHub Actions.

The local Android example uses Windows and an emulator. The iOS example needs a Mac and an iOS Simulator. Neither replaces a final check on real devices.

What Does a UI Test Actually Test?

Unit tests and UI tests answer different questions:

• Unit Tests: Does the ViewModel reject a blank title? / Application logic and test doubles
• UI Tests: Does tapping Save show the validation message and keep the form open? / The installed app on a device or simulator

A unit test can call a command directly. A UI test must find the button, tap it, and observe the screen afterwards. This exercises more of the application: native controls, bindings, input, and navigation.

That broader boundary is useful, but it costs more. UI tests need a running app and device, take longer, and can be affected by keyboard behavior, animations, or ambiguous selectors.

I would not replace unit tests with UI tests. Keep detailed business-rule checks close to the code, then use a focused set of UI tests for important user journeys.

The basic pattern stays familiar: arrange a known state, perform an action, and assert the result.

Introducing Maestro

Maestro describes UI interactions in YAML files called flows. A flow can launch an app, find an element in the native UI hierarchy, tap it, enter text, and check what becomes visible.

For .NET MAUI, that is an interesting boundary. Maestro does not know our ViewModel types. It interacts with the native controls that MAUI creates.

There is no Maestro NuGet package in this sample and no production-only test hook. The installed app remains the app we want to test.

This is not a pixel-diff test suite either. We check behavior through elements, identifiers, and accessibility descriptions. Screenshots can help us understand failures, but taking a screenshot does not automatically compare the UI against a visual baseline.

The Sample: MAUI Tasks

The app is deliberately small. It starts with three tasks:

• Learn .NET MAUI
• Explore Maestro
• Write UI tests

We can add a task, mark it as completed, and delete it. Empty or whitespace-only titles are rejected with an inline message. Valid titles are trimmed before saving.

There is no backend, database, or authentication. An in-memory task service keeps the example focused on UI interaction rather than infrastructure.

The repository contains five flows:

• Smoke: Check the seeded task list and Add button
• Add: Save a new task and find it in the list
• Validate: Reject blank input, then recover by saving a valid title
• Complete: Complete a specific task and return it to “To do”
• Delete: Remove a specific task without removing the other tasks

That is a useful starting point, not a claim of complete application coverage.

Keeping Unit Tests Separate

The solution separates the .NET MAUI app from a platform-independent Core library. Models, ViewModels, the task service, and a navigation contract live in Core; views and Shell integration remain in the app.

Core targets net10.0 and does not reference .NET MAUI. We can run its unit tests directly with the matching .NET SDK:

dotnet test `
    tests\MaestroMauiDemo.UnitTests\MaestroMauiDemo.UnitTests.csproj

This project uses xUnit with VSTest, so the positional project path is intentional. No .NET MAUI workload or emulator is needed for this command.

The Maestro workspace is different. It is a directory of YAML files and runner scripts, not another .NET test project:

tests/
  MaestroMauiDemo.UITests/
    config.yaml
    flows/
      smoke.yaml
      add-task.yaml
      validate-task.yaml
      complete-task.yaml
      delete-task.yaml
    scripts/
      run-android.ps1
      run-ios.sh

Start with a Known State

To write a first flow, create a YAML file such as open-task-list.yaml inside the workspace’s flows directory. For a temporary exercise, remove it afterwards if you want to keep the repository’s original five-flow suite.

Here is its complete content:

appId: ${APP_ID}
name: Open the task list
---
- launchApp:
    clearState: true
- assertVisible: "MAUI Tasks"
- assertVisible:
    id: "TaskList"

The header identifies the app and names the flow. The --- separator starts the command list. Our workspace discovers files inside flows, so a new file there is included in suite runs.

APP_ID is supplied when we invoke Maestro. For this app, its value is de.tsjdevapps.maestromauidemo. Keeping it outside the flow avoids repeating the package identifier in every file.

launchApp starts the app with its data cleared. In this sample, the process restart also recreates the in-memory service and the three seeded tasks. Navigating between pages does not reset that service.

For an app backed by a server, this would not reset server-side data. We would need an explicit test-data strategy.

Finally, assertVisible checks the screen rather than assuming that launching the process means the app is usable. A launch with clearState is destructive to the selected app’s data, so use it only against the intended test app.

Give Controls Stable Selectors

Visible text can identify a screen, but it is not always the best way to identify a control. Labels change, and repeated list rows often contain identical buttons.

The sample assigns explicit .NET MAUI AutomationId values to important controls, including TaskList, TaskTitleEntry, and SaveTaskButton.

A unique button can then be selected like this:

- tapOn:
    id: "SaveTaskButton"

Rows require more detail. Every row has a Delete button. The relevant selector properties in its XAML are:

<Button
    AutomationId="DeleteTaskButton"
    Text="Delete"
    SemanticProperties.Description="{Binding Title, 
        StringFormat='Delete task: {0}'}" />

This excerpt omits the actual command binding and styling to focus on selection.

On Android, the native hierarchy exposes the description, allowing the flow to select one specific task:

- tapOn:
    id: "DeleteTaskButton"
    text: "Delete task: Write UI tests"

The completion checkbox uses the same idea with descriptions such as Completion for Explore Maestro.

Inspect the native hierarchy when a selector does not behave as expected. A XAML property alone is not proof of how it appears on every platform.

Write a Flow That Checks the Result

Here is the complete add-task flow from the repository:

appId: ${APP_ID}
name: Add a task and return to the list
---
- launchApp:
    clearState: true
- assertVisible:
    id: "TaskList"
- assertNotVisible: "Write Maestro UI tests"
- tapOn:
    id: "AddTaskButton"
- assertVisible: "A new task"
- tapOn:
    id: "TaskTitleEntry"
- inputText: "Write Maestro UI tests"
- hideKeyboard
- tapOn:
    id: "SaveTaskButton"
- assertVisible:
    id: "TaskList"
- assertNotVisible:
    id: "TaskTitleEntry"
- scrollUntilVisible:
    element:
      id: "TaskTitleLabel"
      text: "Write Maestro UI tests"
- assertVisible:
    id: "TaskTitleLabel"
    text: "Write Maestro UI tests"

We first verify the starting screen and make sure the new task is absent. Then we open the form, focus the entry, type the title, and hide the keyboard before saving.

The important part comes after the tap. We check that the list returns, the entry is no longer visible, and the new task appears.

scrollUntilVisible avoids depending on a particular screen height. The flow uses state-based checks instead of arbitrary fixed sleeps.

The repository’s other flows start independently too. None needs another flow to create its data first. That makes a single-flow run useful during development.

Do Not Forget the Rejection Path

A successful save does not prove that an invalid save behaves correctly.

After opening the add page, the validation flow contains:

- tapOn:
    id: "SaveTaskButton"
- assertVisible:
    id: "ValidationMessageLabel"
    text: 'Enter a task title\.'
- assertVisible:
    id: "TaskTitleEntry"
- assertNotVisible:
    id: "TaskList"

This checks the message and the navigation result: the form stays open.

The full flow repeats the check with three spaces, then replaces them with a valid title and verifies the saved task. We test both rejection and recovery, not just the presence of red text.

Prepare the Local Android Environment

For the Windows runner in this repository, we need:

• .NET SDK 10.0.403
• .NET MAUI Android workload and compatible Android SDK
• Android Platform-Tools and Emulator
• An existing Android AVD
• Java 17+; use your vendor’s October 2026 security release or later, and point JAVA_HOME to that JDK
• Native Maestro CLI
• PowerShell 7

Follow the official Maestro CLI installation guide. On Windows, download the release ZIP, extract it to a stable directory, and add its bin directory to your user PATH. This uses the native CLI, without WSL.

Set JAVA_HOME to the JDK root containing bin\java.exe, not to bin itself. Configure ANDROID_HOME to point to the Android SDK. Open a new terminal after changing environment variables.

Check the tools before running a test:

dotnet --version
& "$env:JAVA_HOME\bin\java.exe" --version
maestro --version
& "$env:ANDROID_HOME\platform-tools\adb.exe" devices -l
& "$env:ANDROID_HOME\emulator\emulator.exe" -list-avds

If no AVD exists, create one through Android Device Manager or Android Studio. The helper starts existing AVDs; it does not create them or install missing tools.

Run the Tests Locally on Android

From the repository root:

.\tests\MaestroMauiDemo.UITests\scripts\run-android.ps1

The helper reuses an eligible running emulator. If none is available, it selects the only existing AVD automatically, or offers a numbered choice when several exist.

For a repeatable command:

.\tests\MaestroMauiDemo.UITests\scripts\run-android.ps1 `
    -AvdName 'pixel_5_-_api_33'

Replace the example with a name from your own AVD list. The screenshots and local verification in this article use API 33.

The script waits for boot, evaluates the project’s Android target and application ID, builds a fresh signed APK, installs it, and runs all five flows.

To work on just one flow:

.\tests\MaestroMauiDemo.UITests\scripts\run-android.ps1 
    -Flow "add-task.yaml"

The -Flow value is a filename inside the existing flow directory.

For YAML-only changes, we can avoid rebuilding:

.\tests\MaestroMauiDemo.UITests\scripts\run-android.ps1 `
    -DeviceId "emulator-5554" -Flow "add-task.yaml" -SkipBuild

-SkipBuild skips both build and installation. The selected emulator must already contain the app. Do not use this option to claim that freshly changed app code has been tested.

The helper shuts down an emulator only when it started that emulator itself. A pre-existing emulator stays running. Boot, installation, and test failures return nonzero rather than becoming a successful run after cleanup.

See What the Android Helper Runs

Once the app is installed and the emulator is booted, we can invoke Maestro directly:

maestro --device=emulator-5554 --platform=android test `
    --env "APP_ID=de.tsjdevapps.maestromauidemo" `
    tests\MaestroMauiDemo.UITests\flows\add-task.yaml

Replace the serial with the intended test emulator. This command runs the flow only: it does not build, install, or manage emulator shutdown.

For the whole workspace:

maestro --device=emulator-5554 --platform=android test `
    --env "APP_ID=de.tsjdevapps.maestromauidemo" `
    tests\MaestroMauiDemo.UITests

The workspace’s config.yaml limits discovery to the YAML flow directory:

flows:
  - flows/*

Maestro reports the commands and flow outcomes in the terminal. When a flow fails, check its first failed assertion and diagnostic output before changing the app or adding delays.

The five Android flows have passed locally, both as a suite and individually in a different order.

A Few Practical Pitfalls

An ADB-installed MAUI Debug APK needs its managed assemblies included. Visual Studio Fast Deployment can otherwise leave the APK depending on separately deployed files.

The helper builds with:

AndroidPackageFormats=apk
EmbedAssembliesIntoApk=true

An installation that succeeds is not enough if the app then aborts at startup.

For Java issues, check the actual output of java -version, not just the JDK folder name. The local Microsoft JDK reports 17.0.21.0.2, which produces an Android-tooling XA0033 parsing warning in this environment. Builds and flows passed, but the warning is not presented as resolved.

For element-selection failures, inspect the native hierarchy, the foreground screen, and the starting state. Stable IDs and row-specific descriptions are more useful than relying on “the second Delete button”.

The UI-test guide contains the full setup and troubleshooting details.

Run the Same Flows Locally on iOS

The YAML files do not need a separate iOS copy. The environment around them does change.

For an iOS Simulator run, we need:

• macOS and Xcode
• A compatible .NET SDK and .NET MAUI iOS workload
• An installed iOS Simulator runtime and an existing simulator
• Java 17+; use your vendor’s October 2026 security release or later, and point JAVA_HOME to that JDK
• Native Maestro CLI

The repository’s hosted example uses Xcode 27.1, workload set 10.0.403, and Maestro 2.12.1. Maestro 2.12.0 added support for starting iOS simulators with Xcode 27; that support is included in 2.12.1. Keep Xcode and the installed .NET iOS workload compatible; changing one without checking the other can prevent the app from building.

An iOS Simulator runs only on macOS. A Windows or Linux machine cannot run it locally; a Windows developer needs access to a Mac for this part. The simulator does not require an Apple signing certificate or provisioning profile.

On the Mac, check the available simulators and run the Bash helper from the repository root:

xcrun simctl list devices available
bash tests/MaestroMauiDemo.UITests/scripts/run-ios.sh

The helper selects an available simulator, starts it when needed, builds a fresh simulator .app, checks its bundle identifier, installs it, and runs the same five flows. If several simulators are available, it asks us which one to use.

We can also select a simulator by its UDID and run one flow:

bash tests/MaestroMauiDemo.UITests/scripts/run-ios.sh \
  --device-id "YOUR-SIMULATOR-UDID" --flow add-task.yaml

Replace the placeholder with a UDID from simctl. Like the Android helper, --skip-build skips both the build and installation, so use it only when the intended app is already installed. The helper shuts down only a simulator it started itself.

If the simulator is already running and the app is installed, we can invoke the flow directly:

maestro --device="YOUR-SIMULATOR-UDID" --platform=ios test \
  --env "APP_ID=de.tsjdevapps.maestromauidemo" \
  tests/MaestroMauiDemo.UITests/flows/add-task.yaml

This direct command does not build or install the app. It also does not manage simulator startup or shutdown.

Sharing a flow is useful, but it does not guarantee identical native behavior. Inspect the iOS accessibility hierarchy and verify selectors, scrolling, and keyboard dismissal on the simulator.

Do Not Skip Real-Device Testing

An emulator or simulator is a fast, repeatable place to catch many problems. It is not the final answer about how the app behaves in someone’s hand.

Before a release, run the app on a physical Android device and a physical iPhone as well. Check the important journeys, including navigation, text input, scrolling, and accessibility. Depending on the app, also check hardware features, permissions, notifications, performance, and real network conditions. Expand the device and OS coverage to match the people using the app.

An iOS simulator .app is not a device build. Running on an iPhone still requires macOS and the appropriate Apple signing and provisioning setup. Passing a simulator flow is useful evidence, not proof that the physical-device experience is ready.

Conclusion

A useful first UI test does not need to cover every screen. Start with one important journey and verify its outcome through the real app.

For this sample, that means starting from known data, finding controls through stable selectors, saving a task, and checking the resulting list. Add a rejection path next, and keep detailed business rules in unit tests. Run the flows on both platforms where their tooling is available, then check the app on real devices.

The sample and local runners are available on GitHub.

Getting Started with Maestro UI Tests for .NET MAUI was originally published in Medialesson on Medium, where people are continuing the conversation by highlighting and responding to this story.

I spend a lot of time in an editor. Moving to a presentation tool, dragging text boxes around, and pasting screenshots of code often feels like switching to a completely different workflow.

Slidev takes another approach: write the presentation in Markdown, keep it in Git, and render it as an interactive web deck. When a slide needs more than Markdown, you can use Vue components, CSS, and layouts.

To explore it, I created English and German decks about my .NET MAUI + Aspire TaskBoard. They share a reusable tsjdevapps theme, including light/dark switching, and demonstrate both ordinary C# highlighting and Shiki Magic Move.

The complete example is available in maui-aspire-taskboard-slides.

Why this is interesting for developers

With Markdown as the source, a talk becomes something you can review:

• See what changed in a diff instead of comparing presentation files.
• Keep the explanation near the implementation it describes.
• Reuse a theme without copying yesterday’s slide deck.
• Use real code fences rather than code screenshots.
• Ask an AI assistant for an outline or a translation, then review its edits.

There is a trade-off: building a custom visual identity still involves CSS and, occasionally, Vue. Markdown removes much of the content-editing friction; it does not remove the need to think about layout or rehearse.

Step 1: Run the example

Install Node.js 22.12 or newer; Node 24 LTS is a good choice. Then run:

git clone https://github.com/tsjdev-apps/maui-aspire-taskboard-slides.git
cd maui-aspire-taskboard-slides
npm ci
npm run dev

Open http://localhost:3030/en/ for English or http://localhost:3031/de/ for German. The command starts both development servers. Edit the English deck ../decks/en.md or the German deck ../decks/de.md and let Slidev reload it.

Use the top-right controls to change the language or appearance. Matching slide order and animation steps let the language switch retain your position. Keep both servers running when switching languages during development.

You do not need the .NET SDK, MAUI workloads, Docker, or an Azure account to run the slides. Those are separate concerns if you want to run the native TaskBoard application for the suggested live demo.

Starting an unrelated Slidev project from scratch is also straightforward: npm init slidev@latest. Follow its prompts, then edit the generated Markdown.

Step 2: Understand the Markdown

A minimal new deck in this repository can look like this:

---
theme: ../themes/tsjdevapps
title: My next developer talk
layout: cover
themeConfig:
  language: en
---

# Slides as code

One idea, one slide.

---

# The next idea

The opening YAML is called headmatter. It configures the deck and first slide. ---separates subsequent slides; per-slide frontmatter selects layouts.

Create this as decks/my-talk.md and start it with npx slidev decks/my-talk.md --port 3032. This is a standalone deck: its theme works even without the TaskBoard components or a second language.

HTML comments can hold speaker notes. Named slots such as ::right:: let the theme place content in a second column.

Step 3: Tell a story with code

TaskBoard is a .NET 10 sample with a native MAUI client, an ASP.NET Core Minimal API, SQLite persistence, and Aspire development orchestration. It deliberately avoids adding cloud services or Docker just to demonstrate orchestration.

For a talk, the AppHost makes a good story: begin with the host, register the API, and then connect the native client. Instead of showing three screenshots, use Shiki Magic Move.

The important syntax is four outer backticks around ordinary three-backtick code fences:

````md magic-move
```csharp
var app = builder.Build();
app.Run();
```
```csharp
var app = builder.Build();
app.MapTaskEndpoints();
app.Run();
```
````

This is a teaching example, not the full API startup. When you advance, matching tokens move into their new positions and the new line appears. The actual AppHost slide demonstrates three stages.

Ordinary line highlighting is useful too:

```csharp {1|2|*}
options.Retry.MaxRetryAttempts = 2;
options.Retry.DisableFor(HttpMethod.Post, HttpMethod.Put,
    HttpMethod.Delete, HttpMethod.Patch);
```

That example highlights the GET retry limit first, then the start of the write-method exclusions, then the complete block. The sample uses at most two retries for transient GET failures and no automatic retries for those write methods. These are application decisions, not universal recommendations.

The decks link project excerpts to source revision 9f678cd and label omissions or teaching steps explicitly. That matters when your slides explain a real project rather than an imaginary API.

Step 4: Make the design reusable

I wanted the decks to feel like my website, not a generic template: warm off-white surfaces, teal accents, rounded cards, Roboto, and JetBrains Mono.

The theme lives under themes/tsjdevapps/:

components/   Brand frame and appearance/language controls
layouts/      cover, default, two-cols, code
setup/        Light/dark Shiki themes
styles/       Brand tokens, typography, cards, local font imports

Content belongs in the decks, not in the theme. The small TaskBoard illustration, for example, is a deck component and is clearly marked as an illustration rather than an app screenshot.

For another deck in this repository, reuse theme: ../themes/tsjdevapps. For another repository, run npm run theme:pack, install the resulting .tgz in that Slidev project, and use theme:tsjdevapps. You do not have to publish it to npm.

Light mode uses deep teal text on warm paper. Dark mode switches to midnight blue surfaces and mint accents. Both normal code blocks and Magic Move use Shiki’s matching light/dark themes. Fonts are bundled locally rather than loaded from a font CDN while presenting.

Step 5: Use AI as an editor, not as a source of truth

Markdown is convenient input for an AI-assisted workflow. I would start with the source files and a short outline, then ask for a draft:

Create a Slidev talk from the provided TaskBoard source revision.
Use the tsjdevapps theme and matching English/German slide IDs.
Keep one idea per slide and link every project snippet to its source.
Include a three-stage AppHost magic-move animation and speaker notes.
Do not invent APIs, measurements, screenshots, or deployment features.
Mark all simplifications.

Then review the result like code. Check the SDK methods against the source, review both languages, and inspect the actual rendered slides. A successful build does not prove that text fits the canvas or that a technical claim is true.

Share only code you are permitted to share. Remove secrets, personal data, and private URLs before giving material to any AI service.

Step 6: Build, share, and export

Build both interactive decks and preview them locally:

npm run build
npm run preview

Open http://localhost:4173. Upload the whole `dist/` directory to a static host. For a repository subpath, build with:

npm run build -- --base /maui-aspire-taskboard-slides/

The host needs separate SPA fallbacks for en/* and de/*, pointing to each language’s index.html. The included preview server handles those routes and the configured base path. Public builds omit speaker notes.

For a handout, install Chromium once and export a PDF:

npx playwright install chromium
npm run export:en
npm run export:de:dark

Files go to exports/. Use npm run export:en --with-clicks to capture intermediate animation steps as separate pages. A PDF cannot preserve token transitions or switches; share the web build when interactivity matters.

For checks, run npm run typecheck, then npm test after building. The browser tests check both decks, appearance/language switching, source-code animation, and content boundaries.

The takeaway

Slidev is appealing because it lets a presentation join the rest of a developer’s workflow. Markdown handles the story. Git handles the history. Shiki handles the code. A reusable theme handles the visual identity.

And AI can help with the first draft, without taking over the responsibility for the final talk.

Less dragging. More storytelling.

Links

• Slidev getting started
• Shiki Magic Move in Slidev
• Writing a Slidev theme
• TaskBoard source
• Slides and reusable theme
• My developer blog
• Medium / @tsjdevapps

Your Next Presentation Could Be a Git Repository was originally published in Medialesson on Medium, where people are continuing the conversation by highlighting and responding to this story.

You click Refresh in a native app, and the task list takes several seconds to update. The API is running, but that alone does not explain the delay. Was the request sent to the expected endpoint? Did the client retry? Was the server slow?

Aspire brings the client and backend into a shared development workflow, with resource management, endpoint configuration, and a dashboard for telemetry. A small task board gives us enough real behavior to explore that workflow: loading data, saving changes, handling failures, and running a native client alongside an ASP.NET Core API.

In this post, I will walk through TaskBoard, a .NET 10 sample built with .NET MAUI, MVVM, a Minimal API, and SQLite. We will look at the integration points, the mobile setup, and the tradeoffs of adding Aspire to an existing application.

What Is .NET Aspire?

Aspire is an open-source, opinionated stack for building observable, cloud-ready distributed applications with .NET.

It brings an application’s related projects and resources — such as APIs, workers, and databases — into one development model, so they can be started and inspected together instead of configured as unrelated processes.

Three pieces are central to this workflow:

• AppHost describes the projects, resources, and relationships in the application. Running it starts the development environment and supplies configuration such as service endpoints.
• Service Defaults provide shared infrastructure such as service discovery, health checks, and OpenTelemetry configuration. Each project opts in to the defaults it needs.
• Aspire Dashboard gives you one place to inspect resource state, logs, traces, and metrics exported by the application.

In TaskBoard, AppHost coordinates the ASP.NET Core API and the native MAUI app. Service discovery gives the client the API address, and telemetry from both sides can be inspected together.

SQLite stays local to the API; it is not a separately orchestrated resource in this sample. Aspire is a development and diagnostics layer here, not a replacement for MAUI or ASP.NET Core, nor the production host for the app.

Introducing TaskBoard

The application has three screens:

• Tasks: load, create, edit, complete, and delete tasks.
• Editor: validate a title and optional description, then save through the API.
• Diagnostics: send normal, delayed, failing, and timed-out requests.

The UI uses native MAUI controls, Shell navigation, light/dark styling, and English/German resources. The API persists tasks in SQLite, so this sample does not require a database container or Docker. Two example tasks are inserted when a Development database is first created; deleting them does not bring them back on every restart.

The diagnostics screen makes the sample useful beyond CRUD. It gives us repeatable requests to inspect while learning how endpoint discovery, retries, and telemetry interact.

What You Need Before You Start

The sample pins its toolchain and package versions:

|          Component         |      Sample Version      |
|:--------------------------:|:------------------------:|
| .NET SDK                   | 10.0.401                 |
| Aspire AppHost SDK         | 13.6.1                   |
| Aspire MAUI Hosting        | 13.6.1-preview.1.26506.6 |
| ASoure Dev Tunnels Hosting | 13.6.1                   |
| MAUI Controls/Core         | 10.0.110                 |
| CommunityToolkit.MVVM      | 8.4.2                    |
| EF Core SQLite             | 10.0.12                  |

The SDK is selected in global.json, and ordinary NuGet versions live in Directory.Packages.props. The AppHost SDK version belongs in its project declaration.

From the repository root, install the MAUI workloads for the targets you want to build. On Windows, use the .NET MAUI workload in Visual Studio Installer or run dotnet workload restore TaskBoard.slnx. Trust the local HTTPS development certificate as well:

dotnet dev-certs https --trust

Windows can build the Windows and Android targets in this repository. Android also needs the Android SDK, a JDK, and a running emulator or device. iOS and Mac Catalyst require macOS, compatible Xcode, and the corresponding Apple workloads; start a simulator before deploying to it.

For mobile Aspire resources, install the Dev Tunnels CLI, sign in with devtunnel user login, and have internet access. The API and telemetry tunnels are needed when you start a mobile resource; starting the Windows desktop app does not require Dev Tunnels. A separate Aspire CLI installation is not required for this project-based AppHost; the commands below use dotnet run.

The official Aspire MAUI integration is currently a preview, with incomplete Visual Studio integration. The examples here use the pinned package combination above. Check compatibility before upgrading it.

Project Shape

The repository separates application behavior from platform and development infrastructure:

TaskBoard.slnx
Directory.Packages.props
src/
  TaskBoard.Contracts/
  TaskBoard.Api/
  TaskBoard.ClientCore/
  TaskBoard.Maui/
  TaskBoard.ServiceDefaults/
  TaskBoard.MauiServiceDefaults/
  TaskBoard.AppHost/
tests/
  TaskBoard.ClientCore.Tests/
  TaskBoard.Api.Tests/
  TaskBoard.AppHost.Tests/

|       Project       |                        Responsibility                 |
|:-------------------:|:-----------------------------------------------------:|
| Contracts           | Task DTOs and shared validation limits                |
| Api                 | REST endpoints, EF Core, and SQLite                   |
| ClientCore          | HTTP client, ViewModels, resilience, and localization |
| Maui                | XAML pages, navigation, and native connectivity       |
| ServiceDefaults     | Backend health checks, discovery, and telemetry       |
| MauiServiceDefaults | Native discovery and telemetry initialization         |
| AppHost             | Development resource registrations and startup        |

The request path stays simple: a MAUI ViewModel calls the typed HTTP client, the client calls taskapi, and the API reads or writes SQLite. Client and backend telemetry can be exported to the Aspire dashboard.

Contracts and ClientCore have no Aspire hosting dependency. That keeps the API contract and application behavior usable when the app starts independently.

Registering the API and Native App

The AppHost describes how the development resources fit together. Its project references the API and the hosting integrations:

<Project Sdk="Aspire.AppHost.Sdk/13.6.1">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <AspireUseCliBundle>true</AspireUseCliBundle>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Aspire.Hosting.Maui" />
    <PackageReference Include="Aspire.Hosting.DevTunnels" />
    <ProjectReference Include="../TaskBoard.Api/TaskBoard.Api.csproj" />
  </ItemGroup>
</Project>

This excerpt omits the sample’s user-secrets identifier and test assembly visibility. Package versions are supplied centrally.

The desktop portion of AppHost.cs looks like this, with the final Run call included for a minimal desktop configuration:

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.TaskBoard_Api>("taskapi")
    .WithHttpHealthCheck("/health");

var maui = builder.AddMauiProject(
    "taskboard", "../TaskBoard.Maui/TaskBoard.Maui.csproj");

if (OperatingSystem.IsWindows())
{
    maui.AddWindowsDevice().WithReference(api);
}

if (OperatingSystem.IsMacOS())
{
    maui.AddMacCatalystDevice().WithReference(api);
}

builder.Build().Run();

taskapi is the logical service name shared by the host and client. WithReference(api) supplies the API’s endpoint configuration to the native resource.

The MAUI project is registered through its .csproj path. The integration documentation explicitly advises against an AppHost-to-MAUI ProjectReference because their target frameworks are incompatible.

The backend references TaskBoard.ServiceDefaults and calls builder.AddServiceDefaults(). It also registers Problem Details, its DbContext, and a database health check. After building the application, it installs exception handling, initializes the database, maps task endpoints, and calls app.MapDefaultEndpoints(). The Development /health endpoint includes database readiness; /alive provides a liveness check.

Connecting MAUI to the Discovered API

A standalone client can start with a conventional base address:

builder.Services.AddHttpClient<ITaskApiClient, TaskApiClient>(client =>
    client.BaseAddress = new Uri("https://your-api.example/"));

TaskBoard loads its embedded settings and environment configuration, then selects the appropriate address. This excerpt comes from MauiProgram.BuildApplication():

builder.AddServiceDefaults();

var hasDiscoveredApi = builder.Configuration
    .GetSection("services:taskapi")
    .GetChildren()
    .Any();

var baseAddress = hasDiscoveredApi
    ? new Uri("https+http://taskapi")
    : GetStandaloneAddress(builder.Configuration["TaskBoard:ApiBaseUrl"]);

builder.Services.AddTaskBoardClient(baseAddress);

Here, AddServiceDefaults() is the extension from MauiServiceDefaults. It registers discovery for outgoing HTTP clients and configures native telemetry. GetStandaloneAddress() is the sample’s helper that validates an absolute HTTP/HTTPS URL and normalizes its trailing slash.

When Aspire supplies service endpoints, the client uses the logical https+http://taskapi address. Discovery resolves it to the configured endpoint, preferring HTTPS. Outside that launch context, the embedded TaskBoard:ApiBaseUrl provides the conventional URL.

The typed client continues to use relative routes such as api/tasks. The ViewModels depend on ITaskApiClient in both modes, so switching startup configuration does not change the task operations.

Initializing Native Telemetry

Backend defaults register ASP.NET Core and HTTP instrumentation, runtime metrics, and OpenTelemetry logging. Native defaults register HTTP instrumentation, runtime metrics, and logging as well.

MAUI startup needs its own provider initialization. The sample’s OpenTelemetryInitializer implements IMauiInitializeService:

public void Initialize(IServiceProvider services)
{
    _ = services.GetService<MeterProvider>();
    _ = services.GetService<TracerProvider>();
    _ = services.GetService<LoggerProvider>();
}

Both defaults enable OTLP export when OTEL_EXPORTER_OTLP_ENDPOINT is configured. Launching through Aspire supplies the collector configuration; a standalone launch can supply a collector separately.

HTTP instrumentation propagates trace context between the client and API. In a dashboard session, refresh the board and look for the outgoing client request and corresponding server request under the same trace. That gives you a useful place to investigate server processing time and failed attempts.

The diagnostics screen displays the duration of the whole client action, including retry delays. Use that value alongside the trace spans when investigating a slow operation.

Making Retries and Timeouts Explicit

The task client owns one standard resilience handler. Native defaults register discovery globally and leave the task-specific resilience policy to ClientCore. The .NET HTTP resilience guidance recommends using a single resilience handler rather than stacking handlers.

These are the relevant calls from ClientServiceCollectionExtensions.AddTaskBoardClient():

var http = services.AddHttpClient<ITaskApiClient, TaskApiClient>(client =>
{
    client.BaseAddress = baseAddress;
});

http.AddStandardResilienceHandler(options =>
{
    options.TotalRequestTimeout.Timeout = TimeSpan.FromSeconds(12);
    options.AttemptTimeout.Timeout = TimeSpan.FromSeconds(3);
    options.Retry.MaxRetryAttempts = 2;
    options.Retry.Delay = TimeSpan.FromMilliseconds(500);
    options.Retry.BackoffType = DelayBackoffType.Constant;
    options.Retry.UseJitter = false;
    options.Retry.DisableFor(
        HttpMethod.Post, HttpMethod.Put, 
        HttpMethod.Delete, HttpMethod.Patch);
});

http.ConfigureHttpClient(client =>
    client.Timeout = TimeSpan.FromSeconds(12));

GET requests can make up to three attempts for transient failures. Writes receive no automatic retries. The standard circuit breaker and rate limiter remain enabled.

The final ConfigureHttpClient() call is intentional. The standard handler implementation disables HttpClient’s own timeout when it registers the pipeline. TaskBoard reapplies a 12-second limit afterward to cover response-body buffering outside the handler’s timeout scope. A regression test sends headers followed by a body that never completes and verifies that the actual configured client stops waiting.

A failed or canceled write can already have been committed by the server. Refresh the board before manually repeating a write whose outcome is uncertain. This sample has no offline write queue or server-side idempotency keys.

Running the Sample on Windows

From a checkout of the TaskBoard repository, run these commands in its root directory:

dotnet --version
dotnet restore TaskBoard.slnx
dotnet dev-certs https --trust
dotnet run --project src/TaskBoard.AppHost

The AppHost prints its dashboard URL and starts the API. Open the dashboard and use Start on taskboard-windows to build and launch the native application. The native resource starts on demand.

The defaults use Development launch profiles, so taskboard-android is registered as well. Its tunnels stay stopped until a mobile resource is started. If you change resource registrations, rebuild and restart AppHost so the dashboard receives the new model.

The Windows client is configured as an unpackaged application for this local sample. Release packaging and signing belong to a separate distribution workflow.

Adding Android and Mobile Dev Tunnels

The mobile configuration uses one tunnel for the API and another for OTLP telemetry. TaskBoard marks both with explicit start behavior, then starts them before mobile deployment. Desktop resources connect directly to host endpoints.

The following additional block belongs before builder.Build().Run() in the desktop AppHost example. It uses the sample’s MobileTunnelStarter helper from the AppHost project, plus the TaskBoard.AppHost, Aspire.Hosting.DevTunnels, Microsoft.Extensions.Configuration, and Microsoft.Extensions.Hosting namespaces:

var prepareMobileTunnels = builder.Configuration
    .GetValue<bool>("TaskBoard:EnableMobileTargets");

if (prepareMobileTunnels && !builder.Environment.IsDevelopment())
{
    throw new InvalidOperationException(
        "Mobile Dev Tunnels are only supported in Development.");
}

using var tunnelStarter = new MobileTunnelStarter();
if (builder.Environment.IsDevelopment())
{
    var tunnel = builder.AddDevTunnel("taskapi-tunnel")
        .WithAnonymousAccess()
        .WithReference(api.GetEndpoint("https"));

    var emulatorId = builder.Configuration["TaskBoard:AndroidEmulatorId"];
    var android = maui.AddAndroidEmulator(
            "taskboard-android",
            string.IsNullOrWhiteSpace(emulatorId) ? null : emulatorId)
        .WithOtlpDevTunnel()
        .WithReference(api, tunnel);

    var mobileTunnels = builder.Resources
        .OfType<DevTunnelResource>().ToArray();

    if (!prepareMobileTunnels)
    {
        foreach (var mobileTunnel in mobileTunnels)
        {
            builder.CreateResourceBuilder(mobileTunnel)
                .WithExplicitStart();
        }
    }

    android.OnBeforeResourceStarted((_, e, ct) =>
        tunnelStarter.StartAsync(mobileTunnels, e.Services, ct));
}

The helper serializes mobile starts, reuses running tunnels, executes their Start commands, and waits for health/readiness. A failed command or unavailable tunnel fails the mobile start instead of leaving deployment waiting indefinitely. The complete AppHost also registers an iOS simulator target on macOS with the same API reference and OTLP tunnel.

Create and start an Android Virtual Device with the Android Device Manager. With a single running emulator, use Start on taskboard-android in the dashboard. The resource is configured to build, install, and launch the app on that emulator.

The sample API has no authentication, and its API tunnel permits anonymous access. Starting a mobile resource exposes CRUD through that tunnel. Use disposable example data and stop the AppHost afterward.

Signing in authenticates the tunnel host; it does not authenticate callers of this demonstration API.

When Aspire Is Worth Adding

For a client and API developed together, Aspire gives the team a repeatable starting point and a shared place to investigate requests. The diagnostics page makes that benefit easy to explore with predictable failures and delays.

The cost is additional configuration, a preview native integration, and account/network dependencies for mobile tunnels. A small app calling an already deployed API may have less to gain from coordinating local resources.

This repository uses Aspire for development orchestration. Publishing the API, signing native packages, and choosing production endpoints remain separate work. SQLite schema creation and the unauthenticated demo API also need additional design before supporting durable production data.

To add this pattern to your own application, begin with AppHost and the two defaults projects, then update client configuration and verify one desktop target. Keep the existing REST contract and MVVM behavior. Add mobile tunnels once the desktop path is working, and use a few controlled failure requests to check the resulting workflow.

You can explore the implementation in the TaskBoard sample repository.

Conclusion

Aspire gives a MAUI client and its API a shared development workflow for startup, endpoint discovery, and diagnostics without replacing either application. If you develop both sides and want to understand how requests move between them, the extra setup can be worthwhile; for a client that only calls an existing API, running it standalone may be enough.

Connecting .NET MAUI and ASP.NET Core with Aspire was originally published in Medialesson on Medium, where people are continuing the conversation by highlighting and responding to this story.

What Is a Seven-Segment Display?

A seven-segment display is one of the most recognizable digital UI patterns. It is the visual language of alarm clocks, calculators, kitchen timers, fuel pumps, lab equipment, and old arcade scoreboards.

Instead of drawing a character with curves and strokes like a normal font, a seven-segment display uses seven fixed bars:

 -- A --
|       |
F       B
|       |
 -- G --
|       |
E       C
|       |
 -- D --

Each character is a combination of those bars. For example:

• 8 lights every segment.
• 1 lights only the upper-right and lower-right segments.
• 0 lights every segment except the middle bar.
• - lights only the middle bar.

The charm comes from the constraint. You do not have a full alphabet in the traditional sense. You have a small set of physical shapes that can approximate numbers and a useful subset of letters. That limitation is exactly what makes the display feel mechanical, retro, and immediately readable.

Why Build This as a Custom MAUI Control?

The obvious shortcut would be to use a seven-segment font. That can work for simple demos, but a real reusable UI control gives you more control:

• You can draw active and inactive segments separately.
• You can add glow without relying on font effects.
• You can scale the display to any size.
• You can expose colors, spacing, thickness, and animation as bindable properties.
• You can make the control theme-aware through normal MAUI binding features.

This sample builds the display manually with SkiaSharp, which keeps the rendering predictable across Android, iOS, Mac Catalyst, and Windows.

Screenshots of the SevenSegmentDisplay Control

Project Shape

The sample keeps the repository layout intentionally clean:

.editorconfig
Directory.Build.props
Directory.Packages.props
NuGet.config
MauiSevenSegmentDisplay.slnx
README.md
src/
└── MauiSevenSegmentDisplay/
    ├── Controls/
    │   ├── SevenSegmentDisplay.cs
    │   ├── SegmentCharacterMap.cs
    │   ├── SevenSegmentOptions.cs
    │   └── SevenSegmentParts.cs
    ├── Pages/
    │   ├── MainPage.xaml
    │   └── MainPage.xaml.cs
    ├── ViewModels/
    │   └── MainViewModel.cs
    └── MauiSevenSegmentDisplay.csproj
tests/
└── MauiSevenSegmentDisplay.Tests/
    ├── SegmentCharacterMapTests.cs
    ├── SevenSegmentOptionsTests.cs
    └── MauiSevenSegmentDisplay.Tests.csproj

The platform, resource, and property folders generated by the MAUI template are still part of the app because they provide the real cross-platform project plumbing.

Central Package Management

The solution uses central package management through Directory.Packages.props. That keeps package versions out of the project file and makes future updates easier:

<PackageVersion Include="SkiaSharp" Version="4.150.0" />
<PackageVersion Include="SkiaSharp.Views.Maui.Controls" Version="4.150.0" />
<PackageVersion Include="CommunityToolkit.Mvvm" Version="8.4.2" />
<PackageVersion Include="NUnit" Version="4.6.1" />
<PackageVersion Include="NUnit3TestAdapter" Version="6.2.0" />
<PackageVersion Include="Microsoft.NET.Test.Sdk" Version="18.7.0" />

The project targets the installed stable .NET 10 MAUI workload and uses net10.0-android, net10.0-ios, net10.0-maccatalyst, and net10.0-windows10.0.19041.0.

Character Mapping

The mapping lives in SegmentCharacterMap. Each supported character maps to a SevenSegmentParts flag combination.

For example, 0 uses every segment except G, while 2 uses A, B, G, E, and D.

Unsupported characters map to None. That is important for a reusable control because a UI control should not throw just because a bound string contains an unexpected character. Rendering a blank is safer and easier to reason about.

The sample also treats : and . as special narrow symbols. They do not use the seven bars; they are drawn as round lights.

Rendering with SkiaSharp

The main control inherits from SKCanvasView. Every visual part is drawn manually in OnPaintSurface.

The renderer works in a design coordinate system first:

• Character width is based on segment thickness.
• Character height is based on segment thickness.
• Symbol width is narrower for colon and decimal point.
• Character spacing is included in the measured design width.

After measuring the string, the control calculates a scale factor that fits the design model inside the actual Skia canvas:

float scale = MathF.Min(
    availableWidth / totalWidth, 
    availableHeight / characterHeight);

That means the same control can be used in a small card, a wide desktop layout, or a phone screen without hard-coded pixel sizes.

Segment Geometry

Each normal segment is a polygon, not a rectangle. Horizontal segments are six-point beveled shapes. Vertical segments use the same idea rotated into a vertical slot.

The points are then passed into a helper that rounds each corner by replacing sharp turns with short quadratic curves. This gives the display a more physical LED/LCD look without making the geometry hard to explain.

The renderer draws in layers:

1. Inactive segment body
2. Optional glow for active segments
3. Active segment body

That layering matters. The inactive segments make the whole display shape readable, while the active segments stay bright and crisp.

Glow

Glow is implemented by drawing the same active segment path with a blurred Skia paint before drawing the crisp active fill.

The control exposes:

• GlowColor
• GlowIntensity
• IsGlowEnabled

This keeps the effect optional and styleable. A subtle blue countdown display can use a lower glow intensity, while a bright clock can look more like a classic LED sign.

Animation

When the Text property changes, the control runs a short pulse animation. The pulse slightly increases the glow and brightness impression while the new text is displayed.

The animation uses an IDispatcherTimer owned by the control. That avoids a startup issue where MAUI’s animation manager might not yet be available during early binding updates.

The timer stops when the animation completes and also stops when the control unloads.

Bindable Properties

The control exposes the common knobs a consuming app would expect:

<controls:SevenSegmentDisplay
    Text="{Binding CurrentTime}"
    SegmentColor="Lime"
    InactiveSegmentColor="DarkGreen"
    DisplayBackgroundColor="Black"
    GlowColor="Lime"
    SegmentThickness="12"
    CharacterSpacing="8"
    SegmentCornerRadius="4"
    InactiveSegmentOpacity="0.28"
    GlowIntensity="0.7"
    IsGlowEnabled="True"
    IsAnimationEnabled="True"
    AnimationDuration="250" />

The property is named DisplayBackgroundColor instead of BackgroundColor to avoid confusion with MAUI’s existing VisualElement.BackgroundColor.

App Theming

The demo page uses AppThemeBinding for light and dark themes:

SegmentColor="{AppThemeBinding Light=#27D86A, Dark=#39FF72}"
InactiveSegmentColor="{AppThemeBinding Light=#2B6640, Dark=#1E5531}"
InactiveSegmentOpacity="{AppThemeBinding Light=0.34, Dark=0.3}"

The surrounding page becomes bright in light mode, while the display surfaces stay dark. That keeps the retro display contrast intact in both themes.

Unit Tests

The sample includes an NUnit project under tests/MauiSevenSegmentDisplay.Tests. The tests focus on behavior that is easy to validate without launching a MAUI UI:

• SegmentCharacterMapTests verifies digit mappings, demo status-letter mappings, blank symbol mappings, and unsupported-character behavior.
• SevenSegmentOptionsTest verifies that the design-space constants stay sensible: regular characters are wider than punctuation symbols, digits are taller than they are wide, and segment thickness has a positive lower bound.

These tests are intentionally small. They protect the most important non-visual contract of the control: given a character, the renderer receives the expected segment flags. Pixel-perfect rendering tests would require a separate screenshot or image-comparison workflow, which is useful for a production control but would distract from this article’s core idea.

The test project links the small UI-independent source files instead of referencing the MAUI app project directly. That keeps NUnit fast and avoids pulling MAUI Resizetizer targets into a plain unit-test build.

Running the Sample

From the solution folder:

dotnet build MauiSevenSegmentDisplay.slnx
dotnet test MauiSevenSegmentDisplay.slnx

The sample builds for Android, iOS, Mac Catalyst, and Windows when the matching MAUI workloads are installed.

Closing Thoughts

The interesting part of this control is not that it draws numbers. The interesting part is that a small, constrained visual system can become a polished, reusable UI component when it is modeled carefully:

• A clear segment map
• Scalable geometry
• Bindable styling
• Theme-aware colors
• Lightweight animation
• MVVM-friendly sample state

That is a good pattern for custom MAUI controls in general. Start with the visual model, expose the right customization points, keep platform behavior out of the control, and let SkiaSharp handle the pixels.

The complete source code for this project is available on GitHub. Feel free to explore the implementation, try it yourself, and use it as a starting point for your own custom .NET MAUI controls:

tsjdev-apps/sevensegmentdisplay-maui

This article was created as part of the annual .NET MAUI UI July community event, where developers from around the world share blog posts and videos showcasing ideas, techniques, and projects built with .NET MAUI throughout July. You can learn more about the event here: .NET MAUI UI July 2026.

Windows packaging is usually where a MAUI setup stops feeling “template simple.” The build command is not the hard part. The friction usually comes from everything around it:

• the package identity in Package.appxmanifest
• the certificate subject and publisher name
• the difference between a signed package and a trusted package
• the extra files a test machine may need before installation works

That is exactly why it helps to make the Windows pipeline explicit instead of treating it like “just another dotnet publish”.

In this post, I will walk through a practical GitHub Actions setup for a .NET MAUI Windows app. The goal is simple:

• align the Windows manifest with the signing identity
• create a self-signed test certificate
• store the signing material in GitHub Secrets
• build a signed .msix in GitHub Actions
• include the public certificate in the artifact
• distribute a test package that can be installed on managed test machines

The self-signed certificate described in this guide is intended only for local testing and controlled distribution to machines you manage. It is not suitable for publishing via the Microsoft Store or for public production use. If you plan to distribute your application through the Microsoft Store, Microsoft will handle the provisioning of the appropriate certificate.

This guide is based on a .NET 10 MAUI project and a Windows-based GitHub Actions runner.

If you are following the full cross-platform series, continue here as well:

• From Commit to APK: Automating .NET MAUI Android Builds with GitHub Actions
• From Commit to IPA: Automating .NET MAUI iOS Builds with GitHub Actions

🤖 Why Windows Packaging Needs More Than A Build Command

For Windows MSIX packaging, a successful CI run does not automatically mean the app will install on another machine.

That usually breaks for one of four reasons:

• the package is not signed at all
• the certificate does not match the manifest publisher
• the test machine does not trust the certificate
• the target machine is missing a required dependency such as the Windows App Runtime package

That makes the Windows pipeline more than a compile step. It is a packaging and distribution flow.

🧰 What You Need Before You Start

Before you begin, make sure you have:

• A .NET MAUI app targeting net10.0-windows10.0.19041.0
• A planned publisher name, for example CN=Sebastian Jensen
• Permission to create and export a test certificate
• Access to add repository secrets in GitHub

In the sample repository, the relevant files are:

src/MyAwesomeMauiApp/MyAwesomeMauiApp.csproj
src/MyAwesomeMauiApp/Platforms/Windows/Package.appxmanifest
.github/workflows/windows-build.yml

🧩 The Windows Signing Pieces In Plain Terms

Before changing anything, it helps to map the Windows terminology to concrete files and settings:

• Package.appxmanifest: defines the package identity and publisher
• Publisher: the certificate subject that the package is expected to be signed with
• .pfx: the certificate including the private key, used by GitHub Actions for signing
• .cer: the public certificate only, used to trust the package on test machines
• Trusted People: certificate store Windows checks for trusted app package signers

The key rule is simple:

The Publisher in the manifest must exactly match the Subject of the certificate used for signing.

🎯 Step 1: Clean Up The Windows Package Identity

Open src/MyAwesomeMauiApp/Platforms/windows/Package.appxmanifest and review the Identity and Properties values carefully.

In a template project, the file often still contains placeholders such as:

<Identity Name="maui-package-name-placeholder" 
          Publisher="CN=User Name" 
          Version="0.0.0.0" />

For a real pipeline, replace these with real values. Example:

<Identity Name="SebastianJensen.MyAwesomeMauiApp" 
          Publisher="CN=Sebastian Jensen" 
          Version="0.0.0.0" />

You should also update the display values:

<Properties>
  <DisplayName>MyAwesomeMauiApp</DisplayName>
  <PublisherDisplayName>Sebastian Jensen</PublisherDisplayName>
  <Logo>$placeholder$.png</Logo>
</Properties>

The important part is not the exact wording. The important part is that the Publisher value matches the certificate subject exactly, character for character.

📦 Step 2: Understand WindowsPackageType

Many MAUI templates start with:

<WindowsPackageType>None</WindowsPackageType>

That means the app is configured as unpackaged by default.

For the Windows pipeline in this post, that is fine. The workflow overrides it at publish time with:

-p:WindowsPackageType=MSIX

That keeps the project flexible while still allowing CI to produce a packaged Windows build.

🔐 Step 3: Create A Self-Signed Test Certificate

For local testing and controlled local distribution, a self-signed certificate is the simplest option.

Use this certificate only for local validation and managed test installs. Do not use it as a replacement for production or Store signing.

Open PowerShell and run:

$publisher = "CN=Sebastian Jensen"

$cert = New-SelfSignedCertificate `
  -Type Custom `
  -Subject $publisher `
  -KeyUsage DigitalSignature `
  -CertStoreLocation "Cert:\CurrentUser\My" `
  -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3","2.5.29.19={text}") `
  -FriendlyName "MyAwesomeMauiApp"

This creates a signing certificate in your personal certificate store.

The important details here are:

• the subject must match the package publisher
• the certificate must include the Code Signing EKU
• the certificate must be usable for digital signatures
• after creation, inspect it:

Get-ChildItem "Cert:\CurrentUser\My" |
  Where-Object { $_.FriendlyName -eq "MyAwesomeMauiApp" } |
  Format-Table Subject, Thumbprint, HasPrivateKey

HasPrivateKey must be True.

📤 Step 4: Export The Certificate Files You Need

The pipeline needs the private key for signing, and the test machines need the public certificate for trust.

Export the public certificate:

Export-Certificate `
  -Cert "Cert:\CurrentUser\My\$($cert.Thumbprint)" `
  -FilePath ".\MyAwesomeMauiApp-Test.cer"

Then export the .pfx for GitHub Actions:

$password = ConvertTo-SecureString "EinSicheresTestPasswort123!" `
  -AsPlainText -Force

Export-PfxCertificate `
  -Cert "Cert:\CurrentUser\My\$($cert.Thumbprint)" `
  -FilePath ".\MyAwesomeMauiApp-Test.pfx" `
  -Password $password

The .cer is safe to distribute to testers. The .pfx is not. Keep the .pfx private and move it only into GitHub Secrets.

🔄 Step 5: Convert The .pfx To Base64

GitHub Secrets store text, so convert the exported .pfx into a Base64 string.

$base64 = [Convert]::ToBase64String([IO.File]::ReadAllBytes
  (".\MyAwesomeMauiApp-Test.pfx"))

$base64 | Set-Content `
  -Path .\MyAwesomeMauiApp-Test.pfx.base64.txt `
  -NoNewline

Get-Content .\MyAwesomeMauiApp-Test.pfx.base64.txt

At the end of this step, you have a text representation of the .pfx that can be stored safely as a GitHub repository secret for this test-signing flow.

🕵️ Step 6: Add The Required GitHub Secrets

For the sample Windows workflow, add these repository secrets:

• PFX_BASE64: the full Base64 content of the exported .pfx
• PFX_PASSWORD: the password used when exporting the .pfx

This is the complete signing input set for the sample workflow.

⚙️ Step 7: Create The GitHub Actions Workflow

Create a file named .github/workflows/windows-build.yml.

Use this workflow:

name: Build .NET MAUI Windows App (.msix)

on:
  # Allow manual execution from the GitHub Actions UI
  workflow_dispatch:

jobs:
  build-windows:
    runs-on: windows-latest

    env:
      # Path to your .NET MAUI project file
      PROJECT_PATH: src/MyAwesomeMauiApp/MyAwesomeMauiApp.csproj

    steps:
      - name: Checkout repository
        uses: actions/checkout@v6

      - name: Setup .NET from global.json
        uses: actions/setup-dotnet@v5
        with:
          global-json-file: global.json

      - name: Install MAUI Workload
        run: dotnet workload install maui

      - name: Set version variables
        run: |
          $buildNumber = [int]"${{ github.run_number }}"
          $packageBuild = [math]::Floor($buildNumber / 65535)
          $packageRevision = $buildNumber % 65535

          echo "VERSION_DISPLAY=1.0.$buildNumber" | Out-File -FilePath $env:GITHUB_ENV -Append
          echo "VERSION_CODE=$((10000 + $buildNumber))" | Out-File -FilePath $env:GITHUB_ENV -Append
          echo "WINDOWS_PACKAGE_VERSION=1.0.$packageBuild.$packageRevision" | Out-File -FilePath $env:GITHUB_ENV -Append

      - name: Restore NuGet packages
        run: dotnet restore "$env:PROJECT_PATH"

      - name: Decode and import certificate
        run: |
          $certPath = "$env:USERPROFILE\MyMauiAppCert.pfx"
          [System.IO.File]::WriteAllBytes($certPath, [System.Convert]::FromBase64String("${{ secrets.PFX_BASE64 }}"))
  
          $password = ConvertTo-SecureString "${{ secrets.PFX_PASSWORD }}" -AsPlainText -Force
          $cert = Import-PfxCertificate -FilePath $certPath -Password $password -CertStoreLocation Cert:\CurrentUser\My

          [xml]$manifest = Get-Content "src/MyAwesomeMauiApp/Platforms/Windows/Package.appxmanifest"
          $publisher = $manifest.Package.Identity.Publisher
          if ($cert.Subject -ne $publisher) {
            throw "Imported certificate subject '$($cert.Subject)' does not match manifest publisher '$publisher'."
          }

          $publicCertPath = "$env:RUNNER_TEMP\MyAwesomeMauiApp-Test.cer"
          Export-Certificate `
            -Cert "Cert:\CurrentUser\My\$($cert.Thumbprint)" `
            -FilePath $publicCertPath | Out-Null
  
          echo "CERT_THUMBPRINT=$($cert.Thumbprint)" | Out-File -FilePath $env:GITHUB_ENV -Append
          echo "PUBLIC_CERT_PATH=$publicCertPath" | Out-File -FilePath $env:GITHUB_ENV -Append

      - name: Build and Sign Windows App (Release)
        run: |
          dotnet publish "$env:PROJECT_PATH" `
            -f net10.0-windows10.0.19041.0 `
            -c Release `
            -p:RuntimeIdentifierOverride=win-x64 `
            -p:WindowsPackageType=MSIX `
            -p:AppxPackage=true `
            -p:AppxPackageSigningEnabled=true `
            -p:ApplicationVersion=$env:VERSION_CODE `
            -p:ApplicationDisplayVersion=$env:VERSION_DISPLAY `
            -p:AppxPackageVersion=$env:WINDOWS_PACKAGE_VERSION `
            -p:PackageCertificateThumbprint=$env:CERT_THUMBPRINT

      - name: Collect distributable files
        run: |
          $destination = "$(pwd)\output"
          New-Item -ItemType Directory -Force -Path $destination | Out-Null
          $files = Get-ChildItem -Recurse -Include *.msix
          foreach ($file in $files) {
            Copy-Item $file.FullName -Destination $destination -Force
          }

          Copy-Item $env:PUBLIC_CERT_PATH -Destination (Join-Path $destination "MyAwesomeMauiApp-Test.cer") -Force

          @'
          Install files in this artifact:
          - MyAwesomeMauiApp_*.msix: the app package
          - Microsoft.WindowsAppRuntime.*.msix: Windows App Runtime dependency package
          - MyAwesomeMauiApp-Test.cer: public test certificate to trust on the target machine

          Recommended installation flow on a test machine:
          1. Import MyAwesomeMauiApp-Test.cer into LocalMachine\TrustedPeople.
          2. Install Microsoft.WindowsAppRuntime.*.msix if Windows App Runtime is not already present.
          3. Install MyAwesomeMauiApp_*.msix.

          Notes:
          - The Windows App Runtime package may be unnecessary on machines where the required runtime is already installed.
          '@ | Set-Content -Path (Join-Path $destination "INSTALL.txt")

      - name: Upload Windows test package
        uses: actions/upload-artifact@v6
        with:
          name: windows-build
          path: output

🧠 Step 8: Understand What The Workflow Does

At a high level, the workflow breaks down into a small number of predictable phases.

1. Check Out The Repository
2. Install The Correct .NET SDK
3. Install The MAUI Workload
4. Set Version Variables For Upgradable MSIX Builds
5. Reconstruct And Import The Signing Certificate
6. Publish The Signed Windows Package
7. Collect The Files Testers Actually Need
8. Upload The Artifact

After the workflow completes, you can download one artifact from the workflow run and hand that package set to a tester.

📁 Step 9: What Is Inside The Artifact?

With the sample workflow above, the artifact should contain at least these files:

• MyAwesomeMauiApp_*.msix
• Microsoft.WindowsAppRuntime.1.7.msix or a similar Windows App Runtime package
• MyAwesomeMauiApp-Test.cer
• INSTALL.txt

That distribution model solves two practical problems:

• the tester gets the public certificate that is needed to trust the package
• the tester also gets the dependency package that may be required before the app package installs

The recommended install flow on a test machine is:

1. import MyAwesomeMauiApp-Test.cer into LocalMachine\TrustedPeople
2. install Microsoft.WindowsAppRuntime.*.msix if that runtime is not already present
3. install MyAwesomeMauiApp_*.msix

On some machines, importing into TrustedPeople is enough. If Windows still reports that the chain ends in an untrusted root, also import the same public certificate into LocalMachine\Root.

The Windows App Runtime package may be unnecessary on machines where the matching runtime is already installed. Including it in the artifact still makes the test package more self-contained and easier to hand to others.

▶️ Step 10: Run The Workflow

Push the workflow file to your repository, open the Actions tab in GitHub, and run the workflow manually.

Because the sample uses workflow_dispatch, this is a safe way to validate the Windows packaging and test-distribution flow before attaching it to push, tags, or release branches.

If the run succeeds, you should see a windows-build artifact containing the final package set.

🚧 Common Issues To Watch For

Even when the commands are correct, a few Windows-specific mistakes show up repeatedly.

Publisher Does Not Match The Certificate Subject

If Package.appxmanifest says CN=Sebastian Jensen but the certificate was created with CN=User Name, signing will fail or the package will be unusable.

The CI Certificate And The Manifest Publisher Do Not Match

If the Publisher value in Package.appxmanifest differs from the subject of the certificate loaded from PFX_BASE64, the workflow may build an unusable package or fail during signing.

WindowsPackageType Is Still Effectively Unpackaged

If you publish with AppxPackage=true but do not request a packaged Windows build, the publish step can fail with an “Improper project configuration” error.

The Artifact Does Not Include The Public Certificate

If the tester receives only the .msix file, installation can fail even though CI succeeded. For self-signed test distribution, the public .cer should travel with the package.

The Target Machine Does Not Trust The Certificate Yet

If the package is signed but Windows reports trust or chain errors, import the public certificate into the appropriate certificate store on the target machine.

The Windows App Runtime Dependency Is Missing

If the app package references the Windows App Runtime and the target machine does not already have it, the app package may not install cleanly until Microsoft.WindowsAppRuntime.*.msix is installed.

A Test Certificate Is Being Treated Like A Production Certificate

This guide uses a self-signed certificate for local testing and controlled local distribution only. If your goal is Store publishing or broader production distribution, you need the signing approach that matches that release channel instead of reusing this test certificate.

Wrong Runtime Identifier Parameter

For .NET 10 MAUI Windows publishing, use:

-p:RuntimeIdentifierOverride=win-x64

not:

-p:RuntimeIdentifier=win-x64

Template Values Were Never Replaced

Values such as maui-package-name-placeholder, $placeholer$, or CN=User Name are fine for a template, but they should not survive into a real Windows packaging setup.

MSIX Version Does Not Increase Between Builds

If the package identity version stays constant, Windows treats the next package as the same or older build and blocks in-place upgrades.

Set AppxPackageVersion during publish and derive it from a monotonic CI value such as github.run_number.

🏁 Final Thoughts

The tricky part of Windows CI is not the dotnet publish command itself.

It is getting the identity, certificate, artifact contents, and installation story aligned.

Once those pieces are consistent, the workflow becomes much more predictable:

1. define a real package identity
2. create a matching test certificate
3. store the signing material in GitHub Secrets
4. build a signed package in GitHub Actions
5. distribute the artifact together with the public certificate and required dependency package

That is the point where Windows packaging stops feeling mysterious and starts feeling mechanical.

Just keep the scope in mind: this certificate is for local testing and controlled local distribution only. When you move to Store or production distribution, treat signing as a separate release concern with its own certificate and trust requirements.

Y️ou can find a sample repository containing a simple .NET MAUI application on GitHub.

From Commit to MSIX: Automating .NET MAUI Windows Builds with GitHub Actions was originally published in Medialesson on Medium, where people are continuing the conversation by highlighting and responding to this story.

The hard part of iOS automation is usually not writing YAML.

It is getting the Apple-side prerequisites into a shape that CI can actually use: a valid .p12, the correct bundle identifier, an App Store Connect API key, and a provisioning profile that already exists in Apple Developer.

Once that preparation is done, the GitHub Actions part becomes much more predictable.

In this post, I will focus only on the GitHub Actions workflow and the repository secrets required to build a signed .ipa. The goal is simple:

• add the required iOS secrets to GitHub
• understand what each secret is used for
• run the iOS GitHub Actions workflow
• build and sign an .ipa file
• upload the final package as a workflow artifact

This guide is based on a .NET 10 MAUI project and a macOS-based GitHub Actions runner.

If you still need to create the certificate, identifier, or provisioning profile first, start here: Preparation Post

🤖 Why Build iOS In GitHub Actions?

For iOS, CI gives you a few immediate benefits:

• every build uses the same .NET SDK and Xcode version
• signing is handled in a repeatable way instead of on one configured Mac
• provisioning profiles can be downloaded automatically during the run
• the final .ipa is attached to the workflow run
• the release process becomes auditable and reproducible

For .NET MAUI specifically, this matters because local Apple tooling differences are one of the easiest ways to get inconsistent iOS build results.

🧰 What You Need Before You Start

This post assumes these Apple-side prerequisites are already complete:

• A .NET MAUI app targeting net10.0-ios
• A GitHub repository containing the app
• A root global.json file pinned to the required .NET SDK
• An Apple Distribution certificate exported as .p12
• matching App ID / Bundle ID in Apple Developer
• A valid App Store provisioning profile in Apple Developer
• An App Store Connect API key

In the sample repository, the MAUI project file is:

src/MyAwesomeMauiApp/MyAwesomeMauiApp.csproj

The repository also pins the SDK with:

{
  "sdk": {
    "version": "10.0.200",
    "rollForward": "latestFeature"
  }
}

Step 0: Convert The .p12 For GitHub Secrets 🔄

GitHub Secrets store text, not binary files, so the exported .p12 has to be converted to Base64.

base64 -i ios_distribution.p12 | tr -d '\n' > ios.p12.base64.txt

The .p8 API key is already text, so that one does not need Base64 encoding. You store its full content directly as a GitHub secret later.

🕵️ Step 1: Add The Required GitHub Secrets

Before the workflow can run, the signing assets and App Store Connect credentials have to be available as repository secrets.

Add these secrets in your GitHub repository:

• IOS_P12_BASE64: the full Base64 content of your exported .p12 file
• IOS_P12_PASSWORD: the password used when exporting the .p12
• IOS_BUNDLE_ID: your bundle identifier, for example com.companyname.myawesomemauiapp
• APP_STORE_CONNECT_ISSUER_ID: the issuer ID from App Store Connect
• APP_STORE_CONNECT_KEY_ID: the key ID from App Store Connect
• APP_STORE_CONNECT_PRIVATE_KEY: the full content of the downloaded .p8 API key file

These six secrets are the complete input set for the sample iOS workflow in this repository.

🔍 Step 2: Understand What Each Secret Does

It helps to be very explicit about why each secret exists.

IOS_P12_BASE64

This is the portable version of your Apple Distribution certificate and private key. The workflow uses it to reconstruct and import the signing identity into a temporary keychain on the macOS runner.

IOS_P12_PASSWORD

This is the export password for the .p12 file. Without it, the import action cannot unlock the certificate package.

IOS_BUNDLE_ID

This is the application identifier used during publish and profile download. It must match the App ID and provisioning profile you created in Apple Developer.

APP_STORE_CONNECT_ISSUER_ID

This identifies the App Store Connect API key issuer. The workflow needs it to authenticate against Apple when requesting provisioning profiles.

APP_STORE_CONNECT_KEY_ID

This is the identifier for the API key itself. Together with the issuer ID and private key, it lets the workflow call App Store Connect securely.

APP_STORE_CONNECT_PRIVATE_KEY

This is the full text content of the .p8 API key file. It is not Base64 encoded in this setup. You store the exact file content as the secret value.

⚙️ Step 3: Create The GitHub Actions Workflow

Create a file named .github/workflows/ios-build.yml.

Use this workflow:

name: Build .NET MAUI iOS App (.ipa)

on:
  workflow_dispatch:

jobs:
  build-ios:
    runs-on: macos-26

    env:
      PROJECT_PATH: src/MyAwesomeMauiApp/MyAwesomeMauiApp.csproj

    steps:
      - name: Checkout repository
        uses: actions/checkout@v6

      - name: Setup .NET from global.json
        uses: actions/setup-dotnet@v5
        with:
          global-json-file: global.json

      - name: Select Xcode 26.2
        run: |
          sudo xcode-select -s /Applications/Xcode_26.2.app/Contents/Developer
          xcode-select -p

      - name: Install MAUI Workload
        run: dotnet workload install maui

      - name: Import P12 File
        uses: apple-actions/import-codesign-certs@v6
        with:
          p12-file-base64: ${{ secrets.IOS_P12_BASE64 }}
          p12-password: ${{ secrets.IOS_P12_PASSWORD }}
          keychain: build
          create-keychain: true
          keychain-password: buildpass

      - name: Activate build.keychain
        run: |
          security list-keychains -s ~/Library/Keychains/build.keychain-db
          security default-keychain -s ~/Library/Keychains/build.keychain-db
          security unlock-keychain -p buildpass ~/Library/Keychains/build.keychain-db

      - name: Extract signing identity
        run: |
          identity=$(security find-identity -v -p codesigning | grep "Apple Distribution" | head -n 1 | awk -F\" '{print $2}')
          echo "CODE_SIGN_IDENTITY=$identity" >> $GITHUB_ENV

      - name: Download Provisioning Profiles
        uses: apple-actions/download-provisioning-profiles@v5
        with:
          bundle-id: ${{ secrets.IOS_BUNDLE_ID }}
          profile-type: IOS_APP_STORE
          issuer-id: ${{ secrets.APP_STORE_CONNECT_ISSUER_ID }}
          api-key-id: ${{ secrets.APP_STORE_CONNECT_KEY_ID }}
          api-private-key: ${{ secrets.APP_STORE_CONNECT_PRIVATE_KEY }}

      - name: Set version variables
        run: |
          buildNumber="${{ github.run_number }}"
          echo "VERSION_DISPLAY=1.0.$buildNumber" >> $GITHUB_ENV
          echo "VERSION_CODE=$((10000 + buildNumber))" >> $GITHUB_ENV

      - name: Restore packages
        run: dotnet restore "$PROJECT_PATH"

      - name: Publish iOS app
        run: |
          dotnet publish "$PROJECT_PATH" -f net10.0-ios -c Release \
            -p:ApplicationVersion="$VERSION_CODE" \
            -p:ApplicationDisplayVersion="$VERSION_DISPLAY" \
            -p:ApplicationId="${{ secrets.IOS_BUNDLE_ID }}" \
            -p:CodesignKey="$CODE_SIGN_IDENTITY"

      - name: Copy .ipa to output
        run: |
          mkdir -p output
          find . -name "*.ipa" -exec cp {} output/ \;

      - name: Upload final IPA only
        uses: actions/upload-artifact@v6
        with:
          name: ios-build
          path: output

🧠 Step 4: Understand What The Workflow Does

At a high level, the workflow breaks down into a few predictable phases.

1. Check Out The Repository
2. Install The Correct .NET SDK
3. Select The Supported Xcode Version
4. Install The MAUI Workload
5. Import The Certificate From Secrets
6. Activate The Build Keychain
7. Resolve The Signing Identity Automatically
8. Download The Provisioning Profile From Apple
9. Generate Version Numbers From The Pipeline Run
10. Publish The iOS App
11. Copy And Upload The Final .ipa

▶️ Step 5: Run The Workflow

Push the workflow file to your repository, open the Actions tab in GitHub, and run the workflow manually.

Because the sample uses workflow_dispatch, this is a safe way to validate the pipeline before attaching it to push, tags, or release branches.

If everything is configured correctly, the workflow run produces an ios-buid artifact containing the final signed .ipa.

🚧 Common Issues To Watch For

Even when the YAML is correct, a few secret-related mistakes show up frequently.

Wrong IOS_BUNDLE_ID

If the bundle identifier does not match the App ID and provisioning profile in Apple Developer, signing will fail.

Broken IOS_P12_BASE64 Value

If the Base64 content is truncated or copied incorrectly, certificate import will fail.

Wrong IOS_P12_PASSWORD

If the export password does not match the .p12, the certificate import action cannot unlock it.

Incorrect App Store Connect Values

If the issuer ID, key ID, or .p8 content is wrong, the provisioning profile download step fails.

Xcode Version Drift

If the selected Xcode version is not supported by the installed .NET MAUI workload, publishing can fail even when signing assets are correct.

🏁 Final Thoughts

Once the Apple-side prerequisites exist, the iOS GitHub Actions workflow is mostly about supplying the right secrets to a predictable build process.

That is what makes this setup useful.

The secrets stay in GitHub, the provisioning profile stays in Apple Developer, and the workflow reconstructs only what it needs at runtime to produce a signed .ipa.

If you standardize those inputs, iOS releases become much less of a hand-crafted process and much more of a repeatable pipeline.

Y️ou can find a sample repository containing a simple .NET MAUI application on GitHub.

️

From Commit to IPA: Automating .NET MAUI iOS Builds with GitHub Actions was originally published in Medialesson on Medium, where people are continuing the conversation by highlighting and responding to this story.

If Android CI usually starts with a keystore, iOS CI starts much earlier. Before GitHub Actions can build a valid .ipa, Apple signing has to be prepared correctly. That means your app identifier has to exist, your distribution certificate has to be created and exported, your provisioning profile has to match, and your App Store Connect access has to be ready for automation.

This is the part that often feels confusing because several Apple systems are involved at the same time. The good news is that the setup is very manageable once you separate it into a few concrete pieces.

In this post, I will walk through the Apple-side preparation for an iOS build. The goal is simple:

• understand which signing assets are required
• create the app identifier
• generate the certificate request
• create the Apple Distribution certificate
• export the certificate as .p12
• create the provisioning profile
• create the App Store Connect API key for CI

🤖 Why iOS Preparation Matters

For iOS, the CI workflow is only as reliable as the signing setup behind it.

If the certificate, identifier, or provisioning profile do not match, the pipeline does not fail randomly. It fails for a very specific reason that traces back to missing preparation.

Getting this right upfront gives you a few immediate benefits:

• your bundle identifier is defined once and used consistently
• your signing certificate is portable to CI through a .p12 export
• your provisioning profile matches the exact app you intend to ship
• your GitHub Actions workflow can download the right profile automatically
• future release builds stop depending on one specific Mac being configured correctly

🧰 What You Need Before You Start

Before you begin, make sure you have:

• An Apple Developer membership
• Access to App Store Connect
• A Mac, or access to one, for Keychain Access and certificate export
• A planned bundle identifier such as com.companyname.myawesomemauiapp

🧩 The iOS Signing Pieces In Plain Terms

Before creating anything, it helps to map the Apple terminology to concrete files and decisions.

• Bundle ID / App ID: the unique identifier for your app, for example com.companyname.myawesomemauiapp
• Certificate Signing Request (CSR): the request file used to ask Apple for a signing certificate
• Apple Distribution certificate: the certificate used to sign release builds for distribution
• .p12 file: an export that contains the certificate and its private key for import into CI
• Provisioning profile: a file that ties your App ID, distribution method, and certificate together
• App Store Connect API key: the credential GitHub Actions can use to download provisioning profiles automatically

The important part is not memorizing the names. The important part is that all of these assets point to the same app identity.

Step 1: Confirm The MAUI Application ID 🎯

Before creating anything in Apple Developer, confirm the identifier your app is supposed to use.

You can keep this value in the project file or override it during CI, but whichever route you choose, the Apple identifier and provisioning profile must use the same value.

If you change the bundle ID later, you will also need to update the Apple identifier and the provisioning profile.

Step 2: Create The Identifier In Apple Developer 📱

Now create the App ID that represents your app in Apple Developer.

In Apple Developer:

• Open Certificates, Identifiers & Profiles
• Go to Identifiers
• Select Register an App ID
• Choose App
• Enter a description, for example MyAwesomeMauiApp
• Enter the bundle ID, for example com.companyname.myawesomemauiapp
• 7. Enable any capabilities your app needs
• 8. Save the identifier

If your app uses capabilities such as push notifications, associated domains, sign in with Apple, or keychain sharing, enable them here. The provisioning profile created later inherits from this identifier configuration.

If your app does not need extra capabilities yet, keep the setup simple and add them later only when the feature exists. Adding capabilities will not change your identifier.

Step 3: Create A Certificate Signing Request 📝

To create the Apple Distribution certificate, Apple needs a Certificate Signing Request, called CSR.

The most common approach is through Keychain Access on macOS.

• Open Keychain Access
• Select Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority
• Enter your email address
• Enter your name
• Choose Saved to disk
• Save the generated .csr or .certSigningRequest file

This creates the request file Apple uses to issue the certificate and also creates the private key on your Mac.

Step 4: Create The Apple Distribution Certificate 🍎

With the CSR ready, create the release signing certificate.

In Apple Developer:

• Open Certificates, Identifiers & Profiles
• Go to Certificates
• Select Add
• Choose Apple Distribution
• Upload the CSR from the previous step
• Download the generated certificate file, typically .cer

This certificate is the release signing identity you need for App Store or distribution builds.

The downloaded .cer file by itself is not what GitHub Actions will use directly. CI needs a .p12 export that includes both the certificate and its private key.

Step 5: Export The Certificate As .p12 🔐

Now convert the certificate into a portable format that CI can import.

On your Mac:

• Double-click the downloaded .cer file to import it into Keychain Access
• Verify the certificate appears together with its private key under My Certificates
• Right-click the certificate entry
• Choose Export
• Export it as ios_distribution.p12
• Set a strong export password

The .p12 file is the artifact your GitHub Actions workflow will import into a temporary keychain.

If the private key does not appear together with the certificate, the CSR and certificate were not created on the same key material, and the export will not work correctly. That is one of the most common iOS signing mistakes.

Step 6: Create The Provisioning Profile 📦

With the identifier and certificate in place, create the provisioning profile that binds them together.

In Apple Developer:

• Open Certificates, Identifiers & Profiles
• Go to Profiles
• Select Add
• Choose the distribution profile type that matches your release target
• Select the App ID you created earlier
• Select the Apple Distribution certificate
• Name the profile clearly, for example MyAwesomeMauiApp App Store
• Generate and save the profile

Step 7: Create An App Store Connect API Key 🔑

Our workflow later downloads provisioning profiles automatically instead of storing them in the repository. For that, GitHub Actions needs an App Store Connect API key.

In App Store Connect:

• Open Users and Access
• Go to Integrations
• Open App Store Connect API
• Create a new API key
• Give it a clear name
• Choose the appropriate access level
• Download the .p8 key file
• Record the Key ID
• Record the Issuer ID

The .p8 file is only downloadable once, so store it securely.

This key is not used to sign the app. It is used to authenticate the GitHub Action that fetches the provisioning profile from Apple.

Step 9: Verify Everything Matches ✅

Before moving to the GitHub Actions workflow, verify the following alignment:

• The Apple identifier bundle ID matches your application
• The provisioning profile was created for that same identifier
• The provisioning profile includes the Apple Distribution certificate
• The .p12 export comes from the same certificate and private key pair
• The App Store Connect API key has enough permission to download profiles

If these pieces are aligned, the CI workflow becomes much simpler because it is mostly importing assets and calling dotnet publish.

Final Thoughts 🏁

The hardest part of iOS CI is usually not the YAML file. It is preparing the Apple-side assets correctly.

Once the identifier, distribution certificate, .p12 export, provisioning profile, and App Store Connect API key are in place, the rest of the automation becomes much more mechanical.

That is the real milestone.

You move from “can one configured Mac produce a release build?” to “can the pipeline produce the same signed output every time?”

The next step is to wire these assets into GitHub repository secrets and let GitHub Actions build the .ipa. So keep an eye on my Medium account to see how we can setup a complete GitHub Action to create the .ipa file using the files and data created in this blog post.

Before The IPA: Preparing iOS Signing was originally published in Medialesson on Medium, where people are continuing the conversation by highlighting and responding to this story.

Shipping an Android app is easy to postpone and surprisingly hard to standardize. A local build works on one machine, someone manually signs an .aab, someone else exports an .apk, and six weeks later nobody remembers which password, keystore, or command produced the store-ready package. That is exactly where GitHub Actions helps.

In this post, I will walk through a practical setup for a .NET MAUI Android app that produces both .aab and .apk artifacts in CI. The goal is simple:

• build a .NET MAUI Android app in GitHub Actions
• sign it with an Android keystore
• generate both .aab and .apk
• upload the outputs as downloadable workflow artifacts

This guide is based on a .NET 10 MAUI project and a Windows-based GitHub Actions runner.

🤖 Why Build Android In GitHub Actions?

For Android, CI gives you a few immediate benefits:

• every build uses the same SDK and workload versions
• signing is automated and repeatable
• artifacts are stored with the workflow run
• version numbers can be derived automatically from the pipeline run
• you reduce the number of local machine differences that break release builds

For .NET MAUI specifically, Android builds are a good first platform to automate because the workflow is straightforward compared to iOS signing.

🧰 What You Need Before You Start?

Before creating the workflow, make sure you have these pieces ready:

• A .NET MAUI app targeting net10.0-android
• A GitHub repository containing the app
• A .NET SDK pinned with global.json
• An Android keystore for signing
• GitHub repository secrets for the keystore and passwords

In the sample repository, the Android project file is:

src/MyAwesomeMauiApp/MyAwesomeMauiApp.csproj

🎯 Step 1: Target .NET 10 In Your MAUI Project

Your MAUI project should explicitly target Android on .NET 10.

Example:

<TargetFrameworks>net10.0-android</TargetFrameworks>

If your project is still targeting net9.0-android, update it first. The workflow should match the framework your project actually targets.

📌 Step 2: Pin The SDK With global.json

Your CI pipeline should not depend on whichever SDK version happens to be installed on the runner image that day.

Create a global.json file in the repository root:

{
  "sdk": {
    "version": "10.0.200",
    "rollForward": "latestFeature"
  }
}

This does two things:

• it keeps local builds and CI builds aligned
• it makes SDK upgrades explicit instead of accidental

In GitHub Actions, actions/setup-dotnet can read this file directly.

🔐 Step 3: Create An Android Keystore

To produce signed Android packages, you need a keystore. If you already have one for your app, use that. If you are setting this up for the first time, create one with keytool.

Example command:

keytool -genkeypair \
  -v \
  -storetype PKCS12 \
  -keystore myapp.keystore \
  -alias myapp \
  -keyalg RSA \
  -keysize 2048 \
  -validity 10000

What each parameter means:

• -genkeypair: creates a new key pair and stores it in the keystore
• -v: prints verbose output
• -storetype PKCS12: uses the PKCS#12 keystore format
• -keystore myapp.keystore: writes the keystore to myapp.keystore
• -alias myapp: names the key entry inside the keystore
• -keyalg RSA: uses RSA as the key algorithm
• -keysize 2048: generates a 2048-bit key
• -validity 10000: makes the certificate valid for 10,000 days

Why 10000?

Because Android app signing certificates should remain valid for a very long time. 10000 days is a little over 27 years. That is a common practical choice because an expired signing certificate can complicate long-term app updates.

If you want a non-interactive version, use this:

keytool -genkeypair \
  -v \
  -storetype PKCS12 \
  -keystore myapp.keystore \
  -alias myapp \
  -keyalg RSA \
  -keysize 2048 \
  -validity 10000 \
  -storepass "YOUR_KEYSTORE_PASSWORD" \
  -keypass "YOUR_KEY_PASSWORD" \
  -dname "CN=Name, OU=Mobile, O=Company, L=City, S=State, C=US"

Here you can see the command in action:

🔄 Step 4: Convert The Keystore To Base64

GitHub Secrets store text, not raw binary files. That means your .keystore file needs to be converted to a Base64 string before you save it as a secret.

PowerShell

$base64 = 
  [Convert]::ToBase64String([IO.File]::ReadAllBytes(".\myapp.keystore"))
$base64 | Set-Content -Path .\myapp.keystore.base64.txt -NoNewline
Get-Content .\myapp.keystore.base64.txt

Bash

base64 -w 0 myapp.keystore > myapp.keystore.base64.txt
cat myapp.keystore.base64.txt

At the end of this step, you have a text representation of the keystore that can safely live in a GitHub secret.

🕵️ Step 5: Add The Required GitHub Secrets

In your GitHub repository, add these secrets:

• ANDROID_KEYSTORE: the full Base64 content of the keystore
• ANDROID_KEY_ALIAS: the alias inside the keystore, for example myapp
• ANDROID_KEY_PASSWORD: the password for the key entry
• ANDROID_KEYSTORE_PASSWORD: the password for the keystore itself

This is the minimum signing data required by the Android workflow.

️⚙️Step 6: Create The GitHub Actions Workflow

Create a file named .github/workflows/android-build.yml.

Use this workflow:

name: Build .NET MAUI Android App (.aab, .apk)

on:
  workflow_dispatch:

jobs:
  build-android:
    runs-on: windows-latest

    env:
      PROJECT_PATH: src/MyAwesomeMauiApp/MyAwesomeMauiApp.csproj

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup .NET from global.json
        uses: actions/setup-dotnet@v4
        with:
          global-json-file: global.json

      - name: Install MAUI Workload
        run: dotnet workload install maui

      - name: Decode Keystore
        run: |
          echo "${{ secrets.ANDROID_KEYSTORE }}" | Out-File -Encoding ascii -FilePath myapp.keystore.b64
          certutil -decode myapp.keystore.b64 myapp.keystore

      - name: Set version variables
        run: |
          $buildNumber = "${{ github.run_number }}"
          echo "VERSION_DISPLAY=1.0.$buildNumber" >> $env:GITHUB_ENV
          echo "VERSION_CODE=$((10000 + $buildNumber))" >> $env:GITHUB_ENV

      - name: Restore NuGet packages
        run: dotnet restore "$env:PROJECT_PATH"

      - name: Build (Release)
        run: |
          dotnet publish "$env:PROJECT_PATH" -f net10.0-android -c Release `
            -p:ApplicationVersion="$env:VERSION_CODE" `
            -p:ApplicationDisplayVersion="$env:VERSION_DISPLAY" `
            -p:AndroidSigningKeyAlias="${{ secrets.ANDROID_KEY_ALIAS }}" `
            -p:AndroidSigningKeyPass="${{ secrets.ANDROID_KEY_PASSWORD }}" `
            -p:AndroidSigningStorePass="${{ secrets.ANDROID_KEYSTORE_PASSWORD }}" `
            -p:AndroidSigningStore=myapp.keystore

      - name: Copy .aab and .apk to output
        run: |
          $destination = "$(pwd)\output"
          mkdir $destination
          $files = Get-ChildItem -Recurse -Include *.aab,*.apk
          foreach ($file in $files) {
            Copy-Item $file.FullName -Destination $destination -Force
          }

      - name: Upload final AAB and APK only
        uses: actions/upload-artifact@v4
        with:
          name: android-build
          path: output

🧠 Step 7: Understand What The Workflow Does

At a high level, the workflow breaks down into a small number of important phases.

1. Check out the repository
2. Install the correct .NET SDK
3. Install the MAUI workload️
4. Reconstruct the keystore from GitHub Secrets
5. Generate version numbers from the pipeline run
6. Publish the Android app
7. Collect the artifacts
8. Upload the build outputs

After the workflow completes, you can download the generated .aab and .apk directly from the GitHub Actions run.

➡️ Step 8: Run The Workflow

Push the workflow file to your repository, open the Actions tab in GitHub, and run the workflow manually.

Because the sample uses workflow_dispatch, this is a safe way to validate the pipeline before you attach it to push, pull_request, tags, or releases.

If the run succeeds, you should see an android-build artifact containing the final .aab and .apk files.

🚧 Common Issues To Watch For

Even a straightforward Android pipeline can fail in a few predictable ways.

Wrong Project Path

If PROJECT_PATH points to the wrong .csproj, restore or publish will fail immediately.

Incorrect Secret Values

If the keystore password, key password, or alias do not match the actual keystore, signing will fail during publish.

Missing MAUI Workload

If dotnet workload install maui is missing, the runner will not be able to publish the MAUI Android app correctly.

SDK Drift

If you do not pin the SDK through global.json, a runner image update can change your build behavior unexpectedly.

📱AAB Vs APK: Why Generate Both?

These outputs serve different use cases:

• .aab: the preferred format for Google Play publishing
• .apk: useful for direct installation, internal testing, and quick validation on devices

Generating both in CI gives you store-ready output and test-ready output from the same pipeline run.

🏁 Final Thoughts

The Android part of a .NET MAUI release pipeline does not need to be fragile. Once you standardize the keystore handling, GitHub secrets, SDK versioning, and dotnet publish command, the process becomes predictable and repeatable.

That is the real win. Not just automation, but confidence that every Android release is built the same way every time.

Y️ou can find a sample repository containing a simple .NET MAUI application on GitHub.

From Commit to AAB/APK: Automating .NET MAUI Android Builds with GitHub Actions was originally published in Medialesson on Medium, where people are continuing the conversation by highlighting and responding to this story.

The world of AI-powered image generation is evolving rapidly. With OpenAI announcing the deprecation of DALL·E 3 and the release of newer, more capable models like gpt-image-1, gpt-image-1-mini, and the newly introduced gpt-image-1.5, now is the perfect time to build a flexible and future-proof image generation solution.

In this blog post, I’ll walk you through building an interactive console application using .NET 10 that seamlessly integrates with both Azure OpenAI and OpenAI services. The application supports multiple image generation models — including gpt-image-1.5 — and allows customizable configurations so you can easily switch between providers and models as the ecosystem continues to evolve.

🚨 Important: DALL-E 3 Deprecation

Before we dive in, it’s crucial to understand that DALL-E 3 is now part of OpenAI’s deprecated models list. According to OpenAI’s deprecation timeline, DALL-E 3 will be phased out in the near future, with the recommended migration path being:

• gpt-image-1: The successor to DALL-E 3, offering high-quality image generation
• gpt-image-1-mini: A faster, more cost-effective alternative for less complex use cases
• gpt-image-1.5: The new flagship image generation model

This application is built with this transition in mind, supporting all three models and making it easy to adapt as the ecosystem evolves.

Project Overview

The Image Generation Console application is a terminal-based tool that:

• ✅ Supports both Azure OpenAI and OpenAI providers
• ✅ Works with DALL-E 3 (legacy), gpt-image-1, gpt-image-1-mini, and gpt-image-1.5
• ✅ Provides a beautiful, interactive UI using Spectre.Console
• ✅ Automatically saves generated images with timestamps
• ✅ Tracks generation performance for each model
• ✅ Handles errors gracefully with detailed feedback

Key Features Breakdown

Multi-Provider Support

One of the core features is the ability to seamlessly switch between Azure OpenAI and OpenAI:

string provider = ConsoleHelper.SelectFromOptions(
    [Providers.AzureOpenAI, Providers.OpenAI],
    Prompts.SelectProvider);

Azure OpenAI requires:

• Endpoint URL
• API Key
• Custom deployment names mapped to model types

OpenAI requires:

• API Key only
• Direct model selection from available options

Model-Specific Configuration

⚠️ Important Note: The model configurations in this application have been customized based on specific requirements and may differ from default SDK settings.

Here’s how different models are configured:

// DALL-E 3 (Deprecated)
ModelTypes.DallE3 => new()
{
  Size = GeneratedImageSize.W1792xH1024,
  Quality = GeneratedImageQuality.Standard,
  Style = GeneratedImageStyle.Vivid,
  ResponseFormat = GeneratedImageFormat.Uri
}

// gpt-image-1 (Recommended)
ModelTypes.GptImage1 => new()
{
  Size = GeneratedImageSize.W1536xH1024
}

// gpt-image-1-mini (Cost-Effective)
ModelTypes.GptImage1Mini => new()
{
  Size = GeneratedImageSize.W1536xH1024,
  Quality = GeneratedImageQuality.Medium
}

// gpt-image-1.5 (New Flagship)
ModelTypes.GptImage15 => new()
{
  Size = GeneratedImageSize.W1536xH1024
}

Note: These configurations have been modified from the default SDK settings to optimize for specific use cases. You may need to adjust them based on your requirements, budget, and quality expectations.

Enhanced User Experience

The application leverages Spectre.Console to provide:

• 🎨 Rich Colors and Markup: Yellow prompts, green success messages, red errors
• ⏳ Animated Spinners: Visual feedback during image generation
• 🔒 Masked Input: Secure API key entry with asterisks
• ✅ Multi-Selection: Choose multiple models with space bar
• 🔗 Clickable Links: Generated file paths are clickable in supported terminals

Robust Error Handling

The application handles various error scenarios gracefully:

catch (ClientResultException ex)
{
    ConsoleHelper.WriteError(
      string.Format(ErrorMessages.ApiError, modelKey, ex.Message));
    
    if (ex.Status == 401)
    {
        ConsoleHelper.WriteError(
          ErrorMessages.AuthenticationFailed);
    }
    else if (ex.Status == 429)
    {
        ConsoleHelper.WriteError(
          ErrorMessages.RateLimitExceeded);
    }
    else if (ex.Status == 404)
    {
        ConsoleHelper.WriteError(
          string.Format(ErrorMessages.ModelNotFound, deploymentName));
    }
}

Common error scenarios covered:

• 🔑 401 Unauthorized: Invalid API credentials
• ⏱️ 429 Rate Limit: Too many requests
• 🔍 404 Not Found: Invalid model or deployment name
• 🌐 Network Errors: Connection failures during download
• 💾 File System Errors: Permission or I/O issues

Performance Tracking

Each image generation is timed using Stopwatch:

var stopwatch = Stopwatch.StartNew();

ClientResult<GeneratedImage> imageResult =
    await imageClient.GenerateImageAsync(imagePrompt, options);

stopwatch.Stop();

ConsoleHelper.WriteMessage(
    string.Format(Messages.GenerationCompleted, 
    stopwatch.ElapsedMilliseconds, 
    stopwatch.Elapsed.TotalSeconds));

This helps users understand the performance characteristics of different models.

Working with Azure OpenAI Deployments

Azure OpenAI requires a unique approach with custom deployment names. The application handles this elegantly:

// User input format: "deploymentName:modelType"
// Example: "myDallE:dall-e-3,myGptImage:gpt-image-1"

string deploymentInput = ConsoleHelper.GetStringFromConsole(
    Prompts.EnterDeployments,
    validateLength: false,
    showHeader: false);

var deployments = 
  deploymentInput.Split(',', 
  StringSplitOptions.RemoveEmptyEntries | StringSplitOptions.TrimEntries);

This allows users to:

• Map their custom Azure deployment names to standard model types
• Use multiple deployments in a single session
• Maintain consistent configuration patterns

Image Output and Storage

Generated images are automatically saved to the system’s temporary directory with a timestamp-based naming convention:

var tempPath = Path.Combine(
    Path.GetTempPath(), 
    $"{modelName}_{DateTime.Now:yyyyMMdd_HHmmss}.png");

The application supports both:

• URL-based images: Downloaded via HTTP and saved locally
• Byte-based images: Direct binary data from the API

Console Application in Action

Main Menu

Azure OpenAI Configuration

Model Selection (OpenAI)

Image Generation Progress

Generation Results

Migration Strategy: From DALL-E 3 to New Models

Why Migrate?

1. Deprecation Timeline: DALL-E 3 will be phased out in May 2026
2. Better Performance: gpt-image-1 offers improved quality and consistency
3. Cost Efficiency: gpt-image-1-mini provides cheaper generations
4. Future-Proofing: Stay ahead of API changes

Migration Checklist

• ✅ Update your code to support gpt-image-1, gpt-image-1-mini, and gpt-image-1.5
• ✅ Test image quality across different models
• ✅ Adjust size and quality parameters as needed
• ✅ Update Azure OpenAI deployments to use new models
• ✅ Monitor costs and performance metrics
• ✅ Plan for eventual DALL-E 3 removal

Conclusion

Building a multi-model image generation console application is more than just integrating APIs — it’s about creating a robust, user-friendly tool that adapts to the evolving AI landscape. With DALL-E 3’s deprecation on the horizon, applications like this demonstrate how to build flexibility and future-proofing into your codebase.

Key takeaways:

• 🚀 Embrace Change: The AI ecosystem evolves quickly — build for adaptability
• 💡 User Experience Matters: Invest in good UX, even for console applications
• ⚠️ Error Handling is Critical: Graceful failure handling keeps users informed
• 🔧 Configuration Flexibility: Allow customization for different use cases
• 📈 Performance Monitoring: Track and display generation metrics

The complete source code is available on GitHub, and I encourage you to try it out, customize it for your needs, and contribute improvements!

Building a Multi-Model Image Generation Console App with Azure OpenAI and OpenAI was originally published in Medialesson on Medium, where people are continuing the conversation by highlighting and responding to this story.

Creating beautiful, responsive, cross-platform desktop applications has become easier than ever — thanks to frameworks like Avalonia UI. In this post, I’ll walk you through my latest project, AvaloniaWeather, a modern weather and air-quality desktop app built with .NET 10, MVVM, Dependency Injection, Localization, and my own NuGet package OpenWeatherMapSharp.

Whether you’re a .NET developer curious about Avalonia or someone looking for inspiration for a cross-platform desktop app, this article will give you a complete end-to-end overview of the architecture, technology choices, and features.

🖥️ What Is Avalonia UI, and Why Use It?

If you’ve ever wished for a true cross-platform WPF-like framework, Avalonia UI is the answer. Avalonia is an open-source, XAML-based UI framework that allows you to target: Windows, macOS, and Linux.

Avalonia uses a WPF-inspired layout system but is far more flexible and modern, offering responsive UI capabilities, GPU acceleration, and a clean MVVM-first development experience. With Avalonia, developers enjoy:

• A rich control set
• XAML-based layouts
• Full styling and theming support
• Strong community ecosystem
• Excellent tooling, including hot reload

For developers already familiar with WPF, MAUI, or UWP, Avalonia feels natural — while delivering true multi-platform desktop capability.

🎨 Modern UI Styling with Semi.Avalonia

To give AvaloniaWeather a modern, fluent, and polished appearance, the application uses Semi.Avalonia, a UI theme inspired by Fluent Design and Semi-UI.

Semi.Avalonia provides:

• Clean, modern controls
• Fluent-inspired transitions
• Better typography and spacing
• Dark and light themes
• Highly customizable styling layers

Combined with the Inter font and a shared style library, the result is a crisp and cohesive user experience that feels like a native desktop app, regardless of the operating system.

🌦️ Introducing AvaloniaWeather

AvaloniaWeather is a modern desktop application that displays:

• Current weather conditions
• 5-day / 3-hour interval forecast
• Current air quality (AQI + pollutant metrics)
• Air pollution forecast
• Unit selection (metric, imperial, standard)
• Localization (UI & data language)
• Configurable API key

Built on Avalonia and .NET 10, the app serves as both a real-world weather tool and a clean architectural template for creating modular, maintainable desktop applications.

🌐 Powered by OpenWeatherMapSharp

To retrieve weather and air-quality data, AvaloniaWeather uses OpenWeatherMapSharp, a NuGet package I created to simplify interacting with the OpenWeatherMap API.

It provides:

• Strongly typed DTOs
• Async methods
• Predictable error handling
• Modular service abstractions

This helps keep the service layer clean, testable, and easy to extend — not only for weather APIs but for any future provider you may want to plug in.

⚙️ Architecture Overview

A key goal of AvaloniaWeather is clean architecture, making it easy to understand, scale, and maintain. The project is split into logical layers:

🧩 Views

XAML-based UI definitions (Views/*.axaml), designed with Avalonia’s styling system and Semi.Avalonia theme controls.

🎛️ ViewModels

Implemented using CommunityToolkit.Mvvm, leveraging:

• Source-generated properties
• Relay commands
• Dependency injection support

This reduces boilerplate and keeps ViewModels expressive and lightweight.

🔌 Services & Interfaces

A dedicated service layer handles API calls and produces aggregated results (WeatherResult), with abstractions that allow future plug-in providers.

📦 Models

Lightweight data structures representing UI-ready weather and air-quality information.

🔄 Value Converters

Used for formatting, unit suffixes, color transformations (e.g., AQI → color), and other UI logic.

🌍 Localization

Based on .resx resources:

• Resources.resx (default)
• Resources.de-DE.resx (German)

UI strings and weather language selection work independently, allowing full flexibility for multilingual users.

🔑 Dependency Injection & .NET 10

Although the app keeps DI optional and minimal by default, the architecture supports expansion using: Microsoft.Extensions.DepenendyInjection

This makes AvaloniaWeather an excellent learning example for:

• .NET 10 SDK setup (via global.json)
• DI patterns
• MVVM workflows
• High-performance async operations
• Cross-platform desktop execution

🌍 Multi-Language Support (UI + Weather Data)

AvaloniaWeather supports:

• Localized UI strings
• Multi-language weather data

You can add new languages simply by:

1. Duplicating Resources.resx
2. Naming it Resources.<culture>.resx
3. Adding translations
4. Rebuilding the project

🚀 Getting Started (Developers)

1️⃣ Install .NET 10

Make sure your system matches the pinned version in global.json.

2️⃣ Clone the repository

git clone https://github.com/tsjdev-apps/weather-avalonia.git
cd weather-avalonia/src/AvaloniaWeather
dotnet restore

3️⃣ Build

dotnet build -c Release -f net10.0

4️⃣ Run

dotnet run -f net10.0

If your SDK doesn’t match, install the correct version from the official .NET download page.

📸 UI Highlights

🎉 Final Thoughts

AvaloniaWeather is more than a weather app — it’s a demonstration of what a modern, cross-platform .NET desktop application can look like when combining:

• Avalonia UI
• Semi.Avalonia
• MVVM + DI
• .NET 10
• Localization
• Strong service abstractions
• Clean UI architecture
• OpenWeatherMapSharp

If you want to explore Avalonia, build a cross-platform desktop tool, or create a real-world app integrating clean architecture principles, AvaloniaWeather is a great starting point. You can find the source code in my GitHub repository.

Building a Modern, Cross-Platform Weather App with Avalonia UI was originally published in Medialesson on Medium, where people are continuing the conversation by highlighting and responding to this story.