DEV Community: NuvyntraLabs

NuvLoc 1.1.2: The Agent Writes the Culture .resx. The CLI Checks It.

NuvyntraLabs — Fri, 25 Sep 2026 14:05:48 +0000

A translation vendor wants an API key. An IDE resource manager wants you to stay in that IDE. A MAUI app that already has an English .resx mostly needs to know which keys are missing in Spanish.

NuvLoc answers that question and hands the missing keys to the coding agent you already use. Version 1.1.2 of NuvyntraLabs.NuvLoc.Cli is on nuget.org. The agent writes AppResources.es.resx. The CLI never calls OpenAI, Azure, or any other translation API.

This post is the walkthrough: i18n.json, nuvloc init, the two slash commands, and the CI check that does not need an agent.

What NuvLoc is

NuvLoc is a global dotnet tool for sibling .resx hosts: MAUI, WPF, WinUI, Avalonia, and Uno. MIT licensed. The command is nuvloc. It is not a PackageReference, and it does not bind strings into XAML.


Package	`NuvyntraLabs.NuvLoc.Cli` 1.1.2
Config	`i18n.json` at the project root
Translate	`/nuvloc.translate` — there is no `nuvloc translate` command
Check	`nuvloc check --ci`
Source	github.com/nuvyntralabs/NuvLoc
Docs	nuvyntralabs.github.io/toolkits/nuvloc/

Coverage and placeholder checks prove that every key is present and that {0} still matches. They do not prove the sentence is right. Review every culture file with a native speaker before you ship.

Install and configure

dotnet tool install -g NuvyntraLabs.NuvLoc.Cli --source https://api.nuget.org/v3/index.json
nuvloc version

Put i18n.json next to the project. init checks this file. It does not create the host.

{
  "platform": "maui",
  "source": "Resources/Strings/AppResources.resx",
  "languages": ["es", "fr"]
}

platform is maui, wpf, winui, avalonia, or uno. source is the English .resx. Culture files are siblings: AppResources.es.resx beside AppResources.resx. WinUI and Uno PRI .resw folders under Strings/{lang}/ stay out of scope.

languages must be BCP-47. es, pt-BR, and zh-Hans are valid. Casing is canonicalized (PT-br becomes pt-BR). Underscores (es_MX), and English source tags (en, en-US, en-GB), are rejected. A bad code does not create a .resx. The CLI exits 2 and prints the reason.

These codes are tested: es, fr, de, it, nl, ja, ko, zh-Hans, pt-BR, ar, hi, ru. Other BCP-47 codes work the same way.

Init, then the agent

nuvloc init --configfile i18n.json --agent cursor

init checks the JSON, confirms the source file exists, and writes .nuvloc/ plus the agent skills. --force overwrites skill files. It does not overwrite a culture .resx. Omit --agent on an interactive terminal to pick from the same Spec Kit set Nuvyn uses (Cursor, GitHub Copilot, Claude Code, Gemini CLI, Codex, Windsurf, and others). --ci requires --agent.

In Cursor:

/nuvloc.status
/nuvloc.translate

/nuvloc.status runs nuvloc status and explains the counts. /nuvloc.translate runs nuvloc plan, writes the sibling culture files, then runs nuvloc check --write-cache.

A plan with gaps looks like this:

Source: Resources/Strings/AppResources.resx

es: 2 current, 1 missing, 0 stale, 0 placeholder, 0 extra
 missing ItemsLeft

fr: 0 current, 3 missing, 0 stale, 0 placeholder, 0 extra
 missing Save
 missing Cancel
 missing ItemsLeft

current means the key is present and the source hash still matches. stale means the English value changed after the culture file was written. placeholder means a format item does not match. extra means the culture file has a key the English source does not.

A second agent is nuvloc agent add copilot. nuvloc update refreshes skills and .nuvloc/reference/dotnet-resx.md and leaves i18n.json and the culture files alone.

CI without an agent

nuvloc check --configfile i18n.json --ci

Exit 0 means the configured cultures are complete. Exit 1 means a key is missing, stale, or a placeholder is broken. Exit 2 is usage: missing i18n.json, an unknown agent, a language that is not BCP-47, or --lang that is not listed in i18n.json.

--write-cache records source hashes for keys that are present, so the next run can tell stale from current. --ci forces JSON.

On an interactive terminal nuvloc asks every 4 hours whether to update from nuget.org. The cache file is ~/.nuvyntra/cli-updates.json, shared with maui-dev, nuvyn, maui-perf, and maui-pulse. Skip it with --no-update-check or NUVYNTRA_NO_UPDATE_CHECK=1. The CLI does not phone home.

When something looks wrong

What you see	What to do
Exit 2 on `es_MX`	Use a hyphen: `es-MX`. Underscores are rejected.
Exit 2 on `en-US` in `languages`	English is the `source` file. Do not list it as a target culture.
`/nuvloc.translate` is missing	Run `nuvloc init --agent cursor` in this repo. `init` installs the skill.
`nuvloc translate` fails	That command does not exist. Translation is the slash skill.
Check is green and the Spanish is wrong	Completeness passed. A native speaker still has to read the file.
You expected XAML to pick up the new culture	NuvLoc does not add a markup extension. The host binds `AppResources` the way it already does.

Where NuvLoc sits next to the other tools

Need	Tool
Diff sibling `.resx` files and let the agent fill the gaps	NuvLoc
An IDE resource editor or a translation vendor	ResXResourceManager, Crowdin, or Phrase
Doctor the MAUI project	MauiDev
Scaffold a new MAUI host	Nuvyn

Try it

dotnet tool install -g NuvyntraLabs.NuvLoc.Cli --source https://api.nuget.org/v3/index.json
nuvloc init --configfile i18n.json --agent cursor
nuvloc status --configfile i18n.json

Then run /nuvloc.translate, and have a native speaker read AppResources.es.resx before the check in CI is the only review it gets.

NuGet: NuvyntraLabs.NuvLoc.Cli
Repository: github.com/nuvyntralabs/NuvLoc
Sample: samples/NuvLocSample
Toolkit page: nuvyntralabs.github.io/toolkits/nuvloc/

By Niladri

Pulse 1.0.1: Nine Lanes for the Plugins the App Already Registered

NuvyntraLabs — Fri, 25 Sep 2026 14:05:23 +0000

A field app fails in the yard and the log is a wall of framework noise. The useful line is the one the app already raised: captive portal, a failed job, a sync conflict.

Pulse shows those lines in a nine-lane table while the session is still running. Version 1.0.1 ships as two packages at the same version. The host listens. The CLI draws.

This post is the walkthrough: UseMauiPulse(), maui-pulse attach, and how to read a quiet row.

What Pulse is

Plugin.Maui.Pulse is a Debug sink inside the MAUI app. UseMauiPulse() finds allow-listed plugins that are already in dependency injection, stays subscribed to their events, and POSTs JSON to the development machine.

Plugin.Maui.Pulse.Cli is the global tool. maui-pulse attach listens on port 7878 and draws the table. The person using the app does not tap anything for Pulse.


Host	`Plugin.Maui.Pulse` 1.0.1
CLI	`Plugin.Maui.Pulse.Cli` 1.0.1
Command	`maui-pulse attach`
Endpoint	`http://127.0.0.1:7878/` (emulator: `10.0.2.2`)
Source	github.com/nuvyntralabs/MauiPulse
Docs	nuvyntralabs.github.io/toolkits/maui-pulse/

Pulse does not scrape logcat, Charles, Firebase, Sentry, or MAUI Connectivity. Unknown sources are dropped. It does not start a plugin, and it does not invent a row from the operating system when a package is missing.

Register the host

Add the host package to the app. Install the CLI on the machine. Do not add Plugin.Maui.Pulse.Cli as a PackageReference.

dotnet add package Plugin.Maui.Pulse --version 1.0.1
dotnet tool install -g Plugin.Maui.Pulse.Cli --source https://api.nuget.org/v3/index.json

builder
    .UseMauiApp<App>()
    .UseMauiPulse();

UseMauiPulse() only registers services. After Build(), the initializer resolves the package name (AppInfo.PackageName unless you set Package), opens the sink, walks the allow-list, and subscribes to instances already in DI. A plugin registered after that pass is missed.

Release builds set Enabled to false before your callback. Set options.Enabled = true only when you intend the sink to run in Release. A closed CLI does not crash the host: the POST times out in 3 seconds and the error is swallowed.

The app still registers the plugins it already uses. Pulse only listens.

Attach

USB Android needs a reverse before the phone can reach the CLI:

adb reverse tcp:7878 tcp:7878
maui-pulse attach --package com.myapp.android --android --port 7878

iOS:

maui-pulse attach --package com.myapp.ios --ios --port 7878

Every session command requires --package (one Android application id or one iOS bundle id). attach and listen also require --android or --ios. JSON for a different package is dropped. Two apps need two Pulse windows.

maui-pulse 1.0.1  attach  com.myapp.android  android  :7878
session 8f2a

NETWORK   Plugin.Maui.NetworkMonitor      captive portal
API       Plugin.Maui.NetworkDiagnostics  —
QUEUE     Plugin.Maui.JobQueue            visits#184
          Plugin.Maui.RetryQueue          — not installed
SYNC      Plugin.Maui.OfflineSync         conflict on Visit
PERMS     Plugin.Maui.PermissionFlow      —
HEALTH    Plugin.Maui.AppHealth           battery 18%
LEAK      Plugin.Maui.LeakAnalyser        —
CRASH     Plugin.Maui.Diagnostics         —
SESSION   Plugin.Maui.DeviceSession       session 8f2a

Row	Meaning
A headline (`captive portal`, `visits#184`)	At least one allow-listed event arrived
`—`	Subscribed, waiting. This is not a failure
`— not installed`	The assembly is not loaded
`— not registered`	The package is referenced and `UseX()` / `AddX()` was not called

--lanes network,sync,queue hides rows. It does not add plugins to the allow-list. GeoLocator, PushRouter, SmartUpload, and every other package are never a lane.

The nine lanes, and the registration Pulse looks for:

Lane	Package	Register
NETWORK	NetworkMonitor	`AddNetworkMonitor`
API	NetworkDiagnostics	`UseNetworkDiagnostics`
QUEUE	JobQueue, and RetryQueue on its own row	`UseMauiJobQueue`, `UseMauiRetryQueue`
SYNC	OfflineSync	`UseOfflineSync`
PERMS	PermissionFlow	`UsePermissionFlow`
HEALTH	AppHealth	`UseAppHealth`
LEAK	LeakAnalyser	`UseLeakAnalyser`
CRASH	Diagnostics	`UseMauiDiagnostics`
SESSION	DeviceSession	`UseDeviceSession`

QUEUE is two plugins. JobQueue alone is a valid session. RetryQueue then shows — not installed.

After the session

maui-pulse listen is the same HTTP sink with no table. GET / returns { "ok": true, "tool": "maui-pulse" }. --stdin accepts one JSON payload for a test or an agent.

Live events are optional for the file lanes. Copy the known files off the device, then inspect them. pull copies from a folder you already have. --adb only prints how to copy. It does not scrape logcat, and logcat.txt in that folder is ignored.

maui-pulse pull --package com.myapp.android --from ./device-files --out ./pulled
maui-pulse queues --package com.myapp.android --from ./pulled
maui-pulse sync --package com.myapp.android --from ./pulled
maui-pulse incident --package com.myapp.android --from ./pulled --out incident.zip

Known names: plugin.maui.jobqueue.db3, plugin.maui.retryqueue.db3, offlinesync.db3, and maui-diagnostics/. queues and sync are read-only. They do not drain a queue or retry a row. incident zips the allow-listed files plus manifest.json.

Exit 0 includes skipped lanes and missing queue files. Exit 1 means no allow-listed evidence or the port bind failed. Exit 2 is usage.

On an interactive terminal the CLI asks every 4 hours whether to update from nuget.org. Skip it with --no-update-check or NUVYNTRA_NO_UPDATE_CHECK=1. CI, --format json, and piped output skip the prompt. The CLI does not phone home.

When something looks wrong

What you see	What to do
Every lane is `— not installed`	Those packages are not in this app. Pulse will not fill the lane from the OS.
`— not registered`	The assembly loaded. Call the plugin's `UseX()` before the app finishes starting.
The table stays empty and the phone is on USB	Run `adb reverse tcp:7878 tcp:7878` again after unplug.
A plugin you added at runtime never appears	Bind runs once at startup. Register it in `MauiProgram`.
Release is silent	`Enabled` is false unless you set `options.Enabled = true`.
Sentry or logcat lines never show up	They are dropped. Pulse renders the nine lanes only.

Plugin.Maui.Observability can POST at the same port. It is a pipe, not a tenth lane. Domains other than Network, Health, Sync, and Session are dropped.

Where Pulse sits next to the other tools

Need	Tool
What the allow-listed plugins are doing in this Debug session	Pulse
SDK, workloads, and the csproj	maui-dev doctor
Startup and page traces	Plugin.Maui.Performance / `maui-perf`
An exporter the app owns	Plugin.Maui.Observability

adb logcat, Charles, Firebase Performance, and Sentry remain the tools for raw logs, HTTP, and a report that arrives after the session. Pulse is the table for the plugins you already registered.

Try it

dotnet add package Plugin.Maui.Pulse --version 1.0.1
dotnet tool install -g Plugin.Maui.Pulse.Cli --source https://api.nuget.org/v3/index.json
adb reverse tcp:7878 tcp:7878
maui-pulse attach --package com.myapp.android --android --port 7878

Call UseMauiPulse(), keep the UseX() lines you already have, and read a — as waiting.

Host: Plugin.Maui.Pulse
CLI: Plugin.Maui.Pulse.Cli
Repository: github.com/nuvyntralabs/MauiPulse
Toolkit page: nuvyntralabs.github.io/toolkits/maui-pulse/

By Niladri

Lock the Device, Not the Page: App Lock, Biometric, Screen Guard, and the Vault

NuvyntraLabs — Fri, 25 Sep 2026 14:04:32 +0000

A banking screen that hides itself with IsVisible is still in the recents thumbnail. A Face ID call on one button does not lock the app two minutes after the user switches to Messages. A token in Preferences is not a file in a vault.

Each of those is a different package. This post wires the five that cover the device: the lock timer, a one-shot prompt, the screenshot flag, small secrets, and encrypted files.

Job	Package	Version
Background, timer, cover, unlock	`Plugin.Maui.AppLock`	1.0.7
One Face ID, fingerprint, or device PIN prompt	`Plugin.Maui.BiometricPlus`	1.0.1
Recents thumbnail and screenshots	`Plugin.Maui.ScreenGuard`	1.0.1
A short secret with expiry	`Plugin.Maui.SecureStoragePlus`	1.0.8
An encrypted file	`Plugin.Maui.FileVault`	1.0.8

All five are MIT licensed. AppLock, BiometricPlus, ScreenGuard, and FileVault target Android and iOS. SecureStoragePlus also targets Mac Catalyst and Windows. Access and refresh tokens, 401 refresh, and multi-device revoke stay on Plugin.Maui.SecureSession. SecureSession persists through SecureStoragePlus. It is not a second lock timer.

The timer and the cover

AppLock owns the sequence: the app backgrounds, LockAfter elapses, the app returns, the user authenticates, the app unlocks. Face ID and the device PIN are the unlock step.

dotnet add package Plugin.Maui.AppLock --version 1.0.7

using Plugin.Maui.AppLock;

builder
    .UseMauiApp<App>()
    .UseAppLock(options =>
    {
        options.LockAfter = TimeSpan.FromMinutes(2);
        options.AllowBiometric = true;
        options.AllowDevicePin = true;
        options.AutoPromptOnResume = true;
    });

TimeSpan.Zero locks as soon as the app backgrounds. LockOnStart = true also starts locked after a cold start. UseAppLock hooks Android pause/resume and iOS background/activate. Without the generic host, call NotifyBackground() and NotifyForeground() yourself.

Swap the window to a cover while the app is locked:

appLock.StateChanged += (_, e) =>
{
    window.Page = e.Current is AppLockState.Locked or AppLockState.Authenticating
        ? new AppLockPage(appLock)
        : mainPage;
};

RequireAuthenticationAsync() is the gate before the app is usable. A balance screen that must prompt even when the timer has not elapsed uses AppLockPromptMode.Always:

var result = await AppLock.RequireAuthenticationAsync(AppLockPromptMode.Always);
if (!result.Succeeded)
    return;

ShowBalance();

A failed or cancelled prompt returns AppLockAuthResult and leaves the app locked. It does not throw. If the automatic resume prompt throws, AuthenticationCompleted still fires with a failed result so the cover stays up.

Android API 23+. USE_BIOMETRIC is merged from the package. Enroll a fingerprint, face, or device PIN before you test. When AllowDevicePin is true, the system prompt includes the device credential. iOS needs NSFaceIDUsageDescription when biometrics are allowed. AllowDevicePin uses LAPolicy.DeviceOwnerAuthentication.

samples/Plugin.Maui.AppLock.Sample is a small vault: enable the lock, change the grace period, lock now, and step up on "View balance".

One prompt, without a timer

BiometricPlus answers a single question: is this the enrolled user, right now? The NuGet id is Plugin.Maui.BiometricPlus because nuget.org already reserved Plugin.Maui.Biometric. The namespace stays Plugin.Maui.Biometric.

dotnet add package Plugin.Maui.BiometricPlus --version 1.0.1

using Plugin.Maui.Biometric;

builder.UseBiometric(o =>
{
    o.AllowDeviceCredential = true;
    o.DefaultReason = "Unlock";
});

var availability = await Biometric.Current.GetAvailabilityAsync();
var result = await Biometric.Current.AuthenticateAsync(
    new BiometricRequest { Reason = "Unlock payroll" });

GetAvailabilityAsync returns Available, NotEnrolled, or NotSupported. Android uses AndroidX BiometricPrompt (API 23+). Declare USE_BIOMETRIC and USE_FINGERPRINT on the host. iOS uses LAContext. Face ID needs NSFaceIDUsageDescription. Touch ID and the device passcode do not.

Use this package for a button. Use AppLock when the whole window has to disappear after background.

The recents thumbnail

ScreenGuard is the window flag. It is not the lock, and it is not file encryption.

dotnet add package Plugin.Maui.ScreenGuard --version 1.0.1

using Plugin.Maui.ScreenGuard;

builder.UseScreenGuard(o => o.ProtectOnStart = false);

ScreenGuard.SetProtected(balancePage, true);

Protect and Unprotect are reference-counted. SetProtected(page, true) ties a hold to one page. Android sets FLAG_SECURE: the recents thumbnail is blank, and screenshots are blocked. No extra manifest permission.

iOS cannot block a screenshot. The plugin raises CaptureStateChanged and exposes IsCaptured while the screen is recorded. The host supplies the overlay. Treat an iOS "blocked screenshot" as a bug in the write-up, not a feature of this package.

The short secret

SecureStoragePlus sits on MAUI SecureStorage (Keychain, EncryptedSharedPreferences) and adds an AES-256-GCM envelope. The key name is associated data, so a blob cannot be copied under another name. Values can expire. The ciphertext is what gets stored.

dotnet add package Plugin.Maui.SecureStoragePlus --version 1.0.8

builder.UseSecureStoragePlus();

await SecureStoragePlus.Default.SetAsync(
    "session",
    sessionJson,
    SecureStorageOptions.ExpireIn(TimeSpan.FromHours(8)));

var result = await SecureStoragePlus.Default.TryGetAsync("session");
if (result.Expired)
{
    // sign in again
}

GetAsync on an expired key returns null and removes the value. Strings are stored as-is. Other types are JSON:

await SecureStoragePlus.Default.SetAsync("profile", new UserProfile("Ada", 36));
var profile = await SecureStoragePlus.Default.GetAsync<UserProfile>("profile");

After an upgrade, copy named keys out of MAUI SecureStorage once:

await SecureStoragePlus.Default.MigrateFromMauiSecureStorageAsync(
    ["oauth_token", "refresh_token"],
    new MigrationOptions
    {
        RemoveSource = true,
        OverwriteExisting = false,
        StorageOptions = SecureStorageOptions.ExpireIn(TimeSpan.FromDays(14))
    });

On iOS, add a keychain access group for $(AppIdentifierPrefix)$(CFBundleIdentifier) so values survive the way you expect. On Android, if Auto Backup restores preferences onto a device that does not have the original key, catch the failed read and call RemoveAllAsync(resetEncryptionKey: true).

A secret that is a file, not a string, belongs in FileVault.

The file

FileVault stores app-private files as AES-256-GCM ciphertext. The master key lives in the platform secure store. Each file has its own nonce.

dotnet add package Plugin.Maui.FileVault --version 1.0.8

using Plugin.Maui.FileVault;

builder.UseFileVault(options =>
{
    options.DefaultTimeToLive = TimeSpan.FromDays(30);
    options.LockOnBackground = true;
    options.ExcludeFromBackup = true;
});

await FileVault.Current.WriteTextAsync("notes/pin.txt", "1234", new VaultWriteOptions
{
    TimeToLive = TimeSpan.FromHours(12)
});

var pin = await FileVault.Current.ReadTextAsync("notes/pin.txt");
var stats = await FileVault.Current.GetStatisticsAsync();

Device-key vaults unlock on first use. RequirePassphrase = true keeps the vault locked until UnlockAsync. ChangePassphraseAsync rewraps the key. It does not re-encrypt every file.

UseFileVault purges expired and idle files on resume. On background, when LockOnBackground is true, the vault locks. The in-memory master key is cleared either way. Reading an expired file deletes it and throws FileVaultException with FileVaultError.Expired.

RootDirectory must stay inside the host-chosen folder. VaultName cannot climb out with ... DestroyAsync deletes the files, the manifest, and the stored key. Prefer GetStatisticsAsync. The synchronous GetStatistics() gives up after 5 seconds if a write holds the gate.

VideoPipeline Encrypt(key) writes its own AES-256-GCM .vault for one clip. FileVault is the store for documents that outlive that call, with a TTL and a lock when the app backgrounds.

When something looks wrong

What you see	What to do
The app switcher still shows the balance	`LockAfter` is still the default grace, or ScreenGuard is not protecting that window. `LockAfter = TimeSpan.Zero` locks immediately. `FLAG_SECURE` blanks the Android thumbnail.
Face ID works on a button and the app stays open after background	That button is BiometricPlus. The timer and the cover are AppLock.
iOS screenshots still save	ScreenGuard does not block them. Handle `CaptureStateChanged` and show your own overlay.
A session token is still readable after eight hours	It was written without `SecureStorageOptions.ExpireIn`. Expiry is checked on the next read.
A note file opens with no passphrase after background	`LockOnBackground` is false, or this vault is device-key and unlocks on first use. Set `RequirePassphrase` when the key must not sit in `SecureStorage`.
Tokens refresh themselves	That is SecureSession, composed on SecureStoragePlus. AppLock does not store access tokens.

Where the five sit next to each other

Need	Tool
Hide the app after it backgrounds, then unlock	AppLock
One prompt on one action	BiometricPlus
Blank recents, block Android screenshots	ScreenGuard
Expire a string in the platform secure store	SecureStoragePlus
Encrypt a file, with TTL and lock	FileVault
Login, refresh, logout, biometric unlock of the session	Plugin.Maui.SecureSession

Plugin.Fingerprint and similar biometric libraries are the usual one-shot prompt when the app already uses them. MAUI SecureStorage is enough when you do not need expiry, listing, or the extra AES-256-GCM envelope.

Try it

Register AppLock with a two-minute LockAfter, put AppLockPage up while StateChanged says Locked, and call ScreenGuard.SetProtected on the balance page. Put the session string in SecureStoragePlus with an expiry. Put the document in FileVault.

AppLock: nuget.org · GitHub · package page
BiometricPlus: nuget.org · GitHub · package page
ScreenGuard: nuget.org · GitHub · package page
SecureStoragePlus: nuget.org · GitHub · package page
FileVault: nuget.org · GitHub · package page

By Niladri

GeoLocator 1.0.8: One Fix, a Tracking Session, and a Reverse Geocode

NuvyntraLabs — Fri, 25 Sep 2026 14:03:58 +0000

A field form needs the yard the technician is standing in. A trip screen needs the next fix every few seconds. A label under the pin needs a street, not a pair of numbers.

Plugin.Maui.GeoLocator is those three calls. Version 1.0.8 is on nuget.org. Android and iOS share IGeoLocator. Mac Catalyst and Windows are not primary targets.

This post is the walkthrough: a single fix, a tracking session, reverse geocoding, and the permissions the host still declares.

What GeoLocator is

GeoLocator is a location plugin for .NET MAUI. MIT licensed. It targets net10.0, net10.0-android (API 21+), and net10.0-ios (15+). On net10.0 the location APIs throw GeoLocatorException with FeatureNotSupported, so shared projects can reference the package.

It does one job: return a position, stream positions until you stop, and turn a coordinate into an address.


Package	`Plugin.Maui.GeoLocator` 1.0.8
Registration	`UseGeoLocator`
Client	`IGeoLocator`, or `GeoLocator.Current`
Source	github.com/nuvyntralabs/Plugin.Maui.GeoLocator
Docs	nuvyntralabs.github.io/packages/plugin-maui-geolocator/

Enter, exit, and dwell for a circular region stay on Plugin.Maui.Geofence. GeoLocator does not draw a map.

Install and register

dotnet add package Plugin.Maui.GeoLocator --version 1.0.8

builder
    .UseMauiApp<App>()
    .UseGeoLocator(options =>
    {
        options.EnableLogging = true;
    });

Resolve IGeoLocator from dependency injection, or use GeoLocator.Current. When EnableLogging is true and the host registered a logger (builder.Logging.AddDebug()), the plugin writes through ILogger. You can also call EnableLogging(true), pass a DebugGeoLocatorLogger, or turn it off with EnableLogging(false).

The plugin requests when-in-use location at runtime. Declare the usage strings yourself.

Android, in Platforms/Android/AndroidManifest.xml:

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

iOS, in Platforms/iOS/Info.plist:

<key>NSLocationWhenInUseUsageDescription</key>
<string>This app needs your location to show where you are.</string>

One fix

var location = await GeoLocator.Current.GetCurrentLocationAsync(new LocationRequest
{
    Accuracy = LocationAccuracy.Best,
    Timeout = TimeSpan.FromSeconds(20)
});

The last cached fix, when the platform still has one:

var last = await GeoLocator.Current.GetLastKnownLocationAsync();

GetCurrentLocationAsync waits for a new reading. GetLastKnownLocationAsync returns what the device already stored. A form that must open offline can show the cached fix first and replace it when the new one arrives.

A tracking session

Tracking is a session you start and stop. It is built for the foreground.

var locator = GeoLocator.Current;

locator.LocationChanged += (_, e) =>
{
    var position = e.Location;
};

locator.LocationError += (_, e) =>
{
    Console.WriteLine(e.Message);
};

await locator.StartTrackingAsync(new TrackingOptions
{
    Accuracy = LocationAccuracy.High,
    MinimumTime = TimeSpan.FromSeconds(2),
    MinimumDistanceMeters = 5
});

await locator.StopTrackingAsync();

MinimumTime and MinimumDistanceMeters drop fixes that arrive too soon or too close. Subscribe to LocationChanged and LocationError before StartTrackingAsync.

Background tracking is a host concern. On Android it needs a foreground service in the app. On iOS it needs AllowBackgroundUpdates = true, always-authorization text, and the location background mode. The plugin does not add that service for you.

Reverse geocoding

var addresses = await GeoLocator.Current.ReverseGeocodeAsync(
    latitude: 47.6062,
    longitude: -122.3321);

foreach (var address in addresses)
    Console.WriteLine(address.FormattedAddress);

Pass the latitude and longitude you already have. The call does not start a tracking session.

When something looks wrong

What you see	What to do
`GeoLocatorException` / `FeatureNotSupported`	The call ran on `net10.0` or a target that is not Android or iOS.
The prompt never appears	The manifest or `Info.plist` usage string is missing. The plugin requests when-in-use. It does not add the declaration.
`GetCurrentLocationAsync` times out	Accuracy is `Best` indoors, or location is off on the device. Try the last known fix, then a longer `Timeout`.
Fixes arrive after `StopTrackingAsync`	The handler is still attached. Unsubscribe when the page goes away.
The trace dies when the screen locks	Foreground tracking stopped with the process. Background needs the host service on Android, or `AllowBackgroundUpdates` plus the location background mode on iOS.
You wanted "entered the depot"	That is a region. Use Geofence. GeoLocator answers where the device is.

Where GeoLocator sits next to the other tools

Need	Tool
A current fix, a tracking session, reverse geocoding	GeoLocator — `Plugin.Maui.GeoLocator`
Enter, exit, and dwell for up to 20 circles	Plugin.Maui.Geofence
A measured offline trip against a vehicle meter	GPSSensorTrackingService
One fix and nothing else	.NET MAUI `Geolocation` already does that

MAUI Geolocation and the older Xamarin.Essentials API cover an on-demand fix. GeoLocator is the client when the same type also has to start and stop a session and reverse geocode. A hosted map (Google Maps, Mapbox) is still a separate SDK.

Try it

dotnet add package Plugin.Maui.GeoLocator --version 1.0.8

Register UseGeoLocator, declare when-in-use location, and call GetCurrentLocationAsync once before you start a session. samples/GeoLocator.Sample exercises the fix, the cache, tracking, and reverse geocoding.

NuGet: Plugin.Maui.GeoLocator
Repository: github.com/nuvyntralabs/Plugin.Maui.GeoLocator
Sample: GeoLocator.Sample
Package page: nuvyntralabs.github.io/packages/plugin-maui-geolocator/

By Niladri

MauiDev 1.2.2: What maui-dev doctor Checks, and What --fix Will Touch

NuvyntraLabs — Fri, 25 Sep 2026 14:03:24 +0000

A MAUI app that fails to build is often a machine problem and a project problem at the same time. The SDK is present. <UseMaui> is missing. Three splash entries point at the same file.

maui-dev doctor reads both. Version 1.2.2 of Plugin.Maui.MauiDev.Cli is on nuget.org. It is a global dotnet tool. It is not a PackageReference in the app.

This post is the walkthrough: install the tool, run doctor, and which two edits --fix is allowed to make.

What doctor is

MauiDev is project-aware. maui-check stops at the environment. dotnet workload and the Microsoft maui CLI install or list SDKs. Doctor also opens the csproj, the manifests, and the MAUI resource items.


Package	`Plugin.Maui.MauiDev.Cli` 1.2.2
Command	`maui-dev doctor`
Extension	`nuvyntralabs.maui-dev` (VS Code / Cursor 1.90+)
Source	github.com/nuvyntralabs/MauiDev
Docs	nuvyntralabs.github.io/toolkits/maui-dev/

nuget.org reserved the id MauiDev.Cli. The package id is Plugin.Maui.MauiDev.Cli. The command stays maui-dev.

Install

dotnet tool install -g Plugin.Maui.MauiDev.Cli --source https://api.nuget.org/v3/index.json
maui-dev doctor

Do not run dotnet add package Plugin.Maui.MauiDev.Cli in the app. The VS Code / Cursor extension shells out to the same command and offers to install the tool when it is missing.

On an interactive terminal the CLI asks every 4 hours whether to update from nuget.org ([y/N], default no). The answer is cached in ~/.nuvyntra/cli-updates.json. Skip the prompt with --no-update-check, NUVYNTRA_NO_UPDATE_CHECK=1, or any --ci / JSON / SARIF run. --no-update-check shipped in 1.2.2. The CLI does not phone home.

What the report covers

Point --path at the app when the repo root is not the csproj.

maui-dev doctor --path ./src/App

The machine section covers the .NET SDK, the MAUI workload, the Android SDK, the JDK, Xcode, and CocoaPods. A check that does not apply on the current OS is skipped.

The project section covers target frameworks, Android min SDK, permissions, duplicate resources, <UseMaui>, and signing.

.NET MAUI Developer Doctor
────────────────────────────────────

Machine
────────────────────────────────────

✓ .NET SDK               10.0.102
✓ MAUI workload          maui 10.0.0
✓ Android SDK            ANDROID_HOME set
✓ JDK                    17.0.12
· Xcode                  skipped (Linux)
· CocoaPods              skipped (Linux)

Project
────────────────────────────────────

✗ UseMaui                missing <UseMaui>true</UseMaui>
✗ Duplicate resources    3 detected
⚠ Android min SDK        21 (recommend 24+)

Exit 0 is pass or skip. Exit 1 is a failure, or a warning when --warn-as-error or --ci is set. Exit 2 is a usage error.

The two edits --fix may make

--fix on doctor does two things:

Insert <UseMaui>true</UseMaui> when the project already looks like MAUI.
Deduplicate identical MauiSplashScreen, MauiImage, MauiIcon, and MauiFont items.

Run the dry run first.

maui-dev doctor --fix --dry-run
maui-dev doctor --fix

Doctor will not bump the min SDK, remove a permission, write a keystore password, install a workload, rewrite a TFM, or push a package. A missing workload is reported. The install command is dotnet workload install maui, and doctor does not run it. maui-dev workload prints that command. It does not install either.

CI

--ci emits JSON and treats warnings as errors.

- script: maui-dev doctor --ci

A failing resource check looks like this:

{
  "id": "maui-resources",
  "title": "Duplicate resources",
  "category": "project",
  "status": "fail",
  "detail": "3 detected",
  "recommendation": "Remove duplicate MauiSplashScreen entries.",
  "canFix": true,
  "diagnostics": [
    {
      "id": "MD030",
      "message": "Duplicate MauiSplashScreen 'Resources/Splash/splash.svg'",
      "file": "App.csproj",
      "line": 12,
      "severity": "fail"
    }
  ]
}

--format sarif feeds the IDE Problems panel. .maui-dev.json can ignore a diagnostic id such as MD020 or a check id.

When something looks wrong

What you see	What to do
`maui-dev: command not found`	The global tool is not on `PATH`. Reinstall `Plugin.Maui.MauiDev.Cli`.
`--no-update-check` is an unknown option	The installed tool is 1.2.1 or older. Update to 1.2.2.
`--fix` left the min SDK at 21	That warning is a recommendation. Doctor does not rewrite min SDK.
Duplicate permissions are still there	Doctor does not dedupe permissions. `maui-dev permissions --fix` dedupes identical Android `UsesPermission` nodes and never removes one.
The app still crashes on device	Doctor reads the project. Leaks, traces, and crashes stay on the runtime plugins below.

Where doctor sits next to the other tools

Need	Tool
Machine and project checks, with a two-item fix list	maui-dev doctor
Event handlers, `new HttpClient()`, fire-and-forget	`maui-dev analyze` (heuristic, not a Roslyn analyzer)
Store ids and the iOS privacy manifest	`maui-dev publish --validate` (never pushes)
A page still alive after you pop it	Plugin.Maui.LeakAnalyser
Live plugin lanes during a Debug session	Pulse

Try it

dotnet tool install -g Plugin.Maui.MauiDev.Cli --source https://api.nuget.org/v3/index.json
maui-dev doctor --path ./src/App --fix --dry-run

Read the dry run before you let --fix insert <UseMaui> or drop a duplicate splash item.

NuGet: Plugin.Maui.MauiDev.Cli
Repository: github.com/nuvyntralabs/MauiDev
Toolkit page: nuvyntralabs.github.io/toolkits/maui-dev/

By Niladri

Understanding System Design as a .NET/MAUI Engineer

NuvyntraLabs — Fri, 25 Sep 2026 13:02:18 +0000

System design is often associated with architects and technical interviews. But every .NET or .NET MAUI developer makes system-design decisions—even when building a small application.

The difference is how far you think beyond your code.

A developer asks:

How do I implement this feature?

A senior developer asks:

How should this feature interact with the rest of the application?

An architect asks:

How will the system behave when users, data, traffic, and failures increase?

That is the journey into system design.

What Is System Design?

System design defines how different components work together to satisfy both functional and non-functional requirements.

A simple application:

.NET MAUI
    |
    v
ASP.NET Core API
    |
    v
SQL Server

A larger system may look like:

.NET MAUI
    |
API Gateway
    |
 ┌──┴──────────┐
 |             |
Services     Services
 |             |
 └──────┬──────┘
        |
   Database / Cache
        |
      Queue
        |
    Background
     Workers

The important part isn't drawing these boxes. It's understanding why they exist and what happens when they fail.

System Design at Different Levels

Beginner

Focus on:

Client/server architecture
HTTP/HTTPS
REST APIs
Authentication
Databases
Dependency Injection

Understand how your MAUI application communicates with the backend.

Intermediate

Start thinking about:

Caching
API scalability
Background processing
Retry and timeout
Logging
API versioning
Message queues
Database indexes

Senior

Think about:

Scalability
Reliability
Data consistency
Security
Offline support
Observability
Failure handling
Cloud architecture

Architect

Think about the complete system:

Availability
Disaster recovery
Cost
Security
Compliance
Infrastructure
Integration
Long-term maintainability
Architectural trade-offs

System Design for .NET MAUI

Mobile applications introduce additional challenges.

A MAUI application may encounter:

No network
Slow connectivity
Application termination
Background restrictions
Token expiration
Device storage limitations
Different OS behavior

A production mobile architecture might therefore look like:

             .NET MAUI
                 |
       ┌─────────┴─────────┐
       |                   |
   Local SQLite        API Client
       |                   |
       └──── Sync ─────────┘
                 |
              Backend
                 |
        ┌────────┼────────┐
        |        |        |
      API      Cache    Queue
        |                 |
     Database          Workers

Now you're dealing with mobile system design, not just UI architecture.

Offline-First Is System Design

Suppose a salesperson creates a customer while offline.

The application may store the data locally and synchronize it later.

But what happens if another device modified the same customer?

You now need a conflict strategy:

Last-write-wins
Version numbers
Server-authoritative data
Conflict detection
Manual resolution

These are system-design decisions.

Reliability Matters

Production systems assume that things will fail.

A database can become unavailable.
An API can timeout.
A third-party service can fail.
A mobile device can lose connectivity.

Common techniques include:

Timeouts — don't wait forever.

Retries — recover from transient failures.

Circuit breakers — stop repeatedly calling an unhealthy dependency.

Idempotency — prevent duplicate operations when requests are retried.

For example:

Mobile App
    |
    v
API
    |
    v
Queue
    |
    v
Background Worker

Not every operation needs to happen synchronously.

Scalability

If your application grows from 1,000 to 100,000 users, architecture becomes important.

Vertical scaling

Small Server
     ↓
Bigger Server

Horizontal scaling

        Load Balancer
        /     |     \
     API1   API2   API3

Understanding when and why to use these approaches is part of system design.

Database Design

Don't simply ask:

SQL or NoSQL?

Instead ask:

What data do we have?
How are entities related?
How much data will exist?
What consistency is required?
What queries will be frequent?
How fast must they be?

Also understand:

Indexes
Transactions
Replication
Partitioning
Query performance

Microservices Are Not Mandatory

Modern architecture doesn't automatically mean microservices.

A modular monolith can be perfectly appropriate:

ASP.NET Core
├── Identity
├── Customers
├── Orders
├── Payments
└── Notifications

If there is a strong reason later, individual modules can become services.

Architecture should follow requirements—not trends.

Observability

A production system should tell you what is happening.

Logs

What happened?

Metrics

How often and how much?

Traces

Where did the request spend its time?

For distributed systems, observability is essential for troubleshooting performance and failures.

A Simple System Design Process

When designing a system:

1. Understand requirements
          ↓
2. Estimate scale
          ↓
3. Design high-level architecture
          ↓
4. Design data model
          ↓
5. Identify failure scenarios
          ↓
6. Plan scalability
          ↓
7. Address security
          ↓
8. Add observability
          ↓
9. Evaluate trade-offs

Always ask:

What happens if this component fails?

What happens if traffic increases 10×?

What happens if the request is sent twice?

What happens when the device is offline?

Final Thoughts

System design isn't about memorizing Azure services, drawing complicated diagrams, or building microservices everywhere.

It is about thinking beyond your immediate code.

Start with the system you're building today and ask:

How does data flow?
What happens when the network fails?
What happens when the database is slow?
How does the system scale?
How do we handle duplicate requests?
How do we detect failures?

These questions gradually move you from developer thinking to system thinking.

System design is not about drawing more boxes.
It's about understanding the consequences of the boxes you draw.

By Niladri

.NET 11, CoreCLR and Google Play’s DEX Optimization: What .NET MAUI Developers Need to Know

NuvyntraLabs — Fri, 25 Sep 2026 11:14:30 +0000

Google Play is introducing more visibility around Android application quality, including 16 KB page-size support and DEX code optimization.

For .NET MAUI developers, this raises an interesting question:

Does moving to .NET 11 and CoreCLR automatically improve the DEX optimization score reported by Google Play?

The short answer is:

Not directly.

.NET 11 brings important improvements to .NET MAUI Android applications, including CoreCLR, ReadyToRun, and improved trimming. However, Google Play's DEX optimization metric is primarily related to the Android DEX pipeline and should be considered separately from .NET runtime optimization.

Let's break this down.

What is changing in .NET MAUI with .NET 11?

One of the significant changes in .NET 11 is the move toward CoreCLR as the default runtime for .NET MAUI applications.

Microsoft's official documentation states that CoreCLR is the default runtime for .NET MAUI applications in .NET 11.

For Android Release builds, CoreCLR also uses composite partial ReadyToRun by default.

This changes the runtime and compilation model compared with previous MAUI releases.

The relevant technologies include:

CoreCLR
ReadyToRun
IL trimming
Android-specific trimming improvements
NativeAOT as an optional deployment model

These changes can affect startup performance, application size, and runtime behavior.

However, they should not be confused with Google's DEX optimization metrics.

CoreCLR and DEX are different layers

A useful way to understand the architecture is:

.NET MAUI Application
        │
        ├── C# / .NET code
        │       │
        │       ├── CoreCLR
        │       ├── ILLink / Trimming
        │       └── ReadyToRun
        │
        └── Android platform integration
                │
                └── Java/Kotlin / Android code
                        │
                        └── DEX
                              │
                              └── R8

CoreCLR operates primarily on the .NET runtime side.

R8 operates on the Android/DEX side.

Therefore:

.NET 11 + CoreCLR
        ≠
automatic R8 optimization

Upgrading a MAUI application from an older .NET version to .NET 11 does not automatically mean that Google Play will report a high DEX optimization percentage.

What exactly is Google Play measuring?

Google has introduced a DEX code optimization metric in Play Console.

According to Google's Android documentation, the metric applies to applications with at least 10 MB of uncompressed DEX code.

Google evaluates aspects including:

DEX optimization
Code shrinking
Code obfuscation

Google currently specifies a 25% minimum threshold for the relevant optimization metrics.

This is separate from:

Target SDK
64-bit support
16 KB page-size support
.NET trimming
CoreCLR
ReadyToRun

These are related to Android application quality, but they are not the same measurement.

What about 16 KB page-size support?

This is another area that can easily become confused with DEX optimization.

Android's 16 KB page-size requirement primarily concerns native libraries.

For example:

lib*.so

Native libraries must be compatible with devices using 16 KB memory pages.

DEX optimization, on the other hand, concerns:

classes.dex
classes2.dex
classes3.dex
...

So an application can simultaneously have:

16 KB page-size support       ✅
Target SDK 36                 ✅
64-bit architectures          ✅
DEX optimization              ⚠️ Low

There is no contradiction.

They represent different parts of the Android build.

Does .NET 11 improve application size?

Potentially, yes.

This is where .NET 11 becomes interesting.

Microsoft has made improvements to Android trimming in .NET 11.

The Android trimmer can remove unused code more effectively, including improvements around Android-related managed types.

This can reduce the amount of code included in an application.

However, application size and DEX optimization are not interchangeable measurements.

For example:

.NET trimming
      ↓
Remove unused .NET code
      ↓
Smaller managed application

while:

R8
      ↓
Analyze Android bytecode
      ↓
Shrink / optimize / obfuscate DEX

Both are valuable, but they operate at different stages.

ReadyToRun is another separate concept

.NET 11 Android Release builds use composite partial ReadyToRun with CoreCLR by default.

ReadyToRun precompiles portions of .NET code to improve startup performance.

But ReadyToRun should not be interpreted as a DEX optimization mechanism.

In fact, precompiled code can introduce a size trade-off because additional native code may be included.

Therefore:

ReadyToRun is primarily a runtime/startup optimization, not a Google Play DEX optimization mechanism.

This distinction becomes important when analyzing application size and Play Console metrics.

What should MAUI developers do about "DEX optimization: Low"?

Don't immediately change your entire MAUI build configuration.

First, determine what Google Play is actually measuring.

If your Play Console reports:

DEX Code Optimization: Low

start by inspecting the actual Android App Bundle.

For example:

unzip -l MyApp.aab | grep -E '\.dex$'

You can also calculate the total DEX size:

unzip -l MyApp.aab \
  | grep -E '\.dex$' \

By Niladri

Migrating a Large Enterprise Xamarin Application to .NET MAUI: Practical Strategies That Actually Work

NuvyntraLabs — Fri, 25 Sep 2026 06:05:16 +0000

Migrating a small Xamarin.Forms application to .NET MAUI is usually manageable.

Migrating a large enterprise application is a different story.

The difficulty is rarely the Xamarin.Forms namespace replacement or converting a .csproj file. The real challenge is that an enterprise application has accumulated years of assumptions around Xamarin, third-party libraries, native platform APIs, custom renderers, background processing, authentication, local databases, CI/CD, and production behavior.

Microsoft provides migration tooling and official migration paths, but the tooling should be treated as an accelerator—not as the migration strategy itself. The Upgrade Assistant can perform many project and namespace transformations, but additional manual work is expected.

The practical question therefore becomes:

How do you migrate a large Xamarin application while continuing to develop, test, and release the product?

This article focuses on that problem.

1. Don't Start With the `.csproj`

One of the most common mistakes is starting the migration by changing:

<TargetFramework>...</TargetFramework>

and then fixing whatever breaks.

That approach works reasonably well for smaller applications.

For a large application, it creates a huge error list before you understand where the real risks are.

Instead, start by answering:

How many screens exist?
Which screens are business-critical?
Which NuGet packages are Xamarin-specific?
Which controls use custom renderers?
Which features depend on native Android/iOS code?
Are there background services?
How are push notifications implemented?
How does offline synchronization work?
Which parts depend on third-party SDKs?
How is the application signed and distributed?
Which production workflows cannot fail?

The first deliverable should be a dependency and feature map, not a converted project.

2. Divide the Application Into Migration Units

A 200-screen application should not be treated as one migration task.

Break it into units.

For example:

Application
│
├── Authentication
├── Customer
│   ├── Customer Search
│   ├── Customer Details
│   └── Customer History
│
├── Orders
│   ├── Order Creation
│   ├── Order Editing
│   └── Order Submission
│
├── Offline
│   ├── Local Database
│   ├── Queue
│   └── Synchronization
│
├── Notifications
├── Location
├── Documents
└── Reporting

Each unit should have its own migration status.

A simple tracking model is enough:

Feature	Xamarin	MAUI	Dependency Risk	Testing
Login	Working	Migrated	Low	Automated
Customer Search	Working	Migrated	Medium	Regression
Order Creation	Working	In progress	High	Full workflow
Push Notifications	Working	In progress	High	Device testing
Offline Sync	Working	Not started	Very High	Scenario testing

This changes the migration from:

"The application is 60% migrated."

to:

"Authentication and customer workflows are migrated; offline synchronization and notifications remain."

That is much more useful to an engineering team.

3. Freeze Architecture, Not Development

A large enterprise application may need to continue receiving new features while migration is happening.

This creates a difficult situation.

The Xamarin application is still in production, but the team is building the future MAUI version.

Do not freeze all development for months.

Instead, establish a rule:

New feature
     │
     ├── Business logic → Shared modern layer
     │
     ├── Xamarin UI → Temporary implementation
     │
     └── MAUI UI → Preferred implementation

The important part is that new business logic should not become more dependent on Xamarin.

For example, avoid introducing:

public class OrderService
{
    Xamarin.Forms.Application.Current...
}

Instead:

public class OrderService
{
    private readonly IOrderRepository _repository;

    public OrderService(IOrderRepository repository)
    {
        _repository = repository;
    }
}

The service can then be consumed by both generations of the application.

This is one of the most effective ways to prevent the migration from becoming a moving target.

4. Use a Compatibility Layer Instead of Rewriting Everything

Large Xamarin applications often contain hundreds of dependencies on platform-specific functionality.

Trying to replace everything immediately creates unnecessary work.

Introduce interfaces around unstable or platform-specific functionality.

For example:

public interface IDeviceService
{
    Task<string?> GetDeviceIdAsync();
    Task<bool> IsNetworkAvailableAsync();
}

The implementation can change:

Xamarin
   ↓
XamarinDeviceService

MAUI
   ↓
MauiDeviceService

The application code does not need to know which implementation is being used.

This approach is particularly useful for:

Device information
Secure storage
File access
Connectivity
Location
Notifications
Logging
Analytics
Authentication
Background processing

The goal is not to create abstractions everywhere.

Create them specifically where migration or platform differences are expected.

5. Treat Custom Renderers as a Separate Migration Problem

Custom renderers are frequently one of the biggest sources of migration effort.

A typical Xamarin application may contain:

CustomRenderer
├── Android
├── iOS
├── Shared Control
└── Platform-specific behavior

In MAUI, handlers provide the preferred customization model.

However, you do not necessarily need to rewrite every renderer on day one. MAUI can reuse certain Xamarin.Forms renderer implementations through compatibility/shim support, although this approach has limitations and becomes more important to revisit as you move to newer MAUI versions.

A practical strategy is:

Existing Renderer
       │
       ├── Simple + stable
       │       ↓
       │   Temporary reuse
       │
       ├── Complex but required
       │       ↓
       │   Migrate later
       │
       └── Obsolete behavior
               ↓
           Delete it

Do not automatically convert every renderer to a handler.

First ask:

Why does this renderer exist?

Sometimes the requirement disappeared years ago.

6. Be Aggressive About Removing Dead Xamarin Code

Migration is an excellent opportunity to identify code that no longer has a purpose.

Large Xamarin applications often contain:

Old platform workarounds
Deprecated controls
Duplicate services
Unused renderers
Legacy navigation code
Old dependency injection registrations
Abandoned feature flags
Xamarin-specific utilities
Compatibility packages added years ago

Don't migrate these blindly.

Use this decision:

Does the code still provide business value?
        │
        ├── Yes → Migrate
        │
        ├── Maybe → Validate usage
        │
        └── No → Delete

Every line of legacy code that you remove is one less thing the MAUI application needs to maintain.

7. Migrate Dependencies Before UI

A common approach is:

Page 1
Page 2
Page 3
Page 4
...

This looks productive, but it can be misleading.

Suppose 80 pages depend on:

OldControls
OldDatabase
OldNavigation
OldAuthentication

Migrating the pages first means the same dependency problems appear repeatedly.

Instead, migrate foundational dependencies first:

API Client
     ↓
Authentication
     ↓
Storage
     ↓
Database
     ↓
Telemetry
     ↓
Navigation
     ↓
UI

Once the foundation is stable, migrating individual screens becomes significantly more predictable.

Microsoft's migration guidance similarly recommends updating dependencies and ensuring the Xamarin.Forms application is stable before moving further into the migration.

8. Don't Assume Every NuGet Package Has a MAUI Replacement

This is where many enterprise migrations get stuck.

You may discover:

Xamarin Package
       ↓
No MAUI version

Don't immediately search for a package with a similar name.

Classify the dependency:

Option 1 — Replace

There is a maintained MAUI/.NET equivalent.

Option 2 — Remove

The application no longer needs it.

Option 3 — Wrap

The package can remain behind an interface temporarily.

Option 4 — Fork

The package is important but abandoned and the organization controls the source.

Option 5 — Rewrite

The dependency is small enough to replace with internal code.

The worst strategy is:

"Let's keep searching until we find something that looks similar."

A package replacement can introduce completely different runtime behavior.

9. Separate UI Migration From Business Logic Migration

Suppose you have:

OrderPage
OrderViewModel
OrderService
OrderRepository
OrderDatabase

Do not migrate these as one block.

A better approach is:

OrderService       → Modern .NET
OrderRepository    → Modern .NET
OrderDatabase      → Modern .NET
OrderViewModel     → Modernized
OrderPage          → MAUI

This allows the business layer to stabilize before the UI is converted.

The result should look approximately like:

             ┌───────────────┐
             │   MAUI UI     │
             └───────┬───────┘
                     │
             ┌───────▼───────┐
             │  ViewModel    │
             └───────┬───────┘
                     │
             ┌───────▼───────┐
             │ Application   │
             │   Services    │
             └───────┬───────┘
                     │
             ┌───────▼───────┐
             │ Infrastructure│
             └───────────────┘

This is more valuable than simply changing namespaces.

10. Build One Complete Vertical Slice

Don't try to migrate 30 screens simultaneously.

Pick one representative business workflow.

For example:

Login
  ↓
Customer Search
  ↓
Customer Details
  ↓
Create Order
  ↓
Save Locally
  ↓
Submit
  ↓
Receive Notification

Migrate the complete workflow.

Why?

Because this exposes problems that a single migrated screen will not reveal:

Navigation
Authentication
API calls
Dependency injection
Local storage
Serialization
Native APIs
Error handling
Logging
Push notifications
Performance
App lifecycle

If the vertical slice works, you have a template for subsequent migrations.

11. Keep Xamarin and MAUI Builds Running in Parallel

For large applications, one of the safest approaches is to maintain:

             Shared Core
                 │
        ┌────────┴────────┐
        │                 │
   Xamarin App        MAUI App
        │                 │
     Production        Migration

The shared layer contains business logic and infrastructure that can be reused.

The UI/platform layer gradually moves to MAUI.

This prevents the migration branch from becoming isolated for six months.

It also means developers can continue delivering fixes to the existing application.

12. Make the CI Pipeline a Migration Gate

A migration is incomplete if it only works on a developer's machine.

The CI pipeline should build:

Android
iOS

and eventually all supported targets.

At minimum, validate:

Restore
   ↓
Build
   ↓
Unit Tests
   ↓
UI/Integration Tests
   ↓
Signing
   ↓
Package
   ↓
Artifact Validation

Also validate the things developers frequently forget:

App identifier
Version number
Signing certificates
Provisioning profiles
Android keystore
Entitlements
Push notification configuration
Environment configuration
API endpoints
Release symbols
Crash reporting
Store packaging

A successful local build is not equivalent to a successful enterprise migration.

13. Test Native Features on Real Devices Early

One of the biggest mistakes is leaving native functionality until the end.

The application may compile perfectly while these features fail at runtime:

Push notifications
Background services
Location
Bluetooth
Camera
File picker
Deep links
Biometric authentication
Audio
Native SDKs

Create a native-risk prototype early.

For example:

MAUI Prototype
   ├── Push notification
   ├── Background task
   ├── Location
   ├── Camera
   └── Third-party SDK

Run it on actual Android and iOS devices.

This gives you answers before hundreds of screens depend on those capabilities.

14. Pay Special Attention to Android and iOS Lifecycle Differences

Xamarin applications often contain lifecycle assumptions that are no longer safe to carry forward unchanged.

Examples include:

Application startup
Activity lifecycle
Background execution
Notification handling
Permission flow
Process termination
App resume
App sleep

Don't test only:

"Does the screen open?"

Test:

Open app
↓
Background app
↓
Kill app
↓
Receive notification
↓
Tap notification
↓
Resume app
↓
Network unavailable
↓
Network restored

Enterprise bugs frequently appear in these transitions rather than in normal UI navigation.

15. Offline Synchronization Deserves Its Own Migration Plan

Offline applications are particularly difficult to migrate.

Do not treat offline storage as simply:

"Move SQLite code to MAUI."

You need to validate:

Create offline record
        ↓
Modify offline record
        ↓
Queue operation
        ↓
Application terminated
        ↓
Network restored
        ↓
Synchronize
        ↓
Server conflict
        ↓
Retry

Compare Xamarin and MAUI behavior using the same test dataset.

For synchronization systems, correctness is much more important than simply getting the database to compile.

16. Use Feature Flags During the Transition

Feature flags can reduce migration risk.

For example:

if (FeatureFlags.UseMauiOrderFlow)
{
    return await _mauiOrderFlow.ExecuteAsync();
}

return await _legacyOrderFlow.ExecuteAsync();

This allows a migration to be released gradually.

Possible rollout:

Internal users
      ↓
QA
      ↓
10% users
      ↓
25% users
      ↓
50% users
      ↓
100% users

The exact rollout depends on the organization's release process, but the principle is important:

Don't make the first production release the first real-world test.

17. Compare Production Metrics, Not Just Screens

A MAUI application can look identical to the Xamarin version and still behave differently.

Compare:

Startup time
Memory usage
Crash rate
ANR rate
API failures
Login success
Screen load time
Database operations
Push delivery
Background task success
Synchronization failures

For example:

Metric                  Xamarin       MAUI

Startup                 2.8 sec       3.1 sec
Crash-free sessions     99.4%         99.5%
Sync failures           0.8%          0.7%
Login failures          0.4%          0.5%

The exact numbers aren't important here.

The important thing is having measurable evidence instead of relying on:

"It seems to work."

18. Create a Migration Definition of Done

A screen should not be considered migrated merely because it compiles.

For each feature, define:

[ ] UI migrated
[ ] Navigation verified
[ ] API verified
[ ] Authentication verified
[ ] Offline behavior verified
[ ] Error handling verified
[ ] Analytics verified
[ ] Logging verified
[ ] Android tested
[ ] iOS tested
[ ] Regression tests passed
[ ] Production metrics available

For native features, add:

[ ] App backgrounded
[ ] App terminated
[ ] App restarted
[ ] Permission denied
[ ] Permission granted
[ ] Network unavailable
[ ] Network restored

This turns "migration complete" into something measurable.

19. What I Would Avoid

There are several approaches that look attractive but create problems later.

Big-bang migration

Stop Xamarin development
        ↓
Migrate everything
        ↓
Test everything
        ↓
Release

This creates a very large feedback loop.

Automatic conversion followed by mass bug fixing

Automation is useful, but it cannot understand business behavior.

Rewriting the entire application

Migration is not automatically a reason to rewrite business logic.

Migrating every renderer immediately

Some renderers can be temporarily reused or may no longer be required.

Replacing every NuGet package

A replacement package is not necessarily behaviorally equivalent.

Testing only the happy path

Enterprise applications fail in lifecycle, offline, permission, synchronization, and recovery scenarios.

20. A More Practical Migration Model

For a large enterprise application, I would structure the work like this:

             EXISTING XAMARIN
                    │
                    ▼
          ┌──────────────────┐
          │ Dependency Audit │
          └────────┬─────────┘
                   │
                   ▼
          ┌──────────────────┐
          │ Modern Core      │
          │ Services         │
          └────────┬─────────┘
                   │
          ┌────────┴────────┐
          ▼                 ▼
    Xamarin UI          MAUI UI
          │                 │
          │          Vertical Slice
          │                 │
          └────────┬────────┘
                   ▼
             Feature Flags
                   │
                   ▼
              Canary Users
                   │
                   ▼
            Production MAUI
                   │
                   ▼
          Remove Xamarin Code

This is essentially a controlled strangler approach rather than a rewrite.

The old application continues to work while the new implementation progressively takes over.

Final Thoughts

The hardest part of Xamarin-to-MAUI migration isn't learning .NET MAUI.

Most experienced Xamarin developers can learn the MAUI differences relatively quickly.

The difficult part is managing the technical dependencies, production risk, and migration sequencing of a large application.

The most effective practical principles are:

Map the application before changing it.
Migrate dependencies before hundreds of screens.
Keep business logic independent of Xamarin.
Use compatibility layers where they reduce risk.
Don't migrate obsolete code.
Build one complete vertical slice first.
Keep Xamarin and MAUI development running in parallel where necessary.
Test native functionality on real devices early.
Use feature flags and controlled rollout.
Measure production behavior instead of judging migration by compilation.

.NET MAUI gives organizations a modern platform, but the migration itself should be treated as an engineering transformation rather than a project-file conversion.

The goal isn't:

"We converted Xamarin to MAUI."

The real goal is:

"We moved the production application to MAUI without losing business functionality, reliability, or the ability to keep delivering."

That distinction is what makes a large migration manageable.

By Niladri

From Xamarin to .NET MAUI: An Enterprise Migration Playbook

NuvyntraLabs — Thu, 24 Sep 2026 14:50:19 +0000

Migrating a small Xamarin.Forms application to .NET MAUI can be relatively straightforward.

Migrating a large enterprise mobile application is a completely different problem.

Enterprise applications often contain years of accumulated business logic, hundreds of screens, custom renderers, native Android and iOS integrations, third-party SDKs, background services, push notifications, offline synchronization, authentication systems, CI/CD pipelines, and production dependencies.

Simply converting the .csproj file and fixing compilation errors is not an enterprise migration strategy.

A successful migration should be treated as a controlled transformation program.

The objective isn't to convert Xamarin code to MAUI. The objective is to move a production application to a modern platform without disrupting the business.

This guide presents a practical approach for migrating large Xamarin/Xamarin.Forms enterprise applications to .NET MAUI.

1. Why Enterprise Migration Is Different

A typical Xamarin application may look like:

Mobile Application
 ├── Pages
 ├── ViewModels
 ├── Services
 ├── API
 └── Local Storage

A large enterprise application can look more like:

Enterprise Mobile Platform
│
├── Presentation
│   ├── 100+ Pages
│   ├── Custom Controls
│   ├── Renderers
│   └── Behaviors
│
├── Business Layer
│   ├── Domain Logic
│   ├── Workflows
│   └── Validation
│
├── Infrastructure
│   ├── REST APIs
│   ├── Database
│   ├── Caching
│   └── Synchronization
│
├── Platform Services
│   ├── Push Notifications
│   ├── Location
│   ├── Bluetooth
│   ├── Background Services
│   └── File System
│
├── Native Integrations
│   ├── Android SDKs
│   ├── iOS SDKs
│   └── Third-party SDKs
│
└── DevOps
    ├── CI/CD
    ├── Signing
    ├── Distribution
    └── Monitoring

Every one of these areas can introduce migration risk.

Therefore, the migration needs to be planned before the first code change.

2. The Migration Mindset

The traditional approach is:

Xamarin
   ↓
Upgrade Project
   ↓
Fix Compilation Errors
   ↓
Fix Runtime Errors
   ↓
Release

For an enterprise application, a better approach is:

ASSESS
   ↓
BASELINE
   ↓
DECOUPLE
   ↓
BUILD MAUI FOUNDATION
   ↓
PILOT
   ↓
MIGRATE IN WAVES
   ↓
VALIDATE
   ↓
CANARY RELEASE
   ↓
FULL ROLLOUT
   ↓
RETIRE XAMARIN

This creates checkpoints throughout the migration rather than discovering major problems near the end.

3. Phase 1 — Assess the Existing Application

Before migrating anything, create a Migration Inventory.

Document:

Xamarin.Forms version
.NET/Xamarin versions
Target Android/iOS versions
NuGet dependencies
Custom renderers
Effects
Behaviors
Custom controls
Native Android code
Native iOS code
Background services
Push notification implementation
Authentication
Local database
Offline synchronization
File handling
Deep links
Analytics
Crash reporting
CI/CD
Signing and provisioning
Automated tests

The goal is to answer:

What parts of this application are actually dependent on Xamarin?

4. Build a Dependency Risk Matrix

Not every dependency deserves the same migration strategy.

Classify dependencies into three categories.

Green

Already compatible with the target .NET/MAUI environment.

.NET libraries
Modern NuGet packages
Pure business logic

Yellow

Requires configuration or code changes.

Older NuGet packages
Custom controls
Navigation libraries
Storage libraries

Red

Requires replacement or significant redesign.

Xamarin-only packages
Unsupported renderers
Old native bindings
Unmaintained SDKs

This gives the team a migration backlog before implementation begins.

5. Phase 2 — Establish a Production Baseline

One of the most overlooked parts of migration is establishing measurable baseline data.

Before migration, measure:

Metric	Xamarin Baseline	MAUI Target
Cold startup
Warm startup
Memory usage
Application size
Login time
Screen load time
API failure rate
Crash rate
ANR rate
Database performance

Also document critical business workflows.

For example:

Login
Search Customer
Open Customer
Create Order
Submit Order
Offline
Synchronize
Receive Notification
Logout

These become migration acceptance criteria.

Without a baseline, "migration completed" can mean nothing more than "the application builds."

6. Phase 3 — Stabilize Xamarin Before Migration

If the existing application is on an older Xamarin.Forms version, stabilize it before starting the MAUI migration.

A useful sequence is:

Legacy Xamarin.Forms
        ↓
Latest stable Xamarin.Forms version
        ↓
Update dependencies
        ↓
Fix existing issues
        ↓
Production baseline
        ↓
MAUI migration

Do not combine an unstable legacy application with a platform migration.

Otherwise, you won't know whether a problem was introduced by the migration or already existed.

7. Don't Automatically Convert Everything

A common mistake is assuming that every piece of existing code should survive.

Ask three questions:

Does this code contain business logic?

Keep and modernize it.

Does this code exist only because Xamarin required it?

Consider removing it.

Is this code solving a problem that MAUI already solves?

Delete it.

Migration is an opportunity to reduce technical debt, but not an excuse for a complete rewrite.

8. Decouple the Business Layer

Before migrating large amounts of UI, separate the business logic from the Xamarin-specific code.

A target architecture could look like:

Presentation
      ↓
ViewModels
      ↓
Application Services
      ↓
Domain
      ↓
Infrastructure
      ↓
Platform

For example:

MyCompany.Mobile
MyCompany.Mobile.Core
MyCompany.Mobile.Domain
MyCompany.Mobile.Application
MyCompany.Mobile.Infrastructure

The objective is simple:

The less Xamarin-dependent your business layer is, the easier the migration becomes.

9. PCL Migration: Don't Create Unnecessary Intermediate Work

Many older applications use Portable Class Libraries.

A common migration path is:

PCL
 ↓
.NET Standard
 ↓
.NET

This can be useful, but it should not automatically become a mandatory intermediate step.

Instead, inspect what is actually inside the PCL.

If it contains:

Models
Business Rules
Validation
API Clients
Utilities

move these into modern reusable libraries.

If it contains:

Xamarin.Forms
Xamarin.Essentials
Platform-specific APIs

separate those dependencies first.

The goal is not:

"Convert the PCL."

The goal is:

"Extract reusable application logic from the PCL."

10. Build the MAUI Foundation First

Before migrating hundreds of screens, establish the new MAUI foundation.

MyCompany.Mobile
│
├── Configuration
├── DependencyInjection
├── Navigation
├── Resources
│
├── Core
├── Domain
├── Application
├── Infrastructure
│
└── Platforms
    ├── Android
    ├── iOS
    ├── Windows
    └── MacCatalyst

Set up:

Dependency Injection
Configuration
Logging
Navigation
API clients
Authentication
Storage
Telemetry
Error handling
Environment management

This creates the platform on which the migrated features can run.

11. Migrate One Vertical Slice

This is one of the most important changes to the traditional migration approach.

Do not migrate:

Page 1
Page 2
Page 3
...
Page 200

Instead, migrate a complete business capability.

For example:

Login
   ↓
Dashboard
   ↓
Customer Search
   ↓
Customer Details
   ↓
Create Order
   ↓
Submit Order
   ↓
Offline Sync

This single workflow exercises:

UI
ViewModels
Navigation
Dependency Injection
API
Authentication
Storage
Offline support
Platform services
Telemetry
Error handling

If the vertical slice works, your migration architecture has been validated.

12. Renderers → Handlers

One of the major Xamarin.Forms migration areas is the transition from renderers to MAUI handlers.

But don't blindly convert every renderer.

Classify each renderer:

Custom Renderer
      │
      ├── Styling
      │      ↓
      │    Styles
      │
      ├── Behavior
      │      ↓
      │    Behavior
      │
      ├── Property mapping
      │      ↓
      │    Handler Mapper
      │
      └── Native control
             ↓
         Custom Handler

You may discover that some old renderers are no longer necessary.

13. Create Platform Abstractions

Avoid spreading platform-specific code throughout ViewModels and business logic.

Instead of:

#if ANDROID
...
#endif

everywhere, create interfaces.

For example:

public interface IPushNotificationService
{
    Task InitializeAsync();
    Task<string?> GetTokenAsync();
}

Then implement:

IPushNotificationService
        │
        ├── Android
        └── iOS

The same pattern can be applied to:

IBiometricsService
ILocationService
IFileService
IAudioService
IDeviceService
IBackgroundService

This keeps platform-specific code isolated.

14. Treat Native Functionality as a Separate Migration Track

Native functionality deserves its own checklist.

Android

MainActivity
Services
Broadcast Receivers
Firebase Messaging
Permissions
Intents
Background Processing

iOS

AppDelegate
Push Notifications
Background Tasks
Extensions
Permissions
Native SDKs

Don't consider the migration complete until these areas have been individually validated.

15. Firebase and Push Notifications

Push notification migration can be more complicated than expected.

Validate:

App running
App backgrounded
App terminated
App restored
Token refresh
Notification tap
Deep link
Data payload
Notification payload

Test both:

Android
iOS

And test different OS versions and device manufacturers.

Push functionality should be considered a production-critical capability, not just another NuGet package migration.

16. Authentication Must Be Tested End-to-End

Enterprise applications frequently use:

OAuth
OpenID Connect
Microsoft Entra ID
SSO
biometric authentication
refresh tokens
secure storage

Validate:

Login
 ↓
Token
 ↓
API
 ↓
Token Refresh
 ↓
Logout
 ↓
Re-login

Also test:

expired tokens
revoked sessions
offline behavior
device restart
application restart

17. Keep Xamarin and MAUI Side-by-Side

For a very large application, a side-by-side migration can significantly reduce risk.

                 Shared Core
                     │
          ┌──────────┴──────────┐
          ↓                     ↓
       Xamarin                MAUI
          │                     │
      Legacy UI             New UI

Migrate functionality progressively.

Eventually:

Xamarin
   ↓
Remaining modules
   ↓
Zero modules
   ↓
Retire Xamarin

This approach allows the existing application to continue receiving releases while migration continues.

18. Use Feature Flags

Feature flags allow old and new implementations to coexist.

CustomerDetails.Maui
        │
        ├── false → Xamarin
        │
        └── true  → MAUI

A feature can then be enabled for:

Internal testers
      ↓
Pilot users
      ↓
Small production group
      ↓
Larger production group
      ↓
Everyone

If a problem occurs, disable the MAUI implementation without necessarily rolling back the entire application.

19. CI/CD Should Be Migrated Early

Do not wait until the application is fully converted.

Build the pipeline early:

Pull Request
      ↓
Build
      ↓
Unit Tests
      ↓
Static Analysis
      ↓
Android Build
      ↓
iOS Build
      ↓
Integration Tests
      ↓
Artifact

Then:

Development
     ↓
QA
     ↓
UAT
     ↓
Internal
     ↓
Canary
     ↓
Production

Validate early:

Android signing
iOS signing
provisioning
certificates
app identifiers
push configuration
environment configuration
crash reporting
symbol upload

A migration that works only on a developer's machine is not complete.

20. Automated Testing Is a Migration Requirement

Create three levels of validation.

Unit tests

Business rules
Validation
Domain logic

Integration tests

API
Authentication
Database
Synchronization

Device tests

Android
iOS

Critical workflows should be automated before migration begins.

Otherwise, the team will spend enormous amounts of time manually comparing old and new applications.

21. Performance Testing

Don't assume that moving to MAUI automatically improves performance.

Compare the old and new applications.

Measure:

Startup
Memory
Navigation
Scrolling
API operations
Database operations
Synchronization
Battery usage
Application size

Test on:

low-end Android devices
popular Android manufacturers
supported iPhones
slow networks
offline mode
application restart
background/foreground transitions

The goal is measurable equivalence or improvement, not simply successful compilation.

22. Observability During Migration

Add migration-specific telemetry.

For example:

MigrationFeature = CustomerDetails
MigrationVersion = 5.2
Platform = Android
Implementation = MAUI

Track:

Crash rate
API failures
Navigation failures
Startup time
Feature failures
User workflow completion

Now you can compare:

Xamarin production
       VS
MAUI production

using actual data.

23. Don't Combine Migration With a Major Rewrite

This is probably the most important practical recommendation.

Avoid:

Xamarin → MAUI
       +
New UI
       +
New architecture
       +
New API
       +
New database
       +
New authentication

Instead:

Release 1 — Migration

Xamarin
   ↓
MAUI

Focus on functional equivalence.

Release 2 — Stabilization

MAUI
 ↓
Performance
 ↓
Reliability
 ↓
Operational improvements

Release 3 — Modernization

MAUI
 ↓
New UI
 ↓
Architecture improvements
 ↓
New features

This makes failures easier to isolate.

24. Track Migration Debt

Not everything needs to be modernized immediately.

Create migration tasks such as:

MAUI-MIG-001
Replace legacy renderer

MAUI-MIG-002
Remove Xamarin compatibility dependency

MAUI-MIG-003
Modernize navigation

MAUI-MIG-004
Replace legacy native binding

MAUI-MIG-005
Remove platform-specific conditional logic

This prevents temporary migration compromises from becoming permanent architecture.

25. Enterprise Migration Scorecard

Track every module.

Module	Core	UI	Native	Tests	Performance	Status
Login	✅	✅	✅	✅	✅	Complete
Dashboard	✅	🟡	✅	🟡	🟢	In Progress
Orders	✅	🟢	🔴	🟡	🟡	Blocked
Reports	✅	🟢	🟢	🟢	🟢	Complete

This creates a common language between developers, QA, architects, DevOps and management.

26. Recommended Migration Roadmap

A practical enterprise migration can be organized into these phases:

Phase 0
Assessment
       ↓
Phase 1
Baseline & Stabilization
       ↓
Phase 2
Architecture Decoupling
       ↓
Phase 3
MAUI Foundation
       ↓
Phase 4
Pilot Vertical Slice
       ↓
Phase 5
Platform & Native Migration
       ↓
Phase 6
Feature Migration Waves
       ↓
Phase 7
Regression & Performance
       ↓
Phase 8
Canary Production
       ↓
Phase 9
Full Production Rollout
       ↓
Phase 10
Xamarin Retirement
       ↓
Phase 11
Application Modernization

27. The Golden Rules

If I had to reduce the entire migration strategy to ten rules:

1. Don't start with the `.csproj`

Start with an assessment.

2. Establish a baseline

Measure the existing production application.

3. Don't migrate everything at once

Use incremental migration.

4. Decouple business logic

Reduce platform dependency.

5. Migrate vertical slices

Move complete business workflows.

6. Isolate native code

Keep Android/iOS implementation behind abstractions.

7. Don't blindly convert renderers

Determine whether they are still necessary.

8. Use feature flags

Keep rollback paths available.

9. Automate validation

Build tests before the migration becomes large.

10. Separate migration from modernization

First move to MAUI. Then improve the application.

Conclusion

A Xamarin-to-.NET MAUI migration for a large enterprise application should not be considered a simple framework upgrade.

It is an application transformation project.

The most effective strategy is to create a stable baseline, understand the application's dependencies, separate business logic from platform-specific code, establish the MAUI foundation, and then migrate complete business capabilities incrementally.

The migration should look like:

        ASSESS
           ↓
        BASELINE
           ↓
        DECOUPLE
           ↓
      MAUI FOUNDATION
           ↓
       PILOT SLICE
           ↓
    FEATURE MIGRATION
           ↓
      VALIDATE
           ↓
     CANARY RELEASE
           ↓
    FULL PRODUCTION
           ↓
    RETIRE XAMARIN
           ↓
      MODERNIZE

The most important mindset shift is this:

Don't ask, "How do we convert our Xamarin application to .NET MAUI?"

Ask:

"How do we move our enterprise application to .NET MAUI while keeping the business running?"

That question leads to a very different—and much safer—migration strategy.

By Niladri

VideoPipeline 1.1.0: Cap the Clip, Transcode on the OS, Then Encrypt

NuvyntraLabs — Thu, 24 Sep 2026 11:11:31 +0000

A 40-second 4K clip should not leave the device at full size. The app needs a duration cap, a smaller frame, a thumbnail, and a file it can encrypt before upload.

Plugin.Maui.VideoPipeline is that path. Version 1.1.0 is on nuget.org. FromCamera and FromGallery pick the clip. MaxDuration, MaxResolution, and MaxBytes are the gates. Over budget, the plugin asks the OS encoder to shrink it. If the device cannot encode, the result is CannotTranscode. There is no FFmpeg binary in the package.

This post is the walkthrough: how to register the defaults, run the builder, and what each platform actually transcodes.

What VideoPipeline is

VideoPipeline is the video counterpart to MediaPipeline for .NET MAUI on Android, iOS, Mac Catalyst, and Windows. MIT licensed. It targets net10.0, net10.0-android (API 21+), net10.0-ios, net10.0-maccatalyst, and net10.0-windows10.0.17763.0.

It does one job: pick a video, enforce the budget, thumbnail it, and optionally encrypt it.


Package	`Plugin.Maui.VideoPipeline` 1.1.0
Registration	`UseVideoPipeline`
Entry	`VideoPipeline.FromCamera`, `FromGallery`, `FromFile`
Encrypt	`Encrypt(key)` writes AES-256-GCM `.vault`
Source	github.com/nuvyntralabs/Plugin.Maui.VideoPipeline
Docs	nuvyntralabs.github.io/packages/plugin-maui-video-pipeline/

Images stay on Plugin.Maui.MediaPipeline. There is no Current singleton. Tests inject a processor with UseProcessor.

Install and register

dotnet add package Plugin.Maui.VideoPipeline --version 1.1.0

using Plugin.Maui.VideoPipeline;

builder
    .UseMauiApp<App>()
    .UseVideoPipeline(options =>
    {
        options.DefaultMaxDuration = TimeSpan.FromSeconds(30);
    });

DefaultMaxDuration applies when the builder does not call MaxDuration. The options default is already 30 seconds.

Pick, limit, thumbnail, encrypt

var result = await VideoPipeline.FromGallery()
    .MaxDuration(TimeSpan.FromSeconds(30))
    .MaxResolution(1280, 720)
    .MaxBytes(12 * 1024 * 1024)
    .ThumbnailAt(TimeSpan.FromSeconds(1))
    .Encrypt(key)
    .SaveAsync();

if (!result.Succeeded)
{
    // result.Status: Cancelled, TooLarge, TooLong, CannotTranscode, Unsupported
}

FromCamera() records. FromFile(path) and FromSource skip the picker. SaveAsync returns VideoPipelineResult. Succeeded is true only for VideoPipelineStatus.Ok. The artifact then carries ThumbnailPath when a frame could be decoded, and Encrypted when Encrypt ran.

Encrypt takes an AES key and writes a .vault file. DecryptFileAsync reverses that file. UploadWith accepts an IMediaUploader. StoreIn accepts an IMediaVault. Chunked upload that must resume after process death stays on SmartUpload once you have a path.

1.1.0 is the release that thumbnails and asks the OS to transcode when the clip is over budget. Android transcode honors cancel and times out.

What each platform encodes

Platform	Probe and thumbnail	Transcode
Android	`MediaMetadataRetriever`	`MediaCodec` and `MediaMuxer`. Many devices return `CannotTranscode`.
iOS and Mac Catalyst	`AVAsset` and `AVAssetImageGenerator`	`AVAssetExportSession` at 640×480 or 1280×720, with an optional duration trim.
Windows	File size	`CannotTranscode`, plus a copy and thumbnail floor.
`net10.0` tests	File size	`CannotTranscode` unless a test injects `UseProcessor`.

CannotTranscode is a typed result. The call does not throw, and the package does not fall back to a bundled encoder. If every Android device must shrink the file, an FFmpeg binding is the tool that makes that guarantee. VideoPipeline is the path when the OS encoder is enough and a failed encode must stay a status.

Permissions the host still requests

Android, in Platforms/Android/AndroidManifest.xml:

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" android:maxSdkVersion="32" />

Camera capture needs CAMERA and usually RECORD_AUDIO. Gallery pick on API 33+ uses READ_MEDIA_VIDEO.

iOS, in Platforms/iOS/Info.plist:

<key>NSCameraUsageDescription</key>
<string>This app records video.</string>
<key>NSMicrophoneUsageDescription</key>
<string>This app records audio with video.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>This app reads videos from your library.</string>

Mac Catalyst and Windows use the camera and photo capabilities the MAUI host already declares.

When something looks wrong

What you see	What to do
`Cancelled`	The picker was dismissed.
`TooLong` or `TooLarge` after transcode	The OS encode still missed `MaxDuration` or `MaxBytes`. Lower the capture budget or reject the clip.
`CannotTranscode` on Android	That device's `MediaCodec` path could not encode. Show the status. Do not expect FFmpeg behavior.
`CannotTranscode` on Windows	Windows transcode is the typed result. Probe is file size.
No `ThumbnailPath`	The platform could not decode a frame at `ThumbnailAt`.
`Encrypted` is false	`Encrypt(key)` was not on the builder.
The upload restarts after a kill	VideoPipeline hands off a file. Resume belongs to SmartUpload.

Where VideoPipeline sits next to the other tools

Need	Tool
Camera or gallery video, limits, thumbnail, OS transcode, encrypt	VideoPipeline — `Plugin.Maui.VideoPipeline`
Camera-to-upload images	Plugin.Maui.MediaPipeline
Resumable upload of the file you just wrote	Plugin.Maui.SmartUpload
A guaranteed encode on every Android device	An FFmpeg binding

MAUI MediaPicker is enough when you only need the original file. VideoPipeline is the pipeline when the budget, the thumbnail, and the .vault file are part of the same call.

Try it

dotnet add package Plugin.Maui.VideoPipeline --version 1.1.0

Register UseVideoPipeline, call FromGallery with a 30-second cap and a 12 MB ceiling, and branch on result.Status. samples/Plugin.Maui.VideoPipeline.Sample covers camera, gallery, encrypt, thumbnail, and a CannotTranscode result that does not crash.

NuGet: Plugin.Maui.VideoPipeline
Repository: github.com/nuvyntralabs/Plugin.Maui.VideoPipeline
Sample: Plugin.Maui.VideoPipeline.Sample
Package page: nuvyntralabs.github.io/packages/plugin-maui-video-pipeline/

By Admin

OfflineSync 1.0.10: Write on the Device, Sync When the Network Is Real

NuvyntraLabs — Thu, 24 Sep 2026 11:09:31 +0000

A field note written in a dead zone has to land on the device first. The server can catch up when the radio comes back.

Plugin.Maui.OfflineSync is that queue. Version 1.0.10 is on nuget.org. InsertAsync, UpdateAsync, and DeleteAsync finish locally. A change log records the mutation. SyncAsync pushes the log and pulls remote updates. A failed automatic push is isolated so it does not take the process down.

This post is the walkthrough: how to register the engine, write a SyncableEntity, pick a conflict strategy, and what the HTTP remote expects.

What OfflineSync is

OfflineSync is an offline-first sync engine for .NET MAUI on Android and iOS. MIT licensed. It targets net10.0, net10.0-android (API 21+), and net10.0-ios (15+). The local file is SQLite (offlinesync.db3 under app data) unless you pass DatabasePath or UseInMemoryStore.

It does one job: keep the write on the device, then ship the change log when the network is real.


Package	`Plugin.Maui.OfflineSync` 1.0.10
Registration	`UseOfflineSync`
Client	`IOfflineSyncEngine`, or `OfflineSync.Default`
Store	SQLite by default, or an in-memory store for tests
Source	github.com/nuvyntralabs/Plugin.Maui.OfflineSync
Docs	nuvyntralabs.github.io/packages/plugin-maui-offline-sync/

Room-style insert, find, replace, and delete across SQLite, NuvexaDB, Realm, or LiteDB stays on Plugin.Maui.LocalStore. OfflineSync is the sync protocol, not a second CRUD API for every engine.

Install and register

dotnet add package Plugin.Maui.OfflineSync --version 1.0.10

using Plugin.Maui.OfflineSync;

builder
    .UseMauiApp<App>()
    .UseOfflineSync(options =>
    {
        options.RemoteBaseAddress = new Uri("https://api.example.com/sync/");
        options.ConflictStrategy = ConflictStrategy.LastWriteWins;
        options.AutoSync = true;
        options.AutoSyncInterval = TimeSpan.FromMinutes(5);
    });

AutoSync is on by default, on a five-minute timer. SyncOnNetworkRestored and SyncOnResume are also on. Timer and connectivity sync catch exceptions. Subscribe to SyncCompleted and StatusChanged when the UI has to show a failed push. 1.0.10 also finishes the Android job even when JobFinished arrives after the service instance is gone.

LocalOnly skips remote calls. EnableBackgroundSync registers Android JobScheduler or iOS BGTaskScheduler. That flag still needs the manifest entries below.

Write locally

public sealed class TodoItem : SyncableEntity
{
    public string Title { get; set; } = "";
    public bool IsDone { get; set; }
}

var todos = OfflineSync.Default.GetCollection<TodoItem>("todos");
await todos.InsertAsync(new TodoItem { Title = "Buy milk" });
await OfflineSync.Default.SyncAsync();

SyncableEntity carries Id, Version, CreatedAtUtc, UpdatedAtUtc, IsDeleted, and a local SyncState. An empty id is filled on insert. SyncState stays on the device. An edit after an insert stays one insert in the change log.

InsertAsync, UpdateAsync, and DeleteAsync complete against SQLite before any HTTP call. GetAsync, GetAllAsync, and QueryAsync read that local set. GetPendingCountAsync tells you how many changes are still waiting. RequeueFailedAsync puts a Failed change back on the queue after MaxRetryAttempts (8 by default).

Conflicts

The default strategy is ConflictStrategy.LastWriteWins: the later UpdatedAtUtc is kept. ServerWins keeps the remote document. ClientWins keeps the local one. Custom requires OfflineSyncOptions.CustomConflictResolver.

OfflineSync.Default.ConflictDetected += (_, args) =>
{
    // args.Collection, args.EntityId, args.Winner: Local, Remote, or Merged
};

StatusChanged reports Idle, Syncing, Offline, or Failed. SyncCompleted fires after a cycle finishes, including a skip or a failure. CollectionChanged fires for a local mutation and for a remote merge.

What the HTTP remote looks like

HttpRemoteSyncClient is the default when you set RemoteBaseAddress. Pull is GET {base}/{collection}?cursor={cursor}. Push is POST {base}/{collection}/changes with operation, baseVersion, updatedAtUtc, and payloadJson. The response lists accepted, conflicts, and rejected. A conflict should include serverVersion, serverUpdatedAtUtc, and serverPayloadJson so the resolver can run.

Supply your own transport when the API is already shaped:

builder.Services.AddSingleton<IRemoteSyncClient, MyApiClient>();

RemoteAccessToken or RemoteAccessTokenProvider attaches a bearer token to the built-in client. An in-memory remote exists for the sample and for tests.

Background sync permissions

Leave EnableBackgroundSync false until the host declares the platform entries.

Android:

<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

iOS, with the identifier plugin.maui.offlinesync.refresh:

<key>BGTaskSchedulerPermittedIdentifiers</key>
<array>
    <string>plugin.maui.offlinesync.refresh</string>
</array>
<key>UIBackgroundModes</key>
<array>
    <string>fetch</string>
    <string>processing</string>
</array>

When something looks wrong

What you see	What to do
`OfflineSync has not been initialized`	Call `UseOfflineSync` before `OfflineSync.Default`.
Writes succeed and nothing reaches the server	`LocalOnly` is true, `AutoSync` is false and nothing called `SyncAsync`, or the device is still offline.
Status stays `Failed`	Read `SyncCompleted`. After `MaxRetryAttempts`, call `RequeueFailedAsync`.
`ConflictStrategy.Custom` throws at startup	Set `CustomConflictResolver`. Custom without a resolver is rejected.
A failed auto-sync kills the app	That crash path is what 1.0.10 isolates. Surface the error from `SyncCompleted` instead.
Background sync never runs	`EnableBackgroundSync` is false, or the manifest / `Info.plist` entries are missing.

Where OfflineSync sits next to the other tools

Need	Tool
Local writes, a change log, and a conflict on sync	OfflineSync — `Plugin.Maui.OfflineSync`
Room-style CRUD on the engine you pick	Plugin.Maui.LocalStore
Retry one HTTP call that already failed	Plugin.Maui.RetryQueue
Durable jobs with a dead-letter path	Plugin.Maui.JobQueue

Realm and Azure Mobile Apps are the usual choice when the organization already runs that sync fabric. OfflineSync is the engine when the host wants SQLite, a small HTTP protocol, and an explicit winner for each conflict.

Try it

dotnet add package Plugin.Maui.OfflineSync --version 1.0.10

Register UseOfflineSync with an https base address. Insert one SyncableEntity, then call SyncAsync or wait for the five-minute auto-sync. samples/Plugin.Maui.OfflineSync.Sample is a todo app that writes to SQLite and syncs through an in-process remote.

NuGet: Plugin.Maui.OfflineSync
Repository: github.com/nuvyntralabs/Plugin.Maui.OfflineSync
Sample: Plugin.Maui.OfflineSync.Sample
Package page: nuvyntralabs.github.io/packages/plugin-maui-offline-sync/

By Admin

TlsPin 1.0.2: Reject the Call When the SPKI Pin Does Not Match

NuvyntraLabs — Thu, 24 Sep 2026 11:06:35 +0000

A payment client that accepts any certificate chain will complete the call on the wrong key. The pin has to fail that request.

Plugin.Maui.TlsPin is that check. Version 1.0.2 is on nuget.org. AddTlsPin attaches SPKI SHA-256 hashes to one named HttpClient. An empty pin set throws when you register it. A mismatch fails the request. ReportOnly is the staging switch, and it still raises OnPinFailure.

This post is the walkthrough: where the pin attaches, why you ship a backup hash, and which HTTP jobs stay on the sibling plugins.

What TlsPin is

TlsPin is the certificate-pin layer for .NET MAUI HttpClient on Android, iOS, Mac Catalyst, and Windows. MIT licensed. It targets net10.0, net10.0-android, net10.0-ios, net10.0-maccatalyst, and net10.0-windows10.0.17763.0.

It does one job: compare the server public key to the hashes you configured.


Package	`Plugin.Maui.TlsPin` 1.0.2
Registration	`UseTlsPin`, then `AddTlsPin` on the client
Pin	`TlsPinSet.SpkiSha256`, base64 SHA-256 of the SPKI
Source	github.com/nuvyntralabs/Plugin.Maui.TlsPin
Docs	nuvyntralabs.github.io/packages/plugin-maui-tls-pin/

UseTlsPin is a no-op registrar. There is no Current singleton. The pin lives on the IHttpClientBuilder you already use for that API. Retry, typed REST, and token refresh stay on ApiResilience, HttpForge, and SecureSession.

Install and pin one host

dotnet add package Plugin.Maui.TlsPin --version 1.0.2

using Plugin.Maui.TlsPin;

builder
    .UseMauiApp<App>()
    .UseTlsPin();

builder.Services.AddHttpClient("payments", client =>
{
    client.BaseAddress = new Uri("https://api.example.com");
})
.AddTlsPin(options =>
{
    options.Pins.Add("api.example.com", new TlsPinSet
    {
        SpkiSha256 = { primary, backup }
    });
});

primary and backup are base64 SHA-256 hashes of certificate.PublicKey.ExportSubjectPublicKeyInfo(). TlsPin.ComputeSpkiSha256 produces that string from an X509Certificate2. Ship at least one backup pin so a planned key rotation does not brick every install on the day the leaf changes.

AddTlsPin throws if Pins is empty, and it throws if any host set has an empty SpkiSha256 list. That failure is at registration, before the first request.

RequireHttps defaults to true. A host that does not appear in Pins fails closed. AllowUnpinnedHosts is the opt-in that lets an unlisted host through. Leave it false on the payments client.

Report-only staging

ReportOnly still calls OnPinFailure and then allows the request. Use it while you confirm the hash in a build you can still talk to.

.AddTlsPin(options =>
{
    options.ReportOnly = true;
    options.OnPinFailure = (host, reason) =>
    {
        // reason is "pin mismatch" or "unpinned host"
    };
    options.Pins.Add("api.example.com", new TlsPinSet
    {
        SpkiSha256 = { primary, backup }
    });
});

Turn ReportOnly off before the store build. A mismatch then fails the request. OnPinFailure still runs, with "pin mismatch" or "unpinned host".

Android needs INTERNET if the host manifest does not already declare it. There is no pinning permission. iOS needs no extra usage string. ATS stays on because RequireHttps is true.

When something looks wrong

What you see	What to do
`TlsPin fail-closed: configure at least one host pin set`	`AddTlsPin` ran with an empty `Pins` dictionary.
`TlsPin fail-closed: a host pin set is empty`	A host entry has no `SpkiSha256` value. Add the primary hash and a backup.
Every call fails after a certificate rotation	The new SPKI is not in the set. The backup pin is what you rotate in before the leaf changes.
Calls succeed in staging and fail in production	Staging still has `ReportOnly = true`. Production does not.
A second host on the same client fails	That host is not in `Pins`, and `AllowUnpinnedHosts` is false. Pin it, or give it its own named client.
You wanted retries on 401	That is ApiResilience or SecureSession. TlsPin only checks the key.

Where TlsPin sits next to the other tools

Need	Tool
SPKI pin on one named `HttpClient`, fail closed	TlsPin — `Plugin.Maui.TlsPin`
A source-generated REST interface	Plugin.Maui.HttpForge
Retry, circuit breaker, offline queue	Plugin.Maui.ApiResilience
Access tokens and 401 refresh	Plugin.Maui.SecureSession

A custom HttpClientHandler, or the platform TrustManager / NSURLSession pin, is the usual choice when the app already owns that callback. TlsPin is the check when the hash set, the empty-set throw, and ReportOnly should sit on the same IHttpClientBuilder as the rest of the MAUI HTTP stack.

Try it

dotnet add package Plugin.Maui.TlsPin --version 1.0.2

Call UseTlsPin, then AddTlsPin on the payments client with two SPKI hashes. Confirm OnPinFailure in a ReportOnly build, then ship with ReportOnly left false. samples/Plugin.Maui.TlsPin.Sample covers the public API.

NuGet: Plugin.Maui.TlsPin
Repository: github.com/nuvyntralabs/Plugin.Maui.TlsPin
Sample: Plugin.Maui.TlsPin.Sample
Package page: nuvyntralabs.github.io/packages/plugin-maui-tls-pin/

By Admin

DEV Community: NuvyntraLabs

NuvLoc 1.1.2: The Agent Writes the Culture .resx. The CLI Checks It.

What NuvLoc is

Install and configure

Init, then the agent

CI without an agent

When something looks wrong

Where NuvLoc sits next to the other tools

Try it

Pulse 1.0.1: Nine Lanes for the Plugins the App Already Registered

What Pulse is

Register the host

Attach

After the session

When something looks wrong

Where Pulse sits next to the other tools

Try it

Lock the Device, Not the Page: App Lock, Biometric, Screen Guard, and the Vault

The timer and the cover

One prompt, without a timer

The recents thumbnail

The short secret

The file

When something looks wrong

Where the five sit next to each other

Try it

GeoLocator 1.0.8: One Fix, a Tracking Session, and a Reverse Geocode

What GeoLocator is

Install and register

One fix

A tracking session

Reverse geocoding

When something looks wrong

Where GeoLocator sits next to the other tools

Try it

MauiDev 1.2.2: What maui-dev doctor Checks, and What --fix Will Touch

What doctor is

Install

What the report covers

The two edits --fix may make

CI

When something looks wrong

Where doctor sits next to the other tools

Try it

Understanding System Design as a .NET/MAUI Engineer

What Is System Design?

System Design at Different Levels

Beginner

Intermediate

Senior

Architect

System Design for .NET MAUI

Offline-First Is System Design

Reliability Matters

Scalability

Vertical scaling

Horizontal scaling

Database Design

Microservices Are Not Mandatory

Observability

Logs

Metrics

Traces

A Simple System Design Process

Final Thoughts

.NET 11, CoreCLR and Google Play’s DEX Optimization: What .NET MAUI Developers Need to Know

What is changing in .NET MAUI with .NET 11?

CoreCLR and DEX are different layers

What exactly is Google Play measuring?

What about 16 KB page-size support?

Does .NET 11 improve application size?

ReadyToRun is another separate concept

What should MAUI developers do about "DEX optimization: Low"?

Migrating a Large Enterprise Xamarin Application to .NET MAUI: Practical Strategies That Actually Work

1. Don't Start With the .csproj

2. Divide the Application Into Migration Units

3. Freeze Architecture, Not Development

4. Use a Compatibility Layer Instead of Rewriting Everything

5. Treat Custom Renderers as a Separate Migration Problem

6. Be Aggressive About Removing Dead Xamarin Code

1. Don't Start With the `.csproj`

1. Don't start with the `.csproj`