DEV Community: NuvyntraLabs

MVVMExpress 1.3.0: One Application Shell for .NET MAUI

NuvyntraLabs — Wed, 23 Sep 2026 09:24:23 +0000

A field app needs properties, commands, a loading state, and a typed route to the next screen. Those pieces usually arrive as three frameworks that overlap.

MVVMExpress is the shell that keeps them on one registration path. Version 1.3.0 is on nuget.org. Core targets net10.0 and does not reference Microsoft.Maui.Controls. The MAUI host calls UseMvvmExpress. Shared libraries and tests call AddMvvmExpress.

This post is the walkthrough: what 1.3.0 registers, a first ViewModel, navigation, and the pieces Phases 8–10 added on the 1.0 SemVer lock. Public 1.x APIs stay source-compatible. Breaking changes wait for 2.0.0.

What MVVMExpress is

MVVMExpress is a modular MVVM framework for .NET MAUI on Android, iOS, Mac Catalyst, and Windows (single-window). MIT licensed. Manual INotifyPropertyChanged and hand-written commands are first-class. Generators are an accelerator.

The page owns BindingContext. The ViewModel never holds Page. ViewModels depend on INavigator, never on Shell.Current.


Host package	`Plugin.Maui.MVVMExpress` 1.3.0
Core	`Plugin.Maui.MVVMExpress.Core`
Registration	`UseMvvmExpress`
Source	github.com/nuvyntralabs/Plugin.Maui.MVVMExpress
Docs	nuvyntralabs.github.io/packages/plugin-maui-mvvmexpress/
Guides	Get started · How it works

Install the packages the screen needs. The host package pulls the MAUI registration. Core stays UI-free so a net10.0 test project can construct the same ViewModel.

Package	What it adds
`.Core`	`ObservableModel`, `ViewModel`, commands, `AsyncState`, `Outcome`, `IMessageHub`, `IModule`
`.Navigation`	`UseNavigationPage`, `UseShell`, replace-root, modal stack
`.Dialogs`	`IDialogs`, toast on `Window.AddOverlay`
`.Validation`	DataAnnotations, `MustMatch`
`.Pagination`	`SnapshotCollection`, `PagedCollection`, `SearchQuery`
`.Reactive`	`CombineLatest` without `System.Reactive`
`.SourceGenerators`	`[Notify]`, `[NotifyDependsOn]`, `[RegisterView]`, `[Route]`, analyzers `MVVME001`–`013`
`.Testing`	`FakeNavigator`, `FakeDialogs`, `LeakProbe`
`.Templates`	`dotnet new mvvmexpress` and `mvvmexpress-page`

Sibling plugins (NetworkMonitor, ApiCache, SecureSession, FormValidation, FeatureFlags, DeepLinks) are wired by the app through Core abstractions. MVVMExpress does not take a PackageReference on them.

Register

DI is Microsoft.Extensions.DependencyInjection. There is no container package to swap in.

builder
    .UseMauiApp<App>()
    .UseMvvmExpress(o => o
        .UseNavigationPage()
        .UseDialogs()
        .UseAuth<LoginViewModel>());

UseNavigationPage is the login → replace-root → push host. UseShell is an equal host for flyout, tabs, and // routes. Register one of them per window. UseAuth<TChallenge>() wraps GuardedNavigator. Leave that wrapper in place. UseSecureSessionAuth() and UseDeepLinks() fail closed when the sibling package is missing.

Call InitializeComponent() on App before resolving pages. ViewModels talk to IMainThread. Leave MainThread statics out of the ViewModel.

Generated [RegisterView] and [Route] apply from UseMvvmExpress through a module initializer. An explicit Map callback stays optional. A feature assembly registers itself with AddModule<T>():

public sealed class CatalogModule : IModule
{
    public void Configure(IServiceCollection services)
    {
        services.AddSingleton<ICatalog, Catalog>();
    }
}

builder.Services.AddModule<CatalogModule>();

A convention scan of *Page / *ViewModel is outside the 1.3 path. MVVME010 reports that in DEBUG.

A ViewModel

ObservableModel.SetProperty compares with EqualityComparer<T>.Default and skips the event when the value is unchanged. NotifyDependsOn raises a named set of dependents. Prefer that over PropertyChanged(null), which refreshes every binding.

public partial class NameViewModel : ViewModel
{
    [Notify] private string _first = "";
    [Notify] private string _last = "";

    [NotifyDependsOn(nameof(First), nameof(Last))]
    public string FullName => $"{First} {Last}".Trim();
}

Types that use [Notify] or [AsyncModelCommand] stay partial. [NotifyDependsOn] does not need the Reactive package. Hand-written SetProperty remains valid.

Lifecycle on ViewModel:

Construct (DI)
  → Accept(args) / Accept(query)
  → InitializeAsync(token)          once
  → OnNavigatedToAsync(token)
  → OnAppearingAsync(token)
  → OnDisappearingAsync(token)
  → OnNavigatedFromAsync(token)
  → Dispose                         cancels ViewModelCancellationToken

The token is created in the constructor and cancelled on Dispose. After dispose it stays readable, with IsCancellationRequested true, so a late continuation can still observe cancel. AutoAttachLifecycle (default true) attaches appear and disappear. Dispose is the guaranteed cancel.

AsyncState<T> is the bindable status object: Status, Data, Error, plus IsLoading, IsRefreshing, IsEmpty, HasError, and IsSuccess. LoadAsync returns Outcome<T>. The name is Outcome so it does not collide with an app-level Result<T>.

public AsyncState<IReadOnlyList<Product>> Products { get; } = new();

await Products.LoadAsync(token => catalog.ListAsync(token), ct);

Bind ItemsSource to Products.Data and IsRefreshing to Products.IsRefreshing. The host package ships AsyncStateView for loading, empty, error, and success templates.

Commands

The page binds Button.Command. The ViewModel owns the work, CanExecute, and cancellation. Tests call ExecuteAsync without a visual tree.

AsyncModelCommand runs through IOperationExecutor: CanExecute, a concurrency gate, optional timeout, optional retry, optional debounce or throttle, then the delegate. ICommand.Execute does not throw. Failures go to IErrorSink or IDialogs. ExecuteAsync still rethrows.

SaveCommand = new AsyncModelCommand(
    SaveAsync,
    () => CanSave,
    new AsyncCommandOptions
    {
        Concurrency = ConcurrencyMode.Prevent,
        Timeout = TimeSpan.FromSeconds(15),
        RetryCount = 2,
        RetryDelay = TimeSpan.FromSeconds(1),
    });

ConcurrencyMode is Prevent, CancelPrevious, Queue, Allow, or Replace. Call NotifyCanExecuteChanged when the condition changes. CanExecuteChanged is a weak event, so a button on a popped page does not pin the command. Allocate the command once.

Search text debounce stays on SearchQuery (default 300 ms, minimum length 2). Command debounce is a separate option on AsyncCommandOptions.

Navigation

INavigator is host-agnostic. Every public method returns Outcome and accepts CancellationToken. Navigators hop to IMainThread before new Page() or Shell.GoToAsync. An off-thread factory throws.

Host	When
`UseNavigationPage`	Login, then `ResetAsync` / `ReplaceRootAsync` so Back cannot return to login. Replaces `window.Page` with a `NavigationPage`.
`UseShell`	Flyout, tabs, or an existing Shell. `ResetAsync` works when the destination is a root `ShellContent`.
One host per window	A second call is for a second window.

Typed records are the default argument. The destination implements IAcceptNavArgs<T>. Accept runs before InitializeAsync. A dictionary query exists for deep links through IAcceptNavQuery.

public sealed record ProductDetailsArgs(int ProductId);

await navigator.NavigateToAsync<ProductDetailsViewModel, ProductDetailsArgs>(new(42));

PushModalAsync / PopModalAsync live on IPageNavigator. Toast is an overlay, drawn with Window.AddOverlay. It does not wrap Page.Content, so a later ResetAsync cannot restore a stale tree.

[RequiresAuth] on a ViewModel sends an anonymous session to the challenge type from UseAuth<TChallenge>(). Production tokens stay on Plugin.Maui.SecureSession. The template’s demo sign-in is demo@mvvmexpress.dev / secret.

What 1.3.0 adds

Phases 8–10 sit on the 1.0 lock. Existing UseAuth, UseNavigationPage, and Map<TViewModel, TPage> calls keep compiling.

Phase	What landed
8	One registration path. Generated `[RegisterView]` / `[Route]` apply without a required `Map`. `[NotifyDependsOn]`. CommunityToolkit `ObservableObject` interop. Analyzers `MVVME001`–`003`.
9	`IModule` / `AddModule<T>()`. Modal stack. `UseDeepLinks` / `UseSecureSessionAuth` (fail closed). `SectionHostView` for in-place tabs. `MvvmSearch`.
10	Analyzers `MVVME010`–`013`. ILLink roots for Core forms, Navigation, Dialogs, and Pagination. 1.0 contract tests.

Templates and the Marketplace wrappers pin the same 1.3.0 pack. The extensions install Plugin.Maui.MVVMExpress.Templates and run dotnet new. They do not copy a private scaffold.

Scaffold

dotnet new install Plugin.Maui.MVVMExpress.Templates
dotnet new mvvmexpress -n MyApp
cd MyApp
dotnet new mvvmexpress-page -n Catalog --namespace MyApp
dotnet test MyApp.Tests

The app template is a NavigationPage host: a counter page, a login that replace-roots back to home, one snapshot list, one FormViewModel screen, and a net10.0 test project. After mvvmexpress-page, call services.AddCatalog() from MauiProgram.

The same commands are in the IDE: MVVMExpress on the VS Code Marketplace and MVVMExpress for Visual Studio 2022+. After the pack is installed, File → New → Project lists MVVMExpress MAUI App.

When something looks wrong

What you see	What to do
`MVVME010`	Stop scanning `Page` / `ViewModel`. Use `[RegisterView]` / `[Route]`, or an explicit `Map`.
Page factory throws off the UI thread	Let the navigator construct the page. It hops to `IMainThread` first.
Back returns to login	Call `ResetAsync` or `ReplaceRootAsync` after sign-in on `UseNavigationPage`.
`UseShell` and `UseNavigationPage` both registered	Keep one host per window.
Auth guard reconstructed by hand	`UseAuth<TChallenge>()` already wraps `GuardedNavigator`. Register `IAuthState`.
`UseDeepLinks` or `UseSecureSessionAuth` throws at startup	The sibling package is missing. These adapters fail closed.
A popped page stays in memory	The message handler captured `this`. Subscribe with the recipient argument: `static (vm, _) => vm.Refresh()`.
`AddGeneratedViewModels` is redundant	1.3 applies generated maps from `UseMvvmExpress`. `Map` stays an escape hatch.
Windows opens a second window	The MAUI host is single-window. Sibling adapters stay Android and iOS.

Where MVVMExpress sits next to the other tools

Need	Tool
MAUI application shell: state, commands, typed navigation, dialogs	MVVMExpress
Source-generated properties and commands beside an existing toolkit	CommunityToolkit.Mvvm — interop package ships with 1.3.0
Observable pipelines	ReactiveUI, or `Plugin.Maui.MVVMExpress.Reactive` when you want `CombineLatest` without `System.Reactive`
Typed REST on the same host	Plugin.Maui.HttpForge
Lumina `NV*` controls	NuvyntraLabs.UIKit
A new MAUI app locked to this shell	Nuvyn — `nuvyn init`

CommunityToolkit.Mvvm covers properties and commands. Prism.Maui covers page navigation. ReactiveUI covers observable pipelines. MVVMExpress is the pack when the app needs those three plus bindable async state and a Shell or NavigationPage host.

Try it

dotnet new install Plugin.Maui.MVVMExpress.Templates
dotnet new mvvmexpress -n HarborDesk
cd HarborDesk
dotnet test HarborDesk.Tests

Run the app, sign in with the template demo account, and confirm Back does not return to login. To walk command, dialog, form, auth, and list in one sample, clone Playground.

NuGet: Plugin.Maui.MVVMExpress
Templates: Plugin.Maui.MVVMExpress.Templates
Repository: github.com/nuvyntralabs/Plugin.Maui.MVVMExpress
Get started: nuvyntralabs.github.io/packages/plugin-maui-mvvmexpress/integration/
Comparison: nuvyntralabs.github.io/packages/plugin-maui-mvvmexpress/comparison/

By Niladri

HttpForge 1.1.1: A Source-Generated REST Client for .NET MAUI

NuvyntraLabs — Wed, 23 Sep 2026 09:23:56 +0000

A ViewModel should call GetUser(42). It should not assemble HttpRequestMessage by hand, and it should not discover a wrong route at runtime.

Plugin.Maui.HttpForge is that contract. Version 1.1.1 is on nuget.org. You declare GET, POST, PUT, DELETE, PATCH, and HEAD as a C# interface. A source generator emits the HttpClient implementation at compile time. There is no reflection request builder.

This post is the walkthrough: the 1.1 request surface (unchanged in 1.1.1), how to register a typed client, and where retry, cache, tokens, and resumable uploads attach on the same IHttpClientBuilder.

What HttpForge is

HttpForge is the REST contract for .NET MAUI on Android, iOS, Mac Catalyst, and Windows. It targets net10.0, net10.0-android (API 21+), net10.0-ios and net10.0-maccatalyst (15+), and net10.0-windows10.0.19041.0.

It does one job: turn the interface into a client. Resilience, cache, session refresh, and chunked upload stay on their own packages and chain onto the builder AddHttpForgeClient returns.


Package	`Plugin.Maui.HttpForge` 1.1.1
Registration	`UseHttpForge` / `AddHttpForgeClient<T>`
Source	github.com/nuvyntralabs/Plugin.Maui.HttpForge
Docs	nuvyntralabs.github.io/packages/plugin-maui-httpforge/
Guides	Get started · How it works

1.1.1 is the current pack. The request surface shipped in 1.1.0. Unsupported shapes fail at compile time (HFG001–HFG010). A reflection fallback package is out of scope. Write that one method against HttpClient yourself.

Declare the API

public interface IUserApi
{
    [Get("/users/{id}")]
    Task<User> GetUser(int id, CancellationToken cancellationToken = default);

    [Post("/users")]
    Task<User> CreateUser([Body] CreateUserRequest request);
}

var user = await api.GetUser(42);

Piece	How
Methods	`[Get]`, `[Post]`, `[Put]`, `[Delete]`, `[Patch]`, `[Head]`
Path	`/users/{id}` matches `int id` or `[AliasAs("id")]`. `{id?}` is optional
Query	Leftover parameters, `[Query]`, query objects, collection formats, camel / snake / kebab keys
Flag with no value	`[QueryName]` writes `?archived`
JSON body	`[Body]`, or `[Body(BodySerializationMethod.JsonLines)]`
Headers	`[Headers("Accept: application/json")]`, `[Header("X-Request-Id")]`
Multipart	`[Multipart]` with `StreamPart`, `ByteArrayPart`, `FileInfoPart`, `[FormObject]`
Route extras	`[PathPrefix]`, `[Url]`, `[Timeout]`
Stream	`IAsyncEnumerable<T>` as JSON Lines or SSE
Compression	`RequestBodyCompression` / `[CompressRequest]` (gzip or brotli)
Token attach	`AuthorizationHeaderValueGetter`
Rich result	`Task<IApiResponse<T>>` — no throw on 4xx/5xx

JSON defaults to System.Text.Json. A trimmed or AOT host can pass a JsonSerializerContext. Newtonsoft.Json and XML are optional packages, not part of the core nupkg. XmlContentSerializer prohibits DTD processing and sets XmlResolver to null.

Task<T> throws ApiException when the server returns 4xx or 5xx, and ApiRequestException when the transport fails (timeout, DNS, TLS). Task<IApiResponse<T>> returns status, headers, and body so the caller can branch.

Register

using Plugin.Maui.HttpForge;

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

builder.Services.AddHttpForgeClient<IUserApi>(client =>
{
    client.BaseAddress = new Uri("https://api.example.com");
});

Resolve IUserApi from DI. A console or test host can skip MAUI:

var api = RestService.For<IUserApi>("https://api.example.com");

AddHttpForgeClient<T>() returns IHttpClientBuilder. That builder is where handlers attach. HttpForge itself does not reference ApiResilience, ApiCache, SecureSession, or SmartUpload, so a typed client still builds when those packages are absent.

The 1.1 request surface

1.1.0 filled the Refit-shaped gaps from 1.0: query objects, collection formats, naming presets, timeouts, runtime URLs, path prefixes, optional segments, valueless query flags, form-object flattening, streaming, request compression, and a token attach hook.

[PathPrefix("/api/v1")]
public interface IUserApi
{
    [Get("/users")]
    Task<List<User>> Search(
        [Query] UserQuery query,
        [Query(CollectionFormat.Multi)] int[] ages);

    [Get("/users/{id}/orders/{orderId?}")]
    [Timeout(5_000)]
    Task<List<Order>> GetOrders(int id, int? orderId);

    [Get("/events")]
    IAsyncEnumerable<Event> StreamEvents(CancellationToken cancellationToken);
}

settings.UrlParameterKeyFormatter = UrlParameterKeyFormatter.SnakeCase;
settings.AuthorizationHeaderValueGetter = (request, ct) => tokenStore.GetAccessTokenAsync(ct);
settings.RequestBodyCompression = RequestBodyCompression.Gzip;

CollectionFormat is Multi, Csv, Ssv, Tsv, or Pipes. [Url] replaces the method path with a runtime string or Uri. Validate that value before the call. AuthorizationHeaderValueGetter sees an absolute URI (BaseAddress plus the relative path) and attaches a header. A 401 refresh stays on SecureSession or ApiResilience.

Multipart is one POST:

[Multipart]
[Post("/users/{id}/photo")]
Task UploadPhoto(int id, [AliasAs("file")] StreamPart file);

await api.UploadPhoto(7, new StreamPart(stream, "photo.jpg", "image/jpeg"));

[FormObject] flattens a C# object into form fields (name, address.city). HFG008 fires when [FormObject] is used without [Multipart]. A file that must resume after process death belongs on Plugin.Maui.SmartUpload. Keep HttpForge for the JSON around that file: create the asset, confirm completion.

Chain the pipeline

IHttpClientFactory invokes handlers in reverse add order. Add resilience first, then cache, so a CacheFirst hit never enters retry. Register host options first, then attach each typed client.

ViewModel
  → IUserApi (generated)
      → IHttpClientFactory
          → GET cache            (ApiCache, optional)
          → Auth / 401 refresh   (SecureSession or ApiResilience)
          → Retry / circuit      (ApiResilience or Polly)
          → HttpClient

builder
    .UseMauiApp<App>()
    .UseHttpForge()
    .UseApiResilience(options =>
    {
        options.Retry.MaxRetryAttempts = 3;
        options.CircuitBreaker.BreakDuration = TimeSpan.FromSeconds(15);
        options.OfflineQueue.Enabled = true;
        options.TokenRefresh.Enabled = true;
    })
    .UseApiCache(options =>
    {
        options.DefaultExpiration = TimeSpan.FromMinutes(30);
        options.DefaultPolicy = CachePolicy.CacheFirst;
    });

builder.Services.AddSingleton<IAccessTokenProvider, AuthTokenProvider>();

builder.Services
    .AddHttpForgeClient<IUserApi>(client =>
    {
        client.BaseAddress = new Uri("https://api.example.com");
    })
    .AddApiResilience()
    .AddApiCache();

Cached responses include X-ApiCache-Hit, X-ApiCache-Stale, and X-ApiCache-Policy. After a local write, await cache.InvalidateByPrefixAsync("/users"). Calling IApiCache.GetAsync around the same HttpForge GET caches twice.

Pick one 401 path. SecureSession targets Android and iOS: store the refresh token, attach Bearer, retry once. On Mac Catalyst or Windows, use ApiResilience IAccessTokenProvider and leave SecureSession off that client. A login interface stays without the session handler. The business interface gets it.

builder.Services
    .AddHttpForgeClient<IAuthApi>(client =>
    {
        client.BaseAddress = new Uri("https://api.example.com");
    });

builder.Services
    .AddHttpForgeClient<IUserApi>(client =>
    {
        client.BaseAddress = new Uri("https://api.example.com");
    })
    .AddSecureSession()
    .AddApiResilience();

When SecureSession owns 401, set options.TokenRefresh.Enabled = false on ApiResilience. Stacking both refresh loops on one client races the refresh.

An organization already on Polly can skip ApiResilience and call .AddStandardResilienceHandler() on the same builder. TLS pinning is Plugin.Maui.TlsPin, fail-closed, on that handler chain.

Optional packages

HttpForge alone is enough for a typed client. Add a sibling package only when the host needs it.

dotnet add package Plugin.Maui.HttpForge
dotnet add package Plugin.Maui.HttpForge.Testing
dotnet add package Plugin.Maui.HttpForge.NewtonsoftJson
dotnet add package Plugin.Maui.HttpForge.Xml

var http = new StubHttp
{
    { Route.Get("/users/{id}"), Reply.With(new User { Id = 7, Name = "octocat" }) }
};

var api = http.CreateClient<IUserApi>("https://api.example.com");
var user = await api.GetUser(7);
await http.VerifyAllCalledAsync();

settings.ContentSerializer = new NewtonsoftJsonContentSerializer() or new XmlContentSerializer() swaps the body codec.

When something looks wrong

What you see	What to do
`HFG001`–`HFG010` at build	The interface shape is outside the generator. Change the contract, or write that call with `HttpClient`.
`HFG008`	`[FormObject]` needs `[Multipart]`.
`ApiException`	The server returned 4xx or 5xx. Switch the method to `Task<IApiResponse<T>>` when the caller should branch.
`ApiRequestException`	Timeout, DNS, or TLS. The response never arrived. Retry belongs on ApiResilience or Polly.
`[Url]` hits an unexpected host	Validate the runtime string before the call.
401 refresh runs twice	One owner: `.AddSecureSession()` or ApiResilience `TokenRefresh`, not both.
GET is cached and then cached again	`.AddApiCache()` is already on the client. Skip `IApiCache.GetAsync` for those URLs.
A large upload dies with the process	`[Multipart]` is one POST. Use SmartUpload for the bytes and HttpForge for the JSON confirm.
SecureSession on Mac Catalyst or Windows	That plugin is Android and iOS. Use `IAccessTokenProvider` on ApiResilience.

Where HttpForge sits next to the other tools

Need	Tool
Generated REST interface on MAUI	HttpForge — `Plugin.Maui.HttpForge`
Retry, circuit breaker, offline POST queue	Plugin.Maui.ApiResilience
GET CacheFirst / stale-while-revalidate	Plugin.Maui.ApiCache
Tokens and a single 401 retry on Android and iOS	Plugin.Maui.SecureSession
Chunked upload that survives process death	Plugin.Maui.SmartUpload
The same idea on a wider framework matrix	Refit

Refit is the mature general-purpose client. HttpForge 1.1 matches the request surface teams usually need from Refit 15 — methods, query objects, multipart, IApiResponse<T>, streaming, compression, and an authorization header getter — and leaves DI inside the core package. Refit remains the default when the team already uses it, needs Refit.Reflection, or targets frameworks beyond this MAUI matrix. HttpForge is the client when the host should chain ApiResilience, ApiCache, SecureSession, and SmartUpload on one IHttpClientBuilder.

The ViewModel that calls IUserApi usually lives in MVVMExpress. Nuvyn init includes HttpForge on a new MAUI host.

Try it

dotnet add package Plugin.Maui.HttpForge

Register UseHttpForge, add IUserApi with a BaseAddress, and call GetUser from a ViewModel. For a test that never leaves the process, add Plugin.Maui.HttpForge.Testing and stub the route with StubHttp.

NuGet: Plugin.Maui.HttpForge
Repository: github.com/nuvyntralabs/Plugin.Maui.HttpForge
Get started: nuvyntralabs.github.io/packages/plugin-maui-httpforge/integration/
Comparison: nuvyntralabs.github.io/packages/plugin-maui-httpforge/comparison/

By Niladri

LocalStore 1.1.0: Room-Style CRUD for .NET MAUI, on the Engine You Pick

NuvyntraLabs — Wed, 23 Sep 2026 09:16:13 +0000

A MAUI app that writes people to SQLite today should still find those people after the host opens a NuvexaDB file.

Plugin.Maui.LocalStore is that layer. Version 1.1.0 is on nuget.org. The host sets StoreBackend. Application code stays on IStoreCollection<T>: insert, find, replace, delete, select. A new engine is a different file and the same methods.

This post is the walkthrough: what 1.1.0 opens, how to register it, the CRUD that stays portable, and the three additions in this release — AutoMigrate, QueryAsync, and a source-generated [StoreDao].

What LocalStore is

LocalStore is a Room-style abstract database for .NET MAUI on Android, iOS, Mac Catalyst, and Windows. MIT licensed. It targets net10.0.

It does one job for the host: keep application code on a single collection API while the process opens one embedded engine.

host always calls
  InsertAsync / FindByIdAsync / ReplaceAsync / DeleteByIdAsync / FindAsync
                    ↓
              IStoreCollection<T>
     ┌────────────┼────────────┐
  SQLite      NuvexaDB     Realm / LiteDB / DuckDB
  SQLCipher   Firebird     LMDB / RocksDB / LevelDB


Package	`Plugin.Maui.LocalStore` 1.1.0
Registration	`UseMauiLocalStore`
Source	github.com/nuvyntralabs/Plugin.Maui.LocalStore
Docs	nuvyntralabs.github.io/packages/plugin-maui-local-store/
Guides	Get started · How it works

[StoreDao] generates a facade over that collection. It is a Room-shaped helper for this package. It is separate from AndroidX Room, and LocalStore does not take a PackageReference on OfflineSync, JobQueue, or FileVault.

Why the host picks the engine

Each backend keeps its own file. CRUD on IStoreCollection<T> stays the same when you change StoreBackend. Copying rows between those files is a separate step (AutoMigrate or MigrateAsync).

Database	Kind	Default file	On every MAUI platform
SQLite	Relational	`app.db`	Yes
SQLCipher	Encrypted SQLite	`app.db`	Yes
NuvexaDB	Document (`.nvx`)	`app.nvx`	Yes
LiteDB	Document	`app.litedb`	Yes
Realm	Object	`app.realm`	Yes
LMDB	Key-value	`app.lmdb/`	Yes on Android, iOS, and Windows. JSON files on Mac Catalyst
DuckDB	Analytical SQL	`app.duckdb`	Native on Windows (`win-x64`, `win-arm64`). JSON files on Android, iOS, and Mac Catalyst
Firebird Embedded	Relational	`app.fdb`	Native on Windows. JSON files elsewhere
RocksDB	Key-value	`app.rocksdb/`	Native on Windows x64. JSON files elsewhere
LevelDB	Key-value	`app.leveldb/`	JSON files on every OS in this pack

StoreBackend defaults to Nuvexa. Set it when you want SQLite or another engine. An empty Path resolves under LocalApplicationData/Plugin.Maui.LocalStore/ plus the default file name above.

SQLite, SQLCipher, NuvexaDB, LiteDB, and Realm are the engines that actually run on Android, iOS, Mac Catalyst, and Windows. Pick one of those when the same binary has to use the real database on every head.

Selecting DuckDB, Firebird, RocksDB, LevelDB, or LMDB on Mac Catalyst still opens. UseMauiLocalStore does not throw. On an OS without that native library, each row is a JSON file. InsertAsync, FindByIdAsync, ReplaceAsync, DeleteByIdAsync, and FindAsync still run. Filters run in memory. EnsureIndexAsync does nothing. QueryLanguage is None. Moving those JSON rows onto a native file later uses the same migrate path as any other engine switch.

Install and define a document

dotnet add package Plugin.Maui.LocalStore

A document is a POCO with a public string Id (nullable is fine) and a public parameterless constructor. Filters use top-level property names (Age, City). Get-only properties and [JsonIgnore] members are left out of the file. Stored scalars are string, int, long, double, float, bool, and DateTime.

public sealed class Person
{
    public string? Id { get; set; }
    public string Name { get; set; } = "";
    public int Age { get; set; }
    public string Status { get; set; } = "active";
    public string? City { get; set; }
}

GetCollection<Person>("users") creates the table or collection on the first write. The same Person type is valid on every engine.

Register

using Plugin.Maui.LocalStore;

builder
    .UseMauiApp<App>()
    .UseMauiLocalStore(o =>
    {
        o.Backend = StoreBackend.Sqlite;
        o.Path = Path.Combine(FileSystem.AppDataDirectory, "app.db");
        o.CreateIfMissing = true;
    });

var store = LocalStore.Current;
var users = store.GetCollection<Person>("users");

A console or test host can skip the MAUI builder:

await using var store = LocalStore.Open(new LocalStoreOptions
{
    Backend = StoreBackend.Sqlite,
    Path = path
});

services.AddMauiLocalStore(...) is the DI form of the same options.

Nuvexa is the default backend. Pass EncryptionKey when the file is an encrypted .nvx, a SQLCipher database, a LiteDB password, a Realm file, or a Firebird SYSDBA password. SQLite, DuckDB, LMDB, RocksDB, and LevelDB ignore that key. Keep the secret in SecureStorage (or the platform keystore). A shipped app keeps it out of source and logs.

builder.UseMauiLocalStore(o =>
{
    o.Backend = StoreBackend.Nuvexa;
    o.Path = Path.Combine(FileSystem.AppDataDirectory, "app.nvx");
    o.EncryptionKey = key;
    o.CreateIfMissing = true;
    o.CacheSizeMb = 16;
});

SQLCipher needs its own file. Open app-cipher.db. Leave an unencrypted app.db on the SQLite backend.

Create, read, update, delete

These calls are the same on every engine. Only StoreBackend and the path change.

var id = await users.InsertAsync(new Person
{
    Name = "Ada",
    Age = 36,
    Status = "active",
    City = "London"
});
// Id is generated when Person.Id is null, then written back onto the POCO

var ada = await users.FindByIdAsync(id);
ada.Name = "Ada Lovelace";
await users.ReplaceAsync(ada); // a missing Id throws LocalStoreException

var removed = await users.DeleteByIdAsync(id); // false when the id is absent

InsertManyAsync takes a list and returns the ids. FindAsync() with no filter returns every row.

Select without SQL

StoreFilter and StoreQuery are the portable query. SQLite and DuckDB run them as SQL when the native engine is open. Nuvexa maps property names onto NQL paths (Age → age, Id → _id). Key-value engines filter in memory.

var adults = await users.FindAsync(
    StoreFilter.Gte("Age", 21),
    new StoreQuery { SortBy = "Name", Limit = 20 });

var londonActive = await users.FindAsync(
    StoreFilter.And(
        StoreFilter.Eq("City", "London"),
        StoreFilter.Eq("Status", "active")),
    new StoreQuery { SortBy = "Age", SortDescending = true });

await users.EnsureIndexAsync("City", "Status");

Filter	Meaning
`StoreFilter.Eq`	Equal
`StoreFilter.Ne`	Not equal
`StoreFilter.Gte`	Greater than or equal
`StoreFilter.Lt`	Less than
`StoreFilter.And` / `Or`	All children / any child

StoreQuery.Limit of 0 means no limit. Skip pages the same filter.

Copy a collection onto another engine

Dispose does not copy data. Each engine file stays independent until you ask. On open, AutoMigrate copies registered collections when the destination collection is empty. Map<T> is required so both engines read and write the same POCOs. A destination that already has rows is left as it is (Skipped).

builder.UseMauiLocalStore(o =>
{
    o.Backend = StoreBackend.Nuvexa;
    o.Path = Path.Combine(FileSystem.AppDataDirectory, "app.nvx");
    o.EncryptionKey = key;
    o.AutoMigrate = true;
    o.MigrateFrom = StoreBackend.Sqlite;
    o.Map<Person>("users");
});

If MigrateFrom is omitted and exactly one other engine file sits next to the destination, that file is the source. Two or more siblings throw until you name MigrateFrom.

You can also copy without replacing LocalStore.Current:

var result = await LocalStore.MigrateAsync(
    new LocalStoreOptions { Backend = StoreBackend.Sqlite, Path = sqlitePath },
    new LocalStoreOptions { Backend = StoreBackend.Nuvexa, Path = nvxPath, EncryptionKey = key }
        .Map<Person>("users"));

StoreMigrationResult reports From, To, Collections, Documents, Skipped, and Reason. DeleteSourceAfterMigrate removes the source file after a successful copy. It defaults to false.

Schema changes inside one engine stay in your code. Adding a property to Person is your change on that file. Moving users from SQLite to Nuvexa is the migrate path above.

Raw SQL or NQL, when the engine has a language

QueryAsync<T> and ExecuteAsync sit on ILocalStore. The dialect is store.QueryLanguage. Check it before you send a command.

Engine	`QueryLanguage`
SQLite, SQLCipher	`Sql`
DuckDB, Firebird	`Sql` when native. `None` on the JSON fallback
Nuvexa	`Nql`
LiteDB, Realm, LMDB, RocksDB, LevelDB	`None` — the call throws `LocalStoreException`

if (store.QueryLanguage == StoreQueryLanguage.Sql)
{
    await store.ExecuteAsync(
        "UPDATE users SET Status = ? WHERE City = ?",
        ["active", "London"]);
    var adults = await store.QueryAsync<Person>(
        "SELECT * FROM users WHERE Age >= ?",
        [21]);
}

if (store.QueryLanguage == StoreQueryLanguage.Nql)
{
    var adults = await store.QueryAsync<Person>(
        """db.users.find({ age: { $gte: 21 } }).sort({ name: 1 }).limit(20)""");
}

SQL placeholders are ?. NQL is the text NuvexaDB already speaks. INuvexaLocalStore.ExecuteNqlAsync still returns raw JSON strings. Prefer QueryAsync<T> when you want Person instances. NQL update and delete need NuvexaDB 1.0.2 or newer. LocalStore 1.1 references Nuventra.NuvexaDB 1.0.7 for the Nuvexa backend.

The shared path for application code remains FindAsync. Reach for QueryAsync when a screen needs SQL or NQL that StoreFilter does not express, and when you have already chosen an engine whose QueryLanguage is Sql or Nql.

A generated DAO

[StoreDao] marks an interface. The generator emits an implementation that wraps IStoreCollection<T> and QueryAsync. CRUD method names map to the collection. [StoreRaw] calls QueryAsync. Placeholders are {parameterName}.

[StoreDao("users", typeof(Person))]
public interface IPersonDao
{
    Task<string> InsertAsync(Person item, CancellationToken cancellationToken = default);
    Task<Person?> FindByIdAsync(string id, CancellationToken cancellationToken = default);

    [StoreRaw(
        Sql = "SELECT * FROM users WHERE Age >= {minAge}",
        Nql = "db.users.find({ age: { $gte: {minAge} } })")]
    Task<IReadOnlyList<Person>> FindAdultsAsync(int minAge, CancellationToken cancellationToken = default);
}

services.AddMauiLocalStoreDao<IPersonDao>();
var adults = await store.GetDao<IPersonDao>().FindAdultsAsync(21);

[StoreRaw] carries both dialects so the same interface compiles against SQLite and Nuvexa. The running store uses the string that matches QueryLanguage.

When something looks wrong

What you see	What to do
`LocalStoreException` on `ReplaceAsync`	The POCO needs a non-empty `Id`. Insert first, or set `Id` before replace.
`LocalStoreException` and the file is missing	`CreateIfMissing` is false. Set it true, or create the file before open.
`QueryAsync` throws	`QueryLanguage` is `None` (LiteDB, Realm, a key-value engine, or a JSON fallback). Stay on `FindAsync`, or switch to SQLite, SQLCipher, or Nuvexa.
Open succeeded, queries feel like a folder of JSON	DuckDB, Firebird, RocksDB, LevelDB, or LMDB on Catalyst is on the JSON fallback. Use SQLite, SQLCipher, NuvexaDB, LiteDB, or Realm for a real engine on every OS.
Rows vanished after a backend change	Dispose and `Open` do not copy. Set `AutoMigrate` and `Map<T>`, or call `MigrateAsync`.
Migrate skipped a collection	The destination already had rows. Destination rows win.
Migrate throws with several files nearby	Set `MigrateFrom` (and `MigrateFromPath` if the source is not beside the destination).
Encrypted `.nvx` or SQLCipher will not open	Pass the same `EncryptionKey` used at create. Store it in `SecureStorage`.
SQLCipher opened the old SQLite file	Use a different path, such as `app-cipher.db`.

Where LocalStore sits next to the other tools

Need	Tool
Local rows or documents, and the host picks the engine	LocalStore — `Plugin.Maui.LocalStore`
Offline-first writes, a sync queue, and conflicts	Plugin.Maui.OfflineSync
Durable jobs, retry, and a dead-letter path	Plugin.Maui.JobQueue
Retry a failed call	Plugin.Maui.RetryQueue
Encrypted files (images, PDFs)	Plugin.Maui.FileVault
The `.nvx` engine, NQL, and Data Studio	NuvexaDB — `Nuventra.NuvexaDB`
A new MAUI host; LocalStore only when the spec asks	Nuvyn

Use the engine package directly when the app is committed to one database and needs that vendor’s query language, relationships, or tooling. Use LocalStore when the host must pick SQLite today and keep insert, find, replace, and delete stable if the file later becomes Nuvexa, Realm, or LiteDB.

Try it

dotnet add package Plugin.Maui.LocalStore

Register UseMauiLocalStore with StoreBackend.Sqlite and app.db, insert one Person, and FindByIdAsync it. To see every engine, clone the sample. MauiProgram there leaves registration to a backend picker that calls LocalStore.Open.

NuGet: Plugin.Maui.LocalStore
Repository: github.com/nuvyntralabs/Plugin.Maui.LocalStore
Sample: Plugin.Maui.LocalStore.Sample
Get started: nuvyntralabs.github.io/packages/plugin-maui-local-store/integration/
Comparison: nuvyntralabs.github.io/packages/plugin-maui-local-store/comparison/

By Niladri

NuvexaDB 1.0.7: One Embedded .nvx File for .NET, MAUI, and Every Other Host

NuvyntraLabs — Wed, 23 Sep 2026 09:01:24 +0000

A mobile app, a Kotlin service, and a desktop workbench can share one database file when they all run the same engine.

NuvexaDB is that engine. Version 1.0.7 stores BSON documents in a single portable .nvx file, queries them with NQL (Nuvexa Query Language), and can seal the file with AES-256-GCM. It runs in-process. .NET and .NET MAUI call the managed library. Java, Kotlin, Swift, Flutter, React Native, Python, Node.js, Go, and C++ load a Native AOT build of the same library through nuvexa.h (ABI v2).

A file written from Kotlin is the file Nuvexa Data Studio, a MAUI app, and a Swift host open.

The package id is Nuventra.NuvexaDB. The MauiEssentials catalog is published under Nuvyntra Labs. Both spellings are intentional.

What NuvexaDB is

NuvexaDB is a standalone embedded NoSQL database. MIT licensed. One process holds an exclusive lock on a path. Concurrent reads on that open handle are allowed. Writes stay exclusive.

It does two jobs for the host:

Nuventra.NuvexaDB is the engine: pages, WAL, B+tree indexes, NQL, and optional encryption. A .NET app references this package and talks to NuvexaDatabase.
Nuventra.NuvexaDB.Native is the same engine compiled to a shared library. Language SDKs pass UTF-8 JSON in and JSON out. They leave page layout inside the engine.


Engine	`Nuventra.NuvexaDB` 1.0.7
CLI	`Nuventra.NuvexaDB.Cli` — command `nuvexa`
Release	v1.0.7
Source	github.com/nuvyntralabs/NuvexaDB
Docs	nuvyntralabs.github.io/nuvexadb/
Guides	Platform integration

1.0.7 installs from the GitHub Release zip that matches your language and CPU. nuget.org and the language package registries are not the install path for this version. Download one zip (plus the native library when the guide says so). Leave the rest of the release page alone.

Why one file

An embedded store keeps the database next to the app: no server process, no connection string, no second deployment. NuvexaDB adds a written file format so that choice survives a language change.

Piece	What it gives you
`.nvx`	One application file. Creates and writes use format 2. Format 1 still opens.
Collections	Named sets of documents. `_id` is the primary key.
NQL	`find`, `aggregate`, `update`, and `delete` as text, on every host.
Indexes	B+tree. Compound indexes. Format 2 numeric keys (`d:`) keep range scans in order.
WAL	Crash recovery. A committed insert survives a hard stop. Sibling file: `<path>.nvx-wal`.
Encryption	Optional. Argon2id wraps a random data key. AES-256-GCM seals each page.
Data Studio	Desktop workbench for the same file on Windows, macOS, and Linux.

Documents on new pages are BSON. Public APIs stay JSON: NuvexaDocument.Parse, NQL, Data Studio, and the C ABI. A payload that still looks like {…} reads as legacy UTF-8 JSON, so mixed files stay valid.

What you need

Host	What to download from v1.0.7
.NET / .NET MAUI, WPF, WinUI, Avalonia, Uno	`NuvexaDB-NuGet.zip` — the `Nuventra.NuvexaDB` nupkg. No native library.
CLI	`NuvexaDB-Cli.zip` — install as a global tool. Keep it out of the app's `PackageReference` list.
Java / Kotlin desktop	`NuvexaDB-Java-<rid>.zip` and `NuvexaDB-Native-<rid>.zip`
Android	`NuvexaDB-Android.zip` (`libnuvexa.so` for arm64-v8a)
Swift	Swift zip plus the macOS dylib, or `NuvexaDB-Native-iOS.zip` (`Nuvexa.xcframework`)
Flutter, React Native, Python, Node.js, Go, C++	The language zip and the native zip for that OS and CPU

<rid> is the runtime id in the file name: osx-arm64, osx-x64, win-x64, win-arm64, linux-x64, linux-arm64.

Native library names inside the zip:

Machine	Library
macOS	`libnuvexa.dylib`
Windows	`nuvexa.dll`
Linux and Android	`libnuvexa.so`
iOS device and simulator	`Nuvexa.xcframework`

Python, Node, Flutter desktop, and the JVM fallback read NUVEXA_NATIVE_LIB (full path of the library). Swift, Go, and C++ read NUVEXA_NATIVE_DIR (the folder that contains it).

Create a database from .NET

dotnet new console -n Acme.Store -f net10.0
cd Acme.Store
dotnet add package Nuventra.NuvexaDB --source /path/to/unzipped-nuget

/path/to/unzipped-nuget is the folder that contains Nuventra.NuvexaDB.1.0.7.nupkg after you extract NuvexaDB-NuGet.zip.

using Nuventra.NuvexaDB;

await using var db = NuvexaDatabase.Create("app.nvx", new NuvexaCreateOptions
{
    EncryptionKey = "correct-horse" // omit or null for a plaintext file
});
// db.FormatVersion == 2

var users = db.GetCollection("users");
await users.InsertAsync(NuvexaDocument.Parse("""{"name":"Ada","age":36}"""));
await users.EnsureIndexAsync("age");
await users.EnsureIndexAsync(["city", "status"]);

var rows = await db.ExecuteAsync(
    """db.users.find({ age: { $gte: 21 } }).sort({ name: 1 }).limit(20)""");

GetCollection creates the collection when it is missing. await using closes the file. One process per path.

On MAUI, put the file under FileSystem.AppDataDirectory so the iOS and Android sandbox rules apply. Open it the same way on a later launch:

if (NuvexaDatabase.IsEncrypted(path) && string.IsNullOrEmpty(key))
{
    throw new InvalidOperationException("This .nvx is encrypted. Supply EncryptionKey.");
}

await using var opened = NuvexaDatabase.Open(path, new NuvexaOpenOptions
{
    EncryptionKey = key
});

There is no DropDatabase API. Dispose the handle, then delete the .nvx and its -wal sibling.

Typed LINQ stays on .NET:

var adults = await db.GetCollection<Person>("people").ToListAsync(p => p.Age >= 21);

The same file from another language

Other SDKs call nuvexa_create, nuvexa_insert, and nuvexa_execute. Status codes cross the boundary (0 ok, 2 encryption, 3 integrity). The SDK frees every returned string with nuvexa_free.

Kotlin:

NuvexaDatabase.create("app.nvx", "correct-horse").use { db ->
    db.insert("users", """{"name":"Ada","age":36}""")
    db.execute("db.users.find({ age: { \$gte: 21 } }).limit(20)")
}

Swift:

let db = try NuvexaDatabase.create("app.nvx", key: "correct-horse")
_ = try db.insert(collection: "users", json: #"{"name":"Ada","age":36}"#)
_ = try db.execute("db.users.find({ age: { $gte: 21 } }).limit(20)")

Each host guide on the integration page covers the empty project, the zip to unzip, create / open / close, collections, documents, and the encryption password.

NQL

NQL is the query text for Data Studio, ExecuteAsync, nuvexa query, and nuvexa_execute. Unquoted keys are accepted.

db.users.find({ "address.city": "Bengaluru", age: { $gte: 21 } })
  .sort({ lastName: 1 })
  .limit(20)
  .project({ email: 1 })

db.tickets.find({}).page(2, 200)

Family	Operators
Find	`$eq` `$ne` `$gt` `$gte` `$lt` `$lte` `$in` `$nin` `$and` `$or` `$exists` `$regex`
Update	`$set` `$unset` `$inc` `$push` `$pull`
Aggregate	`$match` `$project` `$sort` `$skip` `$limit` `$count` `$group` `$lookup`

explain() reports ID, IXSCAN, COLLSCAN, AGGREGATE, UPDATE, or DELETE. Equality on an index prefix can IXSCAN. $lookup refuses a foreign collection larger than LookupMaxDocuments (default 100 000; 0 disables the cap).

db.<collection>.update and delete need engine 1.0.2 or later. GridFS-style bytes go through db.Files.UploadAsync / DownloadAsync (fs.files / fs.chunks).

Encryption

Pass a non-empty EncryptionKey at create time and on every later open. The passphrase is UTF-8. It is never written into the file.

The engine derives a key-encryption key with Argon2id (app Create() defaults to 16 MiB, which is the mobile setting; Data Studio and the CLI use 64 MiB). A random 32-byte data key wraps the page cipher. A verifier fails a wrong passphrase before any data page is touched. ChangeEncryptionKeyAsync re-wraps that data key. Pages stay as they are.

Opening an encrypted file without the key throws NuvexaEncryptionException. A tampered or corrupt file throws NuvexaIntegrityException and stays closed. The engine does not repair it.

Store the secret in the platform keystore: SecureStorage on MAUI, Credential Manager on Windows, Keychain on Apple, Android Keystore on Android. A local demo can use a throwaway string. A shipped app keeps that string out of source, appsettings.json, logs, and crash reports.

Data Studio, the CLI, and the editors

Nuvexa Data Studio (Nuventra.NuvexaDB.Explorer) is an Avalonia workbench for one .nvx. Windows (x64 and ARM64 .msi), macOS (unsigned .pkg into /Applications), and Linux (.deb / .rpm for x64 and ARM64). Three tabs: Database Structure, Browse Data (200-row pages), and NQL. Import and export JSON or CSV. Compact, backup, restore, and change the encryption key from the Tools menu. Drag a .nvx onto the window. An encrypted file asks for the key. Recent files remember the last 12 paths and never the passphrase.

The same session backs the Visual Studio tool window and the VS Code / Cursor custom editor. Those VSIX packages bundle nuvexa under cli/.

The standalone CLI is a global dotnet tool. Extract NuvexaDB-Cli.zip and install from that folder:

dotnet tool install -g Nuventra.NuvexaDB.Cli --add-source /path/to/NuvexaDB-Cli

nuvexa covers query, browse, explain, samples, backup, and restore. Do not dotnet add package the CLI into an application.

When something looks wrong

What you see	What to do
`NuvexaEncryptionException`	The file is encrypted. Pass the same `EncryptionKey` you used at create. Data Studio prompts; a library call does not.
`NuvexaIntegrityException`	Open stopped on CRC, GCM, or HMAC. Leave the file closed. Restore from backup.
Second open throws	Another process already holds that path. Close Data Studio, the CLI, or the other app first.
Python or Node cannot create	Set `NUVEXA_NATIVE_LIB` to the full path of `libnuvexa` / `nuvexa.dll` from the matching native zip.
Package not on nuget.org	Expected for 1.0.7. `dotnet add package` with `--source` pointed at the unzipped `NuvexaDB-NuGet` folder.
Old file still opens	Format 1 stays readable. The next write promotes it to format 2.
`$lookup` refuses a collection	The foreign side is over `LookupMaxDocuments`. Raise the cap, or set it to `0`.

Where NuvexaDB sits next to the other tools

Need	Tool
Embedded NoSQL, NQL, encryption, Data Studio, many languages	NuvexaDB — `Nuventra.NuvexaDB`
MAUI CRUD that can sit on NuvexaDB or SQLite	Plugin.Maui.LocalStore. `QueryAsync` can run NQL when the backend is Nuvexa.
A new MAUI host, with NuvexaDB added when the spec asks	Nuvyn. `/nuvyn.plan` picks it. It is not in the default `init` set.
Browse or query a file you already have	Data Studio, or `nuvexa`

Try it

# After extracting NuvexaDB-NuGet.zip from the v1.0.7 release:
dotnet new console -n Acme.Store -f net10.0
cd Acme.Store
dotnet add package Nuventra.NuvexaDB --source /path/to/unzipped-nuget

Create app.nvx, insert one document, and run the find above. Open that file in Data Studio and run the same NQL in the NQL tab.

Release: github.com/nuvyntralabs/NuvexaDB/releases/tag/v1.0.7
Repository: github.com/nuvyntralabs/NuvexaDB
Product page: nuvyntralabs.github.io/nuvexadb/
Integration guides: nuvyntralabs.github.io/nuvexadb/integration/
NQL: nuvyntralabs.github.io/nuvexadb/docs/query/

By Niladri

Nuvyn CLI 1.2.0: Spec-Driven .NET MAUI, From a New App or One You Already Have

NuvyntraLabs — Wed, 23 Sep 2026 08:37:49 +0000

A coding agent will happily build a .NET MAUI app from a chat thread. The next session often builds a different one.

Nuvyn is the CLI that keeps that work on one stack and one written spec. Version 1.2.0 is on nuget.org as the global tool NuvyntraLabs.Nuvyn.Cli. The command is nuvyn.

This post is the walkthrough: what the tool is, how to install it, how to start a new app, how to attach it to an app you already have, and the slash commands the agent runs after that.

What Nuvyn is

Nuvyn is a standalone PackAsTool CLI for .NET 10. It depends on System.CommandLine and Spectre.Console. It is MIT licensed.

It does two jobs:

nuvyn init creates a new four-platform MAUI host (Android, iOS, Mac Catalyst, Windows) and locks plan and implement to the Nuvyntra stack.
nuvyn adopt attaches the same slash chain to an existing MAUI app. It writes workflow files only. The host you already have stays as it is.

The product domain is yours: clinic, field, bank, civic, retail, or anything else. The skills stay domain-agnostic. On a new host they lock only the MAUI and Lumina stack.

Individual plugins and NuvyntraLabs.UIKit stay installable on their own. You do not need Nuvyn to use one package.


Package	`NuvyntraLabs.Nuvyn.Cli` 1.2.0
Command	`nuvyn`
Source	github.com/nuvyntralabs/Nuvyn
Docs	nuvyntralabs.github.io/toolkits/nuvyn/
Guide	Install, init, adopt, slash workflow

Install it as a global dotnet tool. Do not add NuvyntraLabs.Nuvyn.Cli as a PackageReference in an app.

Why a spec, when the agent can just code

Spec-driven development treats a checked-in specification as the source of truth. Code follows that spec. A chat thread is a prompt log: it disappears, it contradicts itself, and a teammate cannot review it.

Nuvyn writes the artifacts into the repo:

Artifact	Role
Constitution	Standing principles: stack, platforms, privacy
Specification	This increment: users, journeys, edge cases
Plan	Smallest package set and one screen recipe per screen
Tasks	Dependency-ordered work (`T001 [P] [US1]`)
Analysis	Consistency check before production code

That matters more once an agent writes the code. The same prompt can pick a different MVVM library on a different day. Long chats drop acceptance rules that were never written down. Agents add a login page, a second UI kit, or persistence nobody asked for, because a finished-looking app is an easy completion.

Nuvyn narrows that search space. Constitution locks the stack. Specify writes the product. Plan names packages and screens. Analysis fails the loop before implement invents a second architecture.

GitHub Spec Kit (specify init) remains the usual choice when the stack is open. Nuvyn is the door when the host should be Nuvyntra, or when an existing MAUI app should grow through the same slash chain.

What you need

Requirement	Why
.NET 10 SDK	The CLI is `net10.0`. Hosts target `net10.0-android`, `net10.0-ios`, `net10.0-maccatalyst`, and `net10.0-windows10.0.19041.0`
MAUI workload	So the host can build and run
A coding agent	Cursor, GitHub Copilot, Claude Code, Gemini CLI, Codex, Windsurf, or any other Spec Kit agent
nuget.org	`init` adds the default Nuvyntra packages at the latest stable versions

Nuvyn targets those four platforms. It is the wrong tool for Tizen, Flutter, React Native, WPF, WinUI, Avalonia, or Uno.

Install

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

nuvyn version prints NuvyntraLabs.Nuvyn.Cli 1.2.0.

Already installed? Update the tool only. Existing apps keep the packages they already reference:

dotnet tool update -g NuvyntraLabs.Nuvyn.Cli --source https://api.nuget.org/v3/index.json
nuvyn version

On an interactive terminal, nuvyn asks every four hours whether to update from nuget.org ([y/N], default no). Skip that prompt with --no-update-check or NUVYNTRA_NO_UPDATE_CHECK=1. The cache file is ~/.nuvyntra/cli-updates.json, shared with maui-dev and maui-perf. The CLIs do not phone home.

Create a new app

nuvyn init <folder_name> always creates a new folder. If that name already exists, init prints an error and exits 1. The existing tree is left untouched.

nuvyn init HarborDesk --agent cursor

Omit --agent and the CLI shows a searchable picker (cursor (Cursor), agy (Antigravity), and the rest of the Spec Kit set). Non-interactive runs default to Cursor.

What init does:

Copies an embedded three-project host (MVVMExpress + Lumina UIKit).
Adds the default Nuvyntra packages from nuget.org, unpinned, at the latest stable versions.
Writes .nuvyn/ (constitution, templates, reference, init-options.json).
Installs slash commands for the agent you picked.
Writes a project README with the slash chain.

The tree looks like this:

HarborDesk/
├── HarborDesk.sln
├── HarborDesk/                      # MAUI app
│   ├── MauiProgram.cs
│   ├── Pages/MainPage.xaml
│   └── Resources/Images/nuvyntra.png
├── HarborDesk.Core/                 # ViewModels
├── HarborDesk.Tests/
├── .nuvyn/
│   ├── constitution.md
│   ├── init-options.json
│   ├── templates/
│   └── reference/
├── specs/                           # empty until /nuvyn.specify
├── .cursor/skills/nuvyn-*/          # when --agent cursor
└── README.md

MainPage is a Lumina screen: the Nuvyntra mark, an NVHeading counter, and Increase / Decrease NVButton controls. There is no stock Entry / Button / Label starter, and no seeded Login / Items / Edit pages. Screens come from the spec.

Build it the usual way:

cd HarborDesk
dotnet restore
dotnet build
dotnet build HarborDesk/HarborDesk.csproj -f net10.0-android

Default packages on a new host

init adds these, and nothing else from the catalog, until the spec asks:

Package	Role
Plugin.Maui.MVVMExpress	App shell, ViewModels, navigation
NuvyntraLabs.UIKit	Lumina `NV*` controls and page recipes
Plugin.Maui.HttpForge	Typed REST client
Plugin.Maui.FormValidation	Form rules on the host
Plugin.Maui.KeyboardManager	Soft keyboard hide, show, and resize

The MAUI app gets MVVMExpress plus Dialogs and Navigation, UIKit, HttpForge, FormValidation, and KeyboardManager. Core gets Plugin.Maui.MVVMExpress.Core and the source generators. Tests get Plugin.Maui.MVVMExpress.Testing. Versions are never pinned: dotnet add package runs without --version.

The host wires up like this:

builder
    .UseMauiApp<App>()
    .UseMvvmExpress(o => o
        .UseNavigationPage((nav, _) => nav
            .Map<MainPageViewModel, MainPage>("main"))
        .UseDialogs())
    .UseNuvyntraUIKit()
    .UseHttpForge()
    .UseMauiFormValidation()
    .UseKeyboardManager();

builder.Services.AddTransient<MainPageViewModel>();
builder.Services.AddTransient<MainPage>();

Register both the page and the view-model in MauiProgram. [RegisterViewModel] is a map for the generator, and it is not the DI registration. Chrome is NavigationPage unless the spec names Shell.

LocalStore, NuvexaDB, AppLock, and the rest of the catalog wait until you ask. /nuvyn.plan then picks the smallest fit. An outside library needs a Catalog gap row in plan.md.

Adopt an existing MAUI app

1.2.0 adds nuvyn adopt. This is the door for a tree that already exists.

cd FieldApp
nuvyn adopt --agent cursor

Or point at another folder:

nuvyn adopt --path ../FieldApp --agent copilot

Adopt:

Refuses the folder when it is not a MAUI app (UseMaui in a csproj), or when .nuvyn/ is already there.
Scans MVVM, chrome, UI kit, and HTTP. The scan is read-only.
Writes .nuvyn/, agent skills, an empty specs/ folder, and .nuvyn/adopt-report.md.
Sets "mode": "adopt" in init-options.json.
Runs maui-dev doctor when MauiDev is on PATH.

It does not add MVVMExpress, Lumina UIKit, or HttpForge. It does not edit MauiProgram, pages, or HttpClient call sites. New work keeps the stack the app already uses. Lumina NV* is allowed on new screens only when UIKit is already referenced. /nuvyn.plan and /nuvyn.implement read adopt-report.md first.

The slash chain

Open the project folder in the agent you selected. Run the commands in order. Extra text after a command is the prompt. An empty /nuvyn.specify asks you to describe the product.

/nuvyn.constitution → /nuvyn.specify → /nuvyn.clarify → /nuvyn.plan
    → /nuvyn.checklist → /nuvyn.task → /nuvyn.analysis
    → /nuvyn.implement → /nuvyn.converge

In Cursor the skill folders are named nuvyn-constitution (a folder name cannot contain .). Type /nuvyn-constitution in Cursor. Type /nuvyn.constitution in Copilot, Claude, Gemini, and the other command-file agents.

Step	You do	The agent writes
`/nuvyn.constitution`	Optional product rules (PII, lock, offline)	Updates `.nuvyn/constitution.md`. The stack stays locked on a new host.
`/nuvyn.specify`	Required: what the app is for	`specs/NNN-short-name/spec.md`, `.nuvyn/feature.json`, `checklists/requirements.md`
`/nuvyn.clarify`	Answer at most five questions	Updates `spec.md`
`/nuvyn.plan`	Extra constraints, if any	`plan.md` + `research.md` — packages and one Lumina recipe per screen
`/nuvyn.checklist`	Optional quality review	`checklists/<domain>.md`
`/nuvyn.task`	—	`tasks.md` (`T001 [P] [US1] …`)
`/nuvyn.analysis`	—	A report only: spec, plan, and tasks agree
`/nuvyn.implement`	Optional scope, such as Foundation only	Host code
`/nuvyn.converge`	—	Appends remaining work to `tasks.md`

A specify prompt can carry the product in one line:

/nuvyn.specify Resident 311 desk: sign in, report a bin miss, see live bus times.
/nuvyn.implement Implement only Foundation

Standing law lives in .nuvyn/reference/constraints.md. Each slash command stays short and points at that file, so the agent spends the window on the domain instead of restating the catalog every turn.

UI on a new host is Lumina first. One recipe per screen. Bound fields go inside the recipe so they replace the demo seed. Prefer NVInputField, NVPasswordField, and NVButton when an NV* control exists. Control reference: UIKit(MAUI) docs.

Which agent gets which folder

nuvyn init and nuvyn adopt write into the folder that agent already reads. The set matches Spec Kit, including more than thirty additional agents.

Agent	`--agent`	On disk
Cursor	`cursor`	`.cursor/skills/nuvyn-*/`
GitHub Copilot	`copilot`	`.github/skills/`
Claude Code	`claude`	`.claude/commands/`
Gemini CLI	`gemini`	`.gemini/commands/`
Codex CLI	`codex`	`.agents/skills/`
Goose	`goose`	`.goose/recipes/`
Windsurf	`windsurf`	`.windsurf/workflows/`
Generic	`generic`	`.agents/commands/`

Pass --agent cursor-agent when that Spec Kit key is the one you already use.

Refresh skills after a CLI update

Do not re-run nuvyn init on a tree that already exists. After the global tool updates, refresh slash files from inside the app:

cd HarborDesk
nuvyn update
nuvyn update --agent cursor

nuvyn update overwrites .nuvyn/templates/, .nuvyn/reference/, and the agent command files. It leaves host code, specs/, .nuvyn/constitution.md, and .nuvyn/adopt-report.md alone. It does not change PackageReference versions.

nuvyn check confirms dotnet and the payload. Inside a greenfield app it also proves the host still uses MVVMExpress, UIKit, HttpForge, FormValidation, and KeyboardManager. Inside an adopted app it prints the inventory and skips that proof.

When MauiDev is on PATH, init, adopt, and check run maui-dev doctor --path. A missing doctor is a warning. Nuvyn still succeeds. Install it when you want the environment report:

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

When something looks wrong

What you see	What to do
`HarborDesk already exists`	`init` is for a new folder. Pick another name, or delete a leftover failed scaffold and retry. For an existing MAUI app, `cd` in and run `nuvyn adopt`.
`is already a Nuvyn project`	Adopt or init already ran. Use `nuvyn update`.
`is not a MAUI app`	`adopt` needs a `UseMaui` csproj in that folder.
`Not a Nuvyn project`	`update` and `check` need a `.nuvyn/` folder from `init` or `adopt`.
Unable to resolve `MainPageViewModel`	Add `builder.Services.AddTransient<MainPageViewModel>()`.
`AddGeneratedViewModels` fails to build	Remove that call. Register the view-model with `AddTransient`.
The agent added LocalStore, Syncfusion, or Refit	You did not ask. Revert. Catalog first, UIKit first.
MAUI workload or TFM errors	Read the printed `maui-dev doctor` report. Do not re-run `nuvyn init`.
Update prompt every few hours	Expected. Answer `n`, or pass `--no-update-check`.

Where Nuvyn sits next to the other tools

Need	Tool
New Nuvyntra MAUI host and the spec chain	Nuvyn — `nuvyn init`, then `nuvyn update`
Existing MAUI app, same spec chain, keep its stack	Nuvyn — `nuvyn adopt`
Diagnose an existing MAUI tree	MauiDev — `maui-dev doctor`
Sibling `.resx` localization	NuvLoc
Any stack, spec only	GitHub Spec Kit
One runtime plugin	The matching `Plugin.Maui.*` package

Try it

dotnet tool install -g NuvyntraLabs.Nuvyn.Cli --source https://api.nuget.org/v3/index.json
nuvyn init HarborDesk --agent cursor
cd HarborDesk

Open that folder in your agent and run /nuvyn.constitution, then /nuvyn.specify with the product in one sentence.

If the app already exists:

cd YourMauiApp
nuvyn adopt --agent cursor

Then read .nuvyn/adopt-report.md before /nuvyn.plan.

NuGet: NuvyntraLabs.Nuvyn.Cli
Repository: github.com/nuvyntralabs/Nuvyn
User guide: nuvyntralabs.github.io/toolkits/nuvyn/guide/
Technical docs: nuvyntralabs.github.io/toolkits/nuvyn/docs/

The Story Behind Building NuvyntraLabs

NuvyntraLabs — Wed, 23 Sep 2026 07:45:43 +0000

Every open-source project has a beginning.

Sometimes it starts with a big idea, a business plan, or a team sitting around a whiteboard.

But sometimes, it starts much more simply.

A developer encounters the same problem again and again, builds a small solution for it, improves it over time, and eventually realizes:

“Maybe this can help someone else too.”

That is, in many ways, the story behind NuvyntraLabs.

From solving problems to building tools

My journey with software development has always been closely connected with solving practical problems.

Over the years, while working with mobile applications, .NET, Xamarin, .NET MAUI, APIs, architecture, networking, databases, background services, and many other areas, I repeatedly found myself building small utilities and reusable components.

A particular problem would appear in one project.

I would solve it.

Then the same problem would appear in another project.

So I would improve the solution and make it reusable.

Eventually, many of those solutions became libraries.

And some of those libraries became NuGet packages.

That was one of the early foundations of what would eventually become NuvyntraLabs.

The idea was not initially to build a large ecosystem.

It was simply:

Build something useful. Make it reusable. Share it. Improve it.

Why NuvyntraLabs?

As the number of projects and experiments grew, I realized that keeping everything as disconnected repositories did not make much sense.

There were libraries for different purposes.

There were experiments.

There were developer utilities.

There were MAUI components.

There were architectural ideas.

There were CLI concepts.

There were tools that could potentially become useful to other developers.

I wanted a place where all of these could live under a common identity.

That became NuvyntraLabs.

NuvyntraLabs is not just a collection of repositories.

It is an attempt to create a small developer ecosystem around ideas, tools, libraries, experimentation, and open-source collaboration.

The .NET MAUI connection

One of the strongest foundations of NuvyntraLabs is the .NET MAUI ecosystem.

Having worked extensively with Xamarin and later .NET MAUI, I experienced many of the challenges that developers face when building real-world cross-platform applications.

Building a production application is much more than creating pages and connecting buttons.

You eventually need to think about:

Networking
API reliability
Localization
Application health
Updates
Geolocation
Storage
MVVM
Messaging
Performance
Memory management
Background processing
Platform-specific behavior
Logging
Diagnostics
Architecture
Developer tooling

Many of these problems are common across applications.

That makes them good candidates for reusable libraries.

This became one of the motivations behind building a collection of MAUI-focused tools and NuGet packages.

Instead of solving the same problem separately in every application, the goal is to create reusable building blocks that developers can adopt in their own projects.

Open source as a learning process

For me, open source is not only about publishing code.

It is also about learning.

When code exists only inside a private project, it is easy to make assumptions.

When you publish it publicly, you start looking at it differently.

You begin asking:

Is this API understandable?

Can another developer use this without knowing the original project?

Is the documentation good enough?

Does the package name make sense?

What happens when someone uses this differently than I expected?

Those questions make the software better.

Open source creates a different kind of feedback loop.

You build.

You publish.

You receive feedback.

You discover problems.

You improve.

Then you publish again.

That cycle is one of the most valuable parts of building NuvyntraLabs.

From repositories to an ecosystem

At some point, NuvyntraLabs started becoming more than a collection of GitHub repositories.

There were multiple libraries.

There were NuGet packages.

There were developer utilities.

There were toolkits.

There were ideas for CLI tools.

There were experiments around AI-assisted development.

And there was a growing need for proper documentation.

That led to the creation of the NuvyntraLabs website and documentation ecosystem.

The goal was to make the projects easier to discover.

A developer should not have to search through dozens of repositories to understand what exists.

Instead, the ecosystem should provide a clear entry point.

What is the project?

What problem does it solve?

How do I install it?

How do I use it?

Is it actively maintained?

Where can I contribute?

These questions became increasingly important.

Building in public

One of the things I want NuvyntraLabs to represent is the idea of building in public.

Not everything needs to be perfect before it is shared.

A project can start small.

A library can begin with a single feature.

A CLI tool can begin as an experiment.

An idea can be published, discussed, improved, or even abandoned.

That is part of software development.

I don't want NuvyntraLabs to be a place where everything looks artificially perfect.

I want it to reflect the real process of engineering.

Ideas become prototypes.

Prototypes become tools.

Tools become libraries.

Libraries become packages.

Packages become part of applications.

And sometimes an experiment teaches us something valuable even if it never becomes a product.

Why the name NuvyntraLabs?

The name represents the direction I wanted to take.

NuvyntraLabs is intentionally broader than a single product.

It is a lab.

A place for experimentation.

A place for engineering.

A place where ideas can be tested.

A place where reusable software can be created.

And a place where developers can discover and contribute to projects.

The “Labs” part is important.

Not every project needs to become a commercial product.

Some projects exist simply because they are interesting problems to solve.

Some exist because developers need them.

Some exist to explore a new technology.

Some may eventually grow into something much larger.

That freedom is important.

The role of AI

The software-development landscape is changing rapidly.

AI coding assistants and coding agents are becoming an increasingly important part of how developers build software.

This creates another interesting challenge for open source.

It is no longer enough for a library to exist somewhere on GitHub.

Developers increasingly discover software through AI tools.

That means libraries need to be understandable not only to humans browsing documentation, but also to tools that help developers find and use software.

Clear documentation, meaningful examples, good APIs, package metadata, source code, README files, and structured information all become more important.

This is an area I want NuvyntraLabs to explore further.

The goal is not simply to build software for developers.

It is also to make that software easier for developers — and their AI development tools — to discover and understand.

The community vision

A developer ecosystem cannot be built around code alone.

It needs people.

That is why community is becoming an important part of NuvyntraLabs.

The vision is to create a space where developers can:

Discuss .NET MAUI
Share solutions
Explore open-source projects
Exchange ideas
Ask technical questions
Share developer experiences
Discover useful tools
Contribute to projects
Learn from each other

The community should not be limited to people who already contribute code.

Someone discovering their first MAUI library is part of the ecosystem.

Someone reporting a bug is part of the ecosystem.

Someone suggesting an improvement is part of the ecosystem.

Someone writing documentation is part of the ecosystem.

Someone simply sharing their experience can contribute value.

Open source becomes stronger when participation is broader than just commits.

What NuvyntraLabs is becoming

Today, NuvyntraLabs is still evolving.

There are many ideas.

Some are already implemented.

Some are experiments.

Some are being improved.

Some may change direction.

And that is okay.

The objective is not to create hundreds of projects simply to have hundreds of projects.

The objective is to build useful software.

Over time, I want NuvyntraLabs to grow around several areas:

Developer Libraries

Reusable libraries and NuGet packages that solve common development problems.

.NET MAUI Toolkits

Practical components and utilities for developers building cross-platform applications.

Developer Tools

CLI tools and utilities that make everyday development tasks easier.

AI-Assisted Development

Exploring how AI agents can discover, understand, use, and contribute to open-source software.

Community

A place where developers can communicate, collaborate, and learn.

Open Source

Projects that developers can inspect, use, improve, and contribute to.

The journey is more important than the destination

There is still a long way to go.

The ecosystem will change.

Projects will evolve.

Some repositories will become more important.

Some will eventually become obsolete.

New technologies will appear.

.NET MAUI will continue to evolve.

AI will continue changing how software is built.

And NuvyntraLabs will need to evolve along with them.

That is actually one of the things I find exciting.

NuvyntraLabs is not intended to be a finished product.

It is a continuous engineering journey.

Every library teaches something.

Every issue provides feedback.

Every contribution adds perspective.

Every new developer who discovers a project creates another opportunity to improve it.

The bigger idea

At its heart, NuvyntraLabs is built around a simple philosophy:

Create useful things. Share them openly. Learn from the community. Keep improving.

It started with individual development problems.

It grew into reusable libraries.

Those libraries became open-source projects.

The projects became NuGet packages.

The packages became a collection.

The collection became an ecosystem.

And now the ecosystem is becoming a community.

That evolution was not planned from day one.

It happened naturally through the process of building.

And perhaps that is the most interesting part of the story.

NuvyntraLabs is not just the story of a brand.

It is the story of a developer continuing to build, experiment, learn, and share.

And this is only the beginning.

Welcome to NuvyntraLabs.

Build. Share. Learn. Evolve.

By Admin

.NET MAUI Ecosystem: Building More Than Just Cross-Platform Apps

NuvyntraLabs — Wed, 23 Sep 2026 05:15:41 +0000

The world of application development has changed dramatically over the last decade. Developers are no longer building applications for a single operating system or a single type of device. Modern applications are expected to work across multiple platforms, communicate with cloud services, operate reliably with limited connectivity, integrate with device capabilities, and provide a consistent user experience.

In the .NET world, .NET MAUI has become an important part of this cross-platform development story.

But .NET MAUI is much more than a UI framework.

The real strength of .NET MAUI comes from the ecosystem around it — libraries, NuGet packages, architecture patterns, developer tools, backend technologies, cloud services, community projects, testing frameworks, and the developers who continuously build and share solutions.

This is the story of the .NET MAUI ecosystem.

What Is .NET MAUI?

.NET MAUI (Multi-platform App UI) is Microsoft's framework for building native applications using .NET and C# from a shared codebase.

With .NET MAUI, developers can target platforms such as:

Android
iOS
macOS
Windows

Instead of maintaining completely separate application projects for every platform, developers can share a significant portion of their application code while still accessing platform-specific functionality when required.

This approach makes .NET MAUI particularly interesting for teams that already have experience with:

C#
.NET
ASP.NET Core
Azure
Microsoft development tools
Visual Studio
NuGet

However, a framework alone does not create a successful application.

That is where the ecosystem becomes important.

.NET MAUI Is an Ecosystem, Not Just a Framework

When developers hear ".NET MAUI," they often think about XAML, controls, layouts and C#.

Those are certainly important.

But a production application usually needs much more.

A typical MAUI application may require:

                    .NET MAUI Application
                            │
        ┌───────────────────┼───────────────────┐
        │                   │                   │
       UI              Architecture          Platform
        │                   │                   │
   XAML / C#           MVVM / DI          Android / iOS
        │                   │                   │
        ├────────────── Libraries ───────────────┤
        │                   │                   │
     Networking         Database             Storage
        │                   │                   │
     Security          Telemetry            Logging
        │                   │                   │
        └────────────── Cloud / APIs ────────────┘
                            │
                     Developer Tools
                            │
                     CI/CD & Releases

The ecosystem fills the gaps between the framework and a complete production application.

The Foundation: .NET

One of the biggest advantages of MAUI is that it sits on top of the broader .NET platform.

A MAUI developer is not limited to APIs specifically created for mobile applications.

They can use the enormous .NET ecosystem.

This includes technologies such as:

.NET libraries
NuGet
Dependency Injection
Configuration
Logging
HTTP
JSON serialization
Cryptography
LINQ
Tasks and async programming
Generic Host concepts
ASP.NET Core
Entity Framework Core
Azure SDKs

This creates an important advantage.

A developer can build an architecture where the mobile application and backend share common concepts, models, libraries and development practices.

NuGet: The Package Ecosystem

One of the most important components of the .NET ecosystem is NuGet.

NuGet allows developers to package reusable functionality and distribute it to other .NET developers.

For MAUI developers, this can dramatically reduce development time.

Instead of building everything from scratch, developers can use packages for:

HTTP networking
REST APIs
Authentication
Logging
Analytics
Localization
Maps
Storage
SQLite
UI controls
MVVM
Dependency injection
Permissions
Device information
Connectivity
Performance monitoring
Application updates
Push notifications

This creates a network effect.

A developer solves a problem once.

They publish the solution.

Another developer discovers it.

The second developer provides feedback.

The library improves.

Eventually, the entire ecosystem benefits.

The Role of Open Source

Open source is one of the most important forces behind the MAUI ecosystem.

Developers can create libraries, tools and frameworks and share them with the community.

This is particularly valuable for problems that are common across applications.

For example:

"How do I handle API retries?"

"How do I implement localization?"

"How do I monitor memory leaks?"

"How do I create a reusable validation framework?"

"How do I manage application updates?"

"How do I simplify MVVM?"

These problems do not need to be solved independently by every development team.

Open-source projects allow developers to share solutions.

Community Libraries

The ecosystem contains libraries created by Microsoft, commercial vendors, independent developers and community organizations.

This diversity is important.

A developer can combine:

.NET MAUI
   +
Community Libraries
   +
NuGet Packages
   +
Custom Components
   +
Platform APIs
   +
Cloud Services

to create a complete application platform tailored to their requirements.

This is one of the reasons the MAUI ecosystem continues to evolve beyond the core framework.

UI Component Ecosystem

Building a modern application often requires more than the standard controls.

Developers may need:

Advanced grids
Charts
Data visualization
PDF viewers
Rich editors
Calendars
Schedulers
Data forms
Image processing
Barcode scanning
Maps
Custom navigation
Advanced pickers

This is where commercial and community UI libraries become valuable.

Companies such as Syncfusion and Telerik, along with many open-source projects, provide additional controls and components for .NET MAUI applications.

This gives development teams more options than the controls included in the base framework.

MVVM and Application Architecture

A large application cannot be maintained effectively by putting everything inside a page's code-behind.

Architecture becomes essential.

Common patterns used with MAUI include:

MVVM
Dependency Injection
Repository pattern
Service-based architecture
Clean Architecture
Modular architecture
Event-driven approaches

MVVM remains particularly common in the MAUI ecosystem.

A simplified architecture might look like:

View
 │
 ▼
ViewModel
 │
 ▼
Application Services
 │
 ▼
Repositories
 │
 ▼
API / Database

This separation makes applications easier to test, maintain and evolve.

Networking

Almost every modern mobile application communicates with a backend.

Therefore networking is a major part of the MAUI ecosystem.

Applications commonly interact with:

REST APIs
GraphQL APIs
WebSockets
SignalR
gRPC
Cloud services

Developers can use technologies such as HttpClient, HttpClientFactory, Refit-style libraries, serialization libraries and custom networking abstractions.

Production applications also need to consider:

Retry policies
Timeout handling
Offline scenarios
Authentication
Token refresh
Request cancellation
Network monitoring
Error handling

The networking layer can become an ecosystem of its own.

Offline-First Applications

One of the interesting areas of MAUI development is offline-first architecture.

Mobile applications cannot always assume that the network is available.

Users may:

Lose connectivity
Move between networks
Enter low-signal areas
Use applications while travelling
Need to work with cached information

An offline-first application can use:

User
  │
  ▼
MAUI Application
  │
  ├── Local Database
  │
  ├── Local Cache
  │
  └── Sync Engine
          │
          ▼
       Backend

The application can continue working locally and synchronize changes when connectivity returns.

This creates opportunities for specialized libraries and frameworks around:

Data synchronization
Conflict resolution
Local caching
Background synchronization
Incremental synchronization

These are important areas for enterprise MAUI applications.

Database Ecosystem

MAUI applications can use several types of data storage.

For local storage, developers may use:

SQLite
Preferences
Secure storage
Files
Local caches

For remote storage, applications may communicate with:

SQL Server
PostgreSQL
MySQL
MongoDB
Azure services
Firebase
REST APIs
GraphQL services

A well-designed application usually keeps the database implementation behind an abstraction rather than allowing the UI to directly access storage.

Cloud Integration

Modern mobile applications rarely operate independently.

They are usually part of a larger cloud architecture.

A MAUI application can communicate with:

Azure
AWS
Google Cloud
Firebase
Custom APIs
Serverless functions
Cloud databases
Identity platforms

A typical architecture could look like:

               Mobile Application
                      │
                      ▼
                 API Gateway
                      │
             ┌────────┴────────┐
             │                 │
          Backend          Authentication
             │                 │
       ┌─────┴─────┐           │
       │           │           │
   Database      Storage    Identity

This makes MAUI a client technology within a much larger application ecosystem.

Authentication and Security

Security cannot be treated as an optional feature.

Production applications commonly require:

OAuth
OpenID Connect
JWT
Secure token storage
Biometric authentication
Certificate handling
Encryption
Secure API communication
Application secrets management

MAUI provides access to platform security capabilities, while the wider .NET ecosystem provides libraries and services for implementing secure application architectures.

Device Capabilities

One of the defining characteristics of mobile applications is their ability to interact with the device.

MAUI applications can work with capabilities such as:

Camera
Microphone
GPS
Bluetooth
Sensors
Notifications
Contacts
Phone functionality
Files
Network information
Battery information

Sometimes the abstraction provided by MAUI is sufficient.

Sometimes an application needs platform-specific implementation.

That is not a weakness of the ecosystem.

It is a natural part of cross-platform development.

A good MAUI architecture allows shared code and platform-specific code to coexist.

Platform-Specific Development

"Write once, run everywhere" does not mean "everything behaves identically everywhere."

Android, iOS, macOS and Windows have different operating-system behaviors.

For example:

                 Shared MAUI Code
                       │
       ┌───────────────┼───────────────┐
       │               │               │
    Android           iOS            Windows
       │               │               │
 Android APIs      Apple APIs     Windows APIs

The MAUI ecosystem therefore includes platform-specific development.

Understanding native platforms remains valuable.

A strong MAUI developer benefits from knowing:

Android lifecycle
iOS lifecycle
Permissions
Background execution
Notifications
App signing
Platform APIs
Native debugging

MAUI reduces duplication, but it does not eliminate the importance of platform knowledge.

Testing

A mature ecosystem also needs testing.

MAUI applications can benefit from multiple layers of testing:

Unit Tests
    ↓
Service Tests
    ↓
ViewModel Tests
    ↓
Integration Tests
    ↓
UI Tests
    ↓
Device Testing

Testing becomes particularly important when applications target multiple operating systems.

A feature that works on Android may still behave differently on iOS or Windows.

Therefore, cross-platform testing is an important part of the ecosystem.

CI/CD and App Distribution

Building an application is only part of the journey.

Eventually, the application needs to reach users.

MAUI projects can integrate with CI/CD platforms such as:

GitHub Actions
Azure DevOps
Codemagic
Other cloud build systems

A typical pipeline may perform:

Git Push
   ↓
Restore
   ↓
Build
   ↓
Test
   ↓
Sign
   ↓
Package
   ↓
Publish

For mobile applications, signing and distribution add another level of complexity.

Developers need to manage:

Android signing
iOS certificates
Provisioning profiles
App Store configuration
Google Play configuration
Versioning
Release channels

The ecosystem around build automation is therefore just as important as the application framework itself.

Observability

Production applications need visibility.

When an application is running on thousands of devices, developers need answers to questions such as:

Is the application crashing?
Which API is failing?
Which version has the problem?
How long are requests taking?
Which devices are affected?
Are users experiencing synchronization failures?

This creates another ecosystem around:

Logging
Crash reporting
Metrics
Distributed tracing
Application telemetry
OpenTelemetry
Cloud monitoring

Observability transforms an application from a black box into something developers can understand and improve.

Localization

Global applications need localization.

Localization is more than translating strings.

It can involve:

Language
Date formats
Number formats
Currency
Time zones
Right-to-left layouts
Cultural conventions

This creates opportunities for specialized localization libraries and developer tooling.

For organizations building applications for multiple markets, localization can become a core part of the architecture.

Developer Tooling

The ecosystem is also about developer productivity.

Developers increasingly use:

CLI tools
Code generators
Project templates
Analyzers
Source generators
AI coding assistants
Documentation generators
Build automation tools

The future MAUI ecosystem will likely include more specialized tools that automate repetitive development tasks.

For example:

Developer
   │
   ├── CLI Tools
   ├── AI Assistants
   ├── Templates
   ├── Generators
   ├── Analyzers
   └── Automation
            │
            ▼
       MAUI Project

The Rise of AI-Assisted Development

AI is changing how developers discover and consume libraries.

Developers increasingly ask AI coding assistants questions such as:

"What NuGet package can I use for this?"

"How do I implement this in .NET MAUI?"

"Show me an example using this library."

This creates a new challenge for library authors.

Having a package published on NuGet is no longer enough.

Projects need to be discoverable through:

Good documentation
Clear README files
API references
Code examples
Search-friendly terminology
GitHub metadata
NuGet metadata
Structured documentation
AI-friendly project information

The ecosystem is therefore becoming both developer-readable and machine-readable.

Documentation Is Part of the Ecosystem

A library without documentation is difficult to adopt.

Good documentation should answer:

What problem does this project solve?
Who should use it?
How do I install it?
How do I configure it?
How do I use it?
What platforms are supported?
What are the limitations?
Where can I report issues?
How can I contribute?

For open-source projects, documentation is not secondary work.

It is part of the product.

Community Matters

Technology ecosystems are ultimately built by people.

Developers share:

Libraries
Tutorials
Blog posts
Videos
GitHub repositories
Bug fixes
Discussions
Samples
Conference talks
Community projects

A healthy ecosystem encourages developers to move from consumers to contributors.

Someone might begin by installing a NuGet package.

Later, they report an issue.

Then they submit a pull request.

Eventually, they may create their own library.

That cycle is how ecosystems grow.

NuvyntraLabs and the .NET MAUI Ecosystem

Projects such as NuvyntraLabs can become part of this larger ecosystem by creating open-source tools, libraries and developer resources around .NET MAUI.

The goal does not need to be replacing existing frameworks.

Instead, the focus can be on solving the practical problems developers encounter while building real applications.

This can include:

MAUI toolkits
NuGet libraries
Developer CLI tools
Localization utilities
Networking helpers
Application utilities
MVVM tools
Performance utilities
Developer documentation
Samples
Community projects

The value of an ecosystem comes from the connections between these projects.

One library can complement another.

A CLI tool can automate a library's setup.

Documentation can teach developers how to combine them.

Community members can contribute improvements.

Building an Ecosystem Step by Step

An ecosystem does not need hundreds of projects on day one.

It can start with one useful library.

Then another.

Then documentation.

Then examples.

Then developer tools.

Then community participation.

A possible progression looks like:

          Useful Library
                 │
                 ▼
          Documentation
                 │
                 ▼
             Examples
                 │
                 ▼
          Developer Tools
                 │
                 ▼
             Community
                 │
                 ▼
           Contributions
                 │
                 ▼
          Growing Ecosystem

This approach creates sustainable growth.

What Does the Future Look Like?

The MAUI ecosystem is likely to continue evolving alongside the broader .NET ecosystem.

Several areas are particularly interesting:

AI-assisted development

AI coding assistants can make it easier to discover, understand and integrate MAUI libraries.

Developer automation

CLI tools and generators can reduce repetitive application-development tasks.

Offline-first applications

As applications become more distributed, synchronization and local-first architectures will remain important.

Observability

Production applications will increasingly require built-in telemetry and diagnostics.

Cross-platform tooling

Developers will continue looking for ways to reduce platform-specific complexity without losing access to native capabilities.

Open-source collaboration

Community libraries will continue filling specialized requirements that cannot all be addressed by a single framework.

The Bigger Picture

.NET MAUI should not be viewed simply as:

"A framework for making Android and iOS applications."

It is better understood as one component of a larger technology ecosystem.

That ecosystem includes:

                         .NET
                          │
                       .NET MAUI
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
       UI            Architecture       Platforms
        │                 │                 │
        ├────────────── Libraries ──────────┤
        │                 │                 │
     NuGet            Open Source         Cloud
        │                 │                 │
        ├──────────── Developer Tools ──────┤
        │                 │                 │
       AI                CI/CD          Observability
        │                 │                 │
        └──────────── Community ────────────┘

Every component contributes to the developer experience.

Conclusion

The future of .NET MAUI is not only about the features included in the framework itself.

It is about what developers build around it.

Libraries make development faster.

NuGet makes distribution easier.

Open source makes collaboration possible.

Cloud services extend application capabilities.

CI/CD makes delivery repeatable.

Observability makes production applications understandable.

AI makes discovery and development increasingly accessible.

And communities bring everything together.

That is what makes an ecosystem powerful.

For developers, the opportunity is not simply to consume the ecosystem.

It is to contribute to it.

Build a library.

Create a tool.

Write documentation.

Publish a sample.

Fix an issue.

Share an idea.

Help another developer.

Every contribution, large or small, can become part of the larger .NET MAUI ecosystem.

Build. Share. Collaborate. Contribute.

That is how an ecosystem grows.

By Admin