DEV Community: NuvyntraLabs

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

Geofence 1.1.0: Enter, Exit, and Dwell Inside Twenty Circular Regions

NuvyntraLabs — Thu, 24 Sep 2026 11:04:52 +0000

A depot app does not need a new GPS fix every few seconds. It needs to know when the device crosses a circle drawn around the yard.

Plugin.Maui.Geofence is that monitor. Version 1.1.0 is on nuget.org. You register named circular regions. The operating system reports enter, exit, and dwell. The list is written to app-private storage and registered again after the process dies.

This post is the walkthrough: how to register the plugin, add a region, read a transition, and which permissions the host still has to request.

What Geofence is

Geofence is a circular-region monitor for .NET MAUI on Android and iOS. MIT licensed. It targets net10.0, net10.0-android (API 21+), and net10.0-ios (15+). Mac Catalyst and Windows are not primary targets.

It does one job: answer when the user enters, exits, or dwells in up to 20 named regions.


Package	`Plugin.Maui.Geofence` 1.1.0
Registration	`UseGeofence`
Client	`IGeofence`, or `Geofence.Current`
Platforms	Android `GeofencingClient`, iOS `CLCircularRegion`
Source	github.com/nuvyntralabs/Plugin.Maui.Geofence
Docs	nuvyntralabs.github.io/packages/plugin-maui-geofence/

A current position, a tracking session, and reverse geocoding stay on Plugin.Maui.GeoLocator. Geofence does not draw a map.

Install and register

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

using Plugin.Maui.Geofence;

builder
    .UseMauiApp<App>()
    .UseGeofence(options =>
    {
        options.MaxRegions = 20;
        options.MinimumRadiusMeters = 50;
    });

UseGeofence loads plugin.maui.geofence.regions.tsv from app data and re-registers those regions with the OS. Resolve IGeofence from dependency injection, or use Geofence.Current after registration. Calling Current before UseGeofence throws.

A radius of zero is replaced with DefaultRadiusMeters (100). A radius below MinimumRadiusMeters is rejected. Replacing a region that already has the same id does not consume another slot.

Add a region

var result = await Geofence.Current.AddAsync(new GeofenceRegion
{
    Id = "depot",
    Latitude = 12.97,
    Longitude = 77.59,
    RadiusMeters = 150,
    NotifyOnEntry = true,
    NotifyOnExit = true,
    NotifyOnDwell = true,
    Dwell = TimeSpan.FromMinutes(5)
});

if (!result.Succeeded)
{
    // result.Status: Denied, LimitReached, InvalidRadius, InvalidId, NotSupported
}

AddAsync returns a typed result. A missing location permission is Denied. Missing Play services is NotSupported. The 21st distinct id is LimitReached. An empty id is InvalidId. The call does not throw because the user said no.

Read a transition

Geofence.Current.Transition += (_, args) =>
{
    // args.RegionId, args.Kind: Enter, Exit, or Dwell
};

OS events queue until something subscribes to Transition. Attach the handler before you expect the first crossing, including crossings that happened while the process was down.

Android dwell uses GEOFENCE_TRANSITION_DWELL and a loitering delay of at least 60 seconds. iOS has no loitering delay. After enter, the plugin starts a timer and cancels it on exit.

Samples and tests can fire the same event without moving the device:

Geofence.Current.Raise(GeofenceTransitionKind.Enter, "depot");

GetMonitoredAsync lists the regions still stored. RemoveAsync and RemoveAllAsync drop them from the store and from the OS.

Permissions the host still requests

The plugin does not prompt. Declare the usage strings, then request location 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" />
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />

AddAsync needs fine location while the app is in use. Background transitions on Android 10+ also need ACCESS_BACKGROUND_LOCATION and the Play disclosure your listing already requires.

iOS, in Platforms/iOS/Info.plist:

<key>NSLocationWhenInUseUsageDescription</key>
<string>This app monitors geofences while you use it.</string>
<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>This app monitors geofences when the app is in the background.</string>
<key>UIBackgroundModes</key>
<array>
    <string>location</string>
</array>

Background enter and exit on CLCircularRegion need Always authorization. Denied or Restricted comes back as Denied.

When something looks wrong

What you see	What to do
`InvalidId`	`Id` is blank. Every region needs a stable name.
`InvalidRadius`	Radius is below `MinimumRadiusMeters` (50 by default).
`LimitReached`	Twenty distinct ids are already monitored. Replace an id or remove one.
`Denied`	Location permission is missing, or iOS authorization is Denied or Restricted.
`NotSupported`	Play services are missing on Android.
No event after a crossing	Nothing is subscribed to `Transition` yet, or background location was never granted.
Regions vanish after a kill	`UseGeofence` was not called on the next launch, so the TSV was never re-registered.

Where Geofence sits next to the other tools

Need	Tool
Enter, exit, and dwell for up to 20 circles	Geofence — `Plugin.Maui.Geofence`
A current fix, a tracking session, reverse geocoding	Plugin.Maui.GeoLocator
A measured offline trip against a vehicle meter	GPSSensorTrackingService

Play GeofencingClient, CLCircularRegion, and Shiny are the usual native and community choices when the app already speaks one of those APIs. Geofence is the client when the same IGeofence has to run on Android and iOS, cap the list at 20, and reload it after process death.

Try it

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

Register UseGeofence, add one region with a radius of at least 50 meters, and subscribe to Transition before you leave the yard. samples/Plugin.Maui.Geofence.Sample requests location, adds a region, lists the persisted set, and simulates enter, exit, and dwell with Raise().

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

By Admin

LeakAnalyser 1.0.1: See Which MAUI View Survives After You Pop It

NuvyntraLabs — Thu, 24 Sep 2026 11:02:43 +0000

A page that leaves the navigation stack should become collectable. If a handler, a binding, or a static root still points at it, the next push pays for the last one.

Plugin.Maui.LeakAnalyser answers that one question. Version 1.0.1 is on nuget.org. After a view looks finished, it holds a WeakReference, forces GC, and reports whether the object is still alive. Detection stays in Debug. Teardown can stay in Release.

This post is the walkthrough: detect-only in Debug, disconnect handlers when you are ready, and which pages you must suppress because they are cached on purpose.

What LeakAnalyser is

LeakAnalyser is a liveness test for .NET MAUI pages and views on Android, iOS, Mac Catalyst, and Windows. MIT licensed. It targets net10.0, net10.0-android (API 21+), net10.0-ios and net10.0-maccatalyst (15+), and net10.0-windows (10.0.17763+; the Windows TFM is included when the package is packed on Windows).

It does one job: report that a finished view is still rooted. A profiler tells you why.


Package	`Plugin.Maui.LeakAnalyser` 1.0.1
Registration	`UseLeakAnalyser`
Monitor	`LeakMonitor.Cascade`
Teardown	`TearDown.Cascade` with `DisconnectHandlers` or `Compartmentalize`
Source	github.com/nuvyntralabs/Plugin.Maui.LeakAnalyser
Docs	nuvyntralabs.github.io/packages/plugin-maui-leak-analyser/
Guides	Get started · How it works

The API is UseLeakAnalyser, LeakMonitor, TearDown, and LeakGraph. It is inspired by AdamE.MemoryToolkit.Maui. It is not a drop-in fork of that toolkit. 1.0.1 does not change the API.

Debug: detect only

Forced GC is a probe. Keep UseLeakAnalyser and LeakMonitor.Cascade inside DEBUG.

using Plugin.Maui.LeakAnalyser;

#if DEBUG
builder.Logging.AddDebug();
builder.UseLeakAnalyser(options =>
{
    options.OnLeaked = target => { /* alert, using target.Name */ };
    options.DefaultTearDownStrategy = TearDownStrategy.DetectOnly;
});
#endif

<ContentPage xmlns:la="clr-namespace:Plugin.Maui.LeakAnalyser;assembly=Plugin.Maui.LeakAnalyser"
             la:LeakMonitor.Cascade="True"
             la:LeakMonitor.Name="OrdersPage">

OnLeaked fires when the target is still alive after the collection passes. OnCollected fires when it is collected. Collection is the healthy outcome. CollectionTarget carries Name, ObjectType, and Screen. Defaults are 10 collections, 200 milliseconds apart.

The monitor waits until the view looks finished: a page popped from an active NavigationPage, a detached template, or a short wait that skips anything still on the navigation stack, still hosted by Shell, or still under a tab. Cached pages and tabs stay alive on purpose. Suppress those, or they look like leaks.

Disconnect handlers

DisconnectHandlers is the default when you omit Strategy. It walks children and calls DisconnectHandler(). It leaves BindingContext, Content, and Parent in place. It honors HandlerDisconnectPolicy.Manual and TearDown.Suppress.

Put TearDown after LeakMonitor so teardown does not run before the snapshot.

la:LeakMonitor.Cascade="True"
la:TearDown.Cascade="True"
la:TearDown.Strategy="DisconnectHandlers"

The same attached properties exist in C#: LeakMonitor.SetCascade, TearDown.SetCascade, page.Monitor(), and page.TearDown(TearDownStrategy.DisconnectHandlers).

In Release, teardown can stay on without detection:

la:TearDown.Cascade="True"

Do not call UseLeakAnalyser or set LeakMonitor.Cascade in Release.

Compartmentalize

Compartmentalize clears common managed references, runs TearDown.OnTearDown while the element still has a handler, then disconnects. Each clear is isolated. A throwing setter is logged and teardown continues.

It clears BindingContext, Parent, logical children, behaviors, resources, gesture recognizers, formatted text, item sources, and Content on content views, borders, pages, and scroll views. CommunityToolkit hooks stay, because they are attached properties.

Opt into it per page. A Shell flyout or a NavigationPage that still holds modals will blank if this runs too early.

la:TearDown.Strategy="Compartmentalize"

A breadcrumb, not a crash

LeakAnalyser does not reference Diagnostics or Observability. Forward OnLeaked yourself when the host already has those plugins. Register Diagnostics first if you want its logger ready before the first callback.

#if DEBUG
builder.UseMauiDiagnostics();
builder.UseLeakAnalyser(options =>
{
    options.OnLeaked = target =>
    {
        MauiDiagnostics.TrackEvent($"Leak:{target.Name}");
        MauiDiagnostics.TrackException(
            new InvalidOperationException($"{target.Name} survived forced GC."));
    };
});
#endif

Track OnLeaked only. A collected target is success. Forced GC counts are not an app-health signal.

When something looks wrong

What you see	What to do
Every Shell tab reports a leak	Cached pages stay alive on purpose. `LeakMonitor.SetSuppress` and `TearDown.SetSuppress` on that host.
A leak appears while the browser sheet is open	Temporary unloads such as `Browser.OpenAsync` should suppress the host `NavigationPage`, then clear Suppress on `Loaded`.
A template root leaks and the page does not	Put `Cascade` on each `ControlTemplate` root, not only on the host control.
`OnLeaked` names the page and you still do not know the root	Open Instruments, dotMemory, or Visual Studio diagnostics. This package reports liveness.
Release builds feel slower after navigation	`LeakMonitor.Cascade` or `UseLeakAnalyser` is still compiled into Release. Detection forces GC.

Where LeakAnalyser sits next to the other tools

Need	Tool
Is this finished view still alive?	LeakAnalyser — `Plugin.Maui.LeakAnalyser`
The retain path	Instruments, dotMemory, or Visual Studio diagnostics
Crash, ANR, and breadcrumbs	Plugin.Maui.Diagnostics
Startup, page, and API timings	Plugin.Maui.Performance

AdamE.MemoryToolkit.Maui is the usual community toolkit for the same class of problem. LeakAnalyser is the package when you want LeakMonitor plus an optional DisconnectHandlers or Compartmentalize pass, and you already accept that the retain path lives in a profiler.

Try it

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

In Debug, call UseLeakAnalyser with TearDownStrategy.DetectOnly, set LeakMonitor.Cascade and LeakMonitor.Name on one page, pop it, and read OnLeaked or OnCollected.

NuGet: Plugin.Maui.LeakAnalyser
Repository: github.com/nuvyntralabs/Plugin.Maui.LeakAnalyser
Package page: nuvyntralabs.github.io/packages/plugin-maui-leak-analyser/
How it works: nuvyntralabs.github.io/packages/plugin-maui-leak-analyser/docs/

By Admin

SmartUpload 1.0.7: Resume a File Upload After the Process Dies

NuvyntraLabs — Thu, 24 Sep 2026 08:54:20 +0000

A field photo that dies halfway through one POST has to start again from byte zero. The next launch has no record of what the server already accepted.

Plugin.Maui.SmartUpload keeps that record. Version 1.0.7 is on nuget.org. The file is sent in slices. Each acknowledged offset is written to disk. After a crash, pause, or retry, the next attempt continues from that offset.

This post is the walkthrough: how to register the client, enqueue a file, which wire protocol to pick, and what still belongs to the host when the transfer has to keep running after the UI is gone.

What SmartUpload is

SmartUpload is the chunked upload client for .NET MAUI on Android, iOS, Mac Catalyst, and Windows. MIT licensed. It targets net10.0, net10.0-android (API 21+), net10.0-ios and net10.0-maccatalyst (15+), and net10.0-windows (10.0.17763+). 1.0.7 adds the Mac Catalyst and Windows target frameworks for the shared implementation.

It does one job: move a file in resumable chunks and remember how far the server got.


Package	`Plugin.Maui.SmartUpload` 1.0.7
Registration	`UseSmartUpload`
Client	`ISmartUploadClient`, or `SmartUpload.Current`
Protocols	Content-Range (default), tus 1.0, or `IUploadProtocol`
Source	github.com/nuvyntralabs/Plugin.Maui.SmartUpload
Docs	nuvyntralabs.github.io/packages/plugin-maui-smart-upload/

The acknowledged offset survives process death. The operating system does not keep sending bytes after the process is gone. A transfer that must continue with the UI closed still needs a host foreground service on Android, or a host NSURLSession background configuration on iOS. SmartUpload is what those hosts resume from.

Install and register

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

builder
    .UseMauiApp<App>()
    .UseSmartUpload(options =>
    {
        options.EnableLogging = true;
        options.DefaultChunkSize = 512 * 1024;
        options.MaxConcurrentUploads = 2;
        options.ResumeInterruptedOnStart = true;
        options.RequireHttps = true;
        options.DefaultRetry = new RetryPolicy
        {
            MaxRetries = 5,
            InitialDelay = TimeSpan.FromSeconds(1),
            MaxDelay = TimeSpan.FromSeconds(30)
        };
    });

Resolve ISmartUploadClient from dependency injection, or call SmartUpload.Current.

DefaultChunkSize falls back to 1 MB when you leave it alone. The default is clamped between 64 KB and 32 MB. An explicit UploadRequest.ChunkSize must be positive and is capped at 32 MB. MaxConcurrentUploads defaults to 2; extra sessions stay Queued until a slot opens. HttpTimeout is 100 seconds per chunk.

ResumeInterruptedOnStart defaults to false. Set it, or call ResumeInterruptedAsync() yourself after launch. That call resumes sessions that were uploading when the process died, and any queued work that had AutoStart.

Enqueue a file

var client = SmartUpload.Current;

var session = await client.EnqueueAsync(new UploadRequest
{
    FilePath = photoPath,
    Endpoint = new Uri("https://uploads.example.com/files/"),
    Protocol = UploadProtocolKind.Tus,
    Headers =
    {
        ["Authorization"] = $"Bearer {accessToken}"
    },
    Metadata =
    {
        ["album"] = "field"
    }
});

FilePath is an absolute path. The file has to stay at that path, non-empty, until the session completes. Endpoint is required. For tus it is the creation URL; the client follows Location. For Content-Range it is the URL that receives each slice. Method defaults to PUT and applies only to Content-Range.

Protocol defaults to UploadProtocolKind.ContentRange. Omit it when the server speaks Content-Range. Set Tus for a tus 1.0 endpoint. FileName defaults to the file name. ContentType is inferred from the extension when omitted.

AutoStart defaults to true, so the session starts as soon as a concurrency slot is free. Set it false to persist the session and call StartAsync later.

SessionId is optional. When you supply one, it may contain only letters, digits, -, and _, and it cannot exceed 128 characters. Otherwise the client generates a GUID.

Pause, resume, and the session states

await client.PauseAsync(session.SessionId);
await client.ResumeAsync(session.SessionId);
await client.RetryAsync(session.SessionId);
await client.CancelAsync(session.SessionId);
await client.RemoveAsync(session.SessionId);

var all = await client.GetSessionsAsync();

PauseAsync stops after the current chunk is cancelled and keeps the offset. ResumeAsync continues a paused or interrupted session from the last acknowledged byte. RetryAsync starts a failed or cancelled session again from that same offset. CancelAsync leaves the record until RemoveAsync, which deletes it. GetSessionsAsync returns every persisted session, newest first.

State	Meaning
`Queued`	Waiting for a concurrency slot, or for `StartAsync`
`Uploading`	A chunk is in flight
`Paused`	Caller stopped it; the offset is on disk
`Completed`	The server accepted every byte
`Failed`	A non-retryable error, or retries ran out
`Cancelled`	Caller cancelled; the record remains until `RemoveAsync`

Progress is an immutable UploadSession plus UploadProgress.Fraction (BytesUploaded / TotalBytes, clamped to 0..1):

client.ProgressChanged += (_, e) =>
    Debug.WriteLine($"{e.Session.FileName}: {e.Progress.Fraction:P0}");

client.SessionCompleted += (_, e) =>
    Debug.WriteLine($"Done {e.Session.SessionId}");

client.SessionFailed += (_, e) =>
    Debug.WriteLine($"{e.Error}: {e.Message}");

SessionStateChanged fires as the session moves through the table above.

Two built-in protocols

Protocol	What the client sends
`ContentRange`	`PUT` or `POST` each slice with `Content-Range: bytes start-end/total`, `X-Upload-Id`, `X-Chunk-Index`, and `X-Chunk-Count`. An optional `HEAD` can return `Range` or `X-Last-Byte` so the client can catch up.
`Tus`	tus 1.0: `POST` to create, `HEAD` for `Upload-Offset`, `PATCH` with `application/offset+octet-stream`. `Metadata` is sent as `Upload-Metadata`.
`Custom`	`UploadRequest.CustomProtocol`, or `SmartUploadOptions.CustomProtocol`, implementing `IUploadProtocol`.

A Content-Range slice looks like this:

PUT /upload HTTP/1.1
Content-Range: bytes 0-1048575/10485760
Content-Length: 1048576
X-Upload-Id: 2f1c9a0e...
X-Chunk-Index: 0
X-Chunk-Count: 10

IUploadProtocol is the extension point: InitializeAsync, QueryRemoteProgressAsync, UploadChunkAsync, CompleteAsync, and AbortAsync. InitializeAsync has to be idempotent. The chunk stream length equals that slice.

DeleteRemoteOnCancel defaults to false. When it is true, a tus cancel sends DELETE if the server advertised the termination extension.

What is written to disk

Sessions are JSON files under FileSystem.AppDataDirectory/Plugin.Maui.SmartUpload/. Set StorageDirectory to move that folder, or set Store to replace the file store with your own IUploadStore.

Each record keeps the file path, size, last-write timestamp, endpoint, headers, protocol state (including the tus Location), and the acknowledged byte offset. On resume, a missing file fails with UploadError.FileNotFound. A different length or last-write time fails with UploadError.FileChanged. The client will not continue a session against a file that is no longer the one it started.

Headers are part of that JSON, including Authorization. A bearer token stored there is what the next request sends. Refresh it before resume when the token can expire while the app is dead.

HTTPS is the default

RequireHttps defaults to true. An http:// endpoint throws SmartUploadException with UploadError.InvalidRequest and the message Endpoint must be an https URL. Set RequireHttps to false to allow http.

That default shipped with the hardened 1.0.6 release and is still the 1.0.7 behavior. Set RequireHttps = false only for a local development server. On iOS, cleartext also needs an App Transport Security exception. The scheme has to be http or https either way.

The package declares INTERNET and ACCESS_NETWORK_STATE. Keep both if the host merges Android manifests by hand.

Retry

RetryPolicy.Default retries five times. The first wait is 1 second, the multiplier is 2, and the wait is capped at 30 seconds. Jitter lands between 80% and 120% of that delay. Status codes 408, 429, 500, 502, 503, and 504 are retryable, along with HttpRequestException, IOException, TimeoutException, and TaskCanceledException. OperationCanceledException stops the loop. A SmartUploadException retries only when it is marked retryable.

RetryPolicy.None sets MaxRetries to 0. A per-request UploadRequest.Retry overrides DefaultRetry.

When retries are exhausted, the session lands in Failed with the offset still on disk. RetryAsync starts again from that offset.

A client that does not touch `Current`

Tests can build an isolated client. SmartUpload.Create does not replace SmartUpload.Current.

using var client = SmartUpload.Create(new SmartUploadOptions
{
    Store = new MyStore(),
    HttpClient = httpClient,
    DefaultChunkSize = 64 * 1024,
    DefaultRetry = RetryPolicy.None
});

A caller-supplied HttpClient is not disposed by the plugin. samples/SmartUpload.Sample creates a 1 MB file, or picks one, and exercises tus or Content-Range with pause, resume, retry, and cancel.

When something looks wrong

What you see	What to do
`InvalidRequest`: endpoint must be https	The URL is `http://` and `RequireHttps` is still true. Use https, or set `RequireHttps = false` for local development only.
`FileNotFound` at enqueue	`FilePath` is missing, blank, or the file length is 0.
`FileChanged` on resume	The file was rewritten or replaced. Length and last-write time are part of the session. Start a new session for the new bytes.
`FileNotFound` on resume	The source file was deleted. The session cannot continue.
Progress stuck in `Queued`	`MaxConcurrentUploads` slots are full, or `AutoStart` is false and nothing called `StartAsync`.
Upload starts over after a kill	`ResumeInterruptedOnStart` is false and nothing called `ResumeInterruptedAsync`.
Session stays `Failed`	Retries are exhausted. Call `RetryAsync`. The offset is still stored.
Custom protocol rejected	`Protocol` is `Custom` and both `UploadRequest.CustomProtocol` and `SmartUploadOptions.CustomProtocol` are null.
Transfer dies when the user leaves the app	The offset is on disk. Continuing while the process is suspended is a host foreground service (Android) or `NSURLSession` background session (iOS).

Where SmartUpload sits next to the other tools

Need	Tool
Chunked file upload that resumes after process death	SmartUpload — `Plugin.Maui.SmartUpload`
JSON around the file: create the asset, confirm completion	Plugin.Maui.HttpForge
Retry, circuit breaker, and an offline queue for ordinary HTTP calls	Plugin.Maui.ApiResilience
Durable jobs with backoff and a dead-letter path	Plugin.Maui.JobQueue
Resize, strip EXIF, watermark, or encrypt before the file leaves the device	Plugin.Maui.MediaPipeline
Encrypted files at rest on the device	Plugin.Maui.FileVault

HttpForge [Multipart] is one POST. Use it for the JSON that books the upload and confirms it. Use SmartUpload for the bytes when a kill has to be recoverable. A small JSON call stays on HttpClient or ApiResilience.

MediaPipeline can finish a photo and leave a file path. That path is what EnqueueAsync takes. FileVault keeps a file encrypted on the device; SmartUpload sends a file to an endpoint.

A general-purpose tus client is the usual choice when the app is not a MAUI host, or when the organization already standardized on one. SmartUpload is the client when the same session API has to run on Android, iOS, Mac Catalyst, and Windows, and the offset has to be on disk after the process dies.

Try it

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

Register UseSmartUpload with RequireHttps = true and ResumeInterruptedOnStart = true. Enqueue one file with UploadProtocolKind.Tus or the default Content-Range protocol, then read ProgressChanged until SessionCompleted.

NuGet: Plugin.Maui.SmartUpload
Repository: github.com/nuvyntralabs/Plugin.Maui.SmartUpload
Sample: SmartUpload.Sample
Package page: nuvyntralabs.github.io/packages/plugin-maui-smart-upload/

By Niladri

Offline GPS Tracking and Haversine Distance

NuvyntraLabs — Wed, 23 Sep 2026 17:26:59 +0000

A field app that bills by the kilometre has to know how far the phone actually moved. A directions API answers a different question: the shortest road between two points.

GPSSensorTrackingService is a Kotlin Android proof that stays with the first question. The fused location provider delivers GPS fixes. A filter drops the ones that are noise. The distance between accepted fixes is added with the Haversine formula and written to a local database. The map draws that trace. Distance is computed on the device from those fixes.

What the proof is

The app is a field-survey tracker. A daily shift window starts and stops location capture. While the window is open, a foreground service records the route and a running total for that calendar day.


App	Field Survey POC · `com.fieldsurvey.poc`
Platform	Android 8+ (API 26) · Kotlin · Jetpack Compose
Location	Fused Location Provider, high-accuracy GPS
Distance	Haversine on accepted fixes, Earth radius 6,371 km
Storage	Room, one day log and its points per `YYYY-MM-DD`
Map	Google Maps polyline of the saved trace
Source	github.com/nuvyntralabs/GPSSensorTrackingService
Research	nuvyntralabs.github.io/research/gps-sensor-tracking-service/

Why the sample interval decides the distance

Two GPS points give the straight line between them. The road between them can be longer. A fix every ten minutes hides the bends:

Motion	Distance covered in 10 minutes
Walking, 5 km/h	833 m
Bicycle, 15 km/h	2.5 km
Car, 40 km/h	6.7 km
Highway, 80 km/h	13.3 km

A left turn, a U-turn, or a loop inside that gap becomes one chord. The total comes out short. Sampling every few seconds while the device is moving keeps those corners in the trace. Sampling slows down when the device is still, so a phone on a desk does not burn a GPS fix every few seconds for nothing.

A directions call on each leg has the opposite failure. It returns a plausible road, including roads the surveyor never drove, and it needs a network at sample time. This proof keeps the polyline as the filtered GPS trace.

Haversine, added as you go

Haversine is the great-circle distance on a sphere. For two latitudes and longitudes it is:

object Haversine {
    private const val EARTH_RADIUS_M = 6_371_000.0

    fun distanceMeters(
        lat1: Double, lon1: Double,
        lat2: Double, lon2: Double
    ): Double {
        val dLat = Math.toRadians(lat2 - lat1)
        val dLon = Math.toRadians(lon2 - lon1)
        val a = sin(dLat / 2).let { it * it } +
                cos(Math.toRadians(lat1)) * cos(Math.toRadians(lat2)) *
                sin(dLon / 2).let { it * it }
        return 2 * EARTH_RADIUS_M * asin(sqrt(a))
    }
}

Each accepted fix adds its metres to that day’s total in SQL, so a crash keeps the distance already counted:

UPDATE day_logs
   SET totalDistanceMeters = totalDistanceMeters + :deltaMeters,
       lastFixUtcMillis    = :timestampUtcMillis
 WHERE dateKey = :dateKey

The running total is kept incrementally. It is stored on the day row as each fix is accepted.

Three filters, or a parked phone invents kilometres

Raw GPS wanders. A phone left on a table drifts by metres. A bad fix can jump across town. Sum those segments and the day total grows while nobody moved.

GpsFilter accepts a fix only after three checks.

Accuracy. Medium mode drops anything worse than 30 m. High mode uses 20 m. Low mode uses 55 m.

Doppler speed. Position drifts while the receiver is still. Reported speed does not. A trustworthy speed under 0.5 m/s is treated as stationary and contributes 0 m. That threshold sits above the stationary noise floor and below a slow walk, so walking still counts.

Anchor. When speed is missing, the filter holds the last still point. Fixes inside max(20 m, accuracy × 1.5) are rejected. A jump past that radius has to repeat on a second fix before it counts, unless speed already says the device is moving. The counted distance starts from the anchor, so the first real metres are kept. A single spike cannot walk the anchor down the street.

Implied speed above 60 m/s (about 216 km/h) is dropped as a teleport.

The bug that straightened every corner

The first road test under-counted badly: about 1.87 km on a ride of about 4.8 km, with sharp turns and a U-turn.

The location callback kept LocationResult.lastLocation. The request also allowed the OS to batch fixes (setMaxUpdateDelayMillis at twice the interval). A batch arrived as one delivery, the callback kept the last point, and every turn inside that batch collapsed into a straight line.

The fix is both halves:

Walk result.locations in time order and run the filter on each fix.
Set setMaxUpdateDelayMillis(0) so fixes are delivered as they arrive.

Route vertices are saved on the first fix, on a heading change of 20° or more (the previous point is saved too, so the polyline bends at the corner), on stop and start, and at least every 60 seconds or 120 metres on a straight. After motion, fast sampling continues for 90 seconds, so a stop at a signal and the turn that follows are still in the trace.

Accuracy modes

Mode	Moving sample	Stationary sample	Max accuracy
High	4 s	20 s	20 m
Medium (default)	6 s	30 s	30 m
Low	15 s	60 s	55 m

Medium is the default for a vehicle survey. High spends more battery to hold tighter corners. On a 4,500 mAh phone, a 12-hour Medium shift plus the always-on process lands around 16–20% of the battery for the day. That figure is an engineering estimate, not a lab measurement.

The road test

After the batching fix, the app was compared with a vehicle trip meter on a route that included left turns, right turns, and a U-turn.


Vehicle trip meter	2.00 km
App	1.94 km
Points saved	25
Agreement	97%
Gap	60 m

Sixty metres on two kilometres is the residue of GPS error, sample spacing, and road curvature. The app estimates the path from fixes. It does not read the odometer.

What stays on the device

Shift start and stop are daily alarms. A second foreground service stays up so those alarms still fire after Doze, reboot, and an app update. OEM battery screens (Xiaomi, Oppo, vivo, Samsung, and others) are linked from inside the app, because a foreground service alone does not survive every vendor killer.

The published proof keeps data on the device, draws the raw filtered trace, and leaves polyline simplification for later. Those are product steps. The distance figure is already the filtered Haversine sum.

The same problem on .NET MAUI — an on-demand fix, a tracking session, and reverse geocoding — is Plugin.Maui.GeoLocator (NuGet, GitHub). This Android proof is the measurement study behind that kind of API: what to sample, what to reject, and what accuracy to expect against a trip meter.

Repository: github.com/nuvyntralabs/GPSSensorTrackingService
Research page: nuvyntralabs.github.io/research/gps-sensor-tracking-service/

By Niladri

.NET 11 RC1 Is Here — What Developers Should Know

NuvyntraLabs — Wed, 23 Sep 2026 14:29:15 +0000

.NET 11 has reached Release Candidate 1 (RC1), bringing the next generation of the .NET platform one step closer to its November 2026 release. Microsoft released .NET 11 RC1 on September 8, 2026, with Go-Live support.

This release includes updates across the runtime, SDK, libraries, MSBuild, NuGet, C#, F#, ASP.NET Core, .NET MAUI, and Windows Forms.

What Makes .NET 11 Interesting?

.NET 11 is not simply another framework version. Several areas are receiving deeper platform-level improvements.

🚀 Runtime & Performance

.NET 11 continues work around runtime performance, NativeAOT, asynchronous execution, and CoreCLR.

One particularly interesting direction is the continued expansion of CoreCLR, including its role in cross-platform scenarios.

🧩 C# 15

.NET 11 comes with C# 15, which introduces new language capabilities including work around union types.

For developers building large applications, language improvements like these could make certain domain models and API contracts more expressive.

🌐 ASP.NET Core & Blazor

ASP.NET Core and Blazor also receive significant updates in the .NET 11 cycle.

The ecosystem is moving toward richer server-side rendering, improved validation, smaller Blazor WebAssembly applications, and better integration with modern .NET development workflows.

📱 .NET MAUI

.NET MAUI developers should pay particular attention to .NET 11.

One of the notable areas Microsoft has highlighted is the move toward CoreCLR for .NET MAUI applications on Android, iOS, and Mac Catalyst.

This could be an important evolution for developers building production cross-platform applications with MAUI.

Should You Move to .NET 11 Now?

.NET 11 RC1 has Go-Live support, meaning Microsoft supports production use of the RC release. However, teams should still carefully test their applications, dependencies, workloads, and CI/CD pipelines before moving production systems.

For teams currently on .NET 10, there is also no immediate need to rush. .NET 10 is an LTS release and is supported through November 14, 2028, while .NET 11 is an STS release.

The Bigger Picture

.NET 11 looks less like a simple yearly upgrade and more like another step in the evolution of the entire .NET ecosystem — from runtime and language improvements to cloud development, web applications, AI tooling, and cross-platform applications.

The official launch is expected in November 2026, alongside .NET Conf 2026.

For .NET developers, now is a good time to start testing .NET 11 in non-production projects and checking how your libraries and applications behave with the new runtime.

.NET 11 is almost here. The next chapter of .NET development is about to begin.

By Niladri

VoIPCall: A Native Android Dialer for PSTN Calls on Vobiz

NuvyntraLabs — Wed, 23 Sep 2026 14:03:10 +0000

A field app that places a phone-network call should look like the phone people already use, and it should still ring after the process has been swiped away.

Vobiz VoIP is that dialer. It is a native Kotlin app for Android 12 and later. Calls go through Vobiz. Signaling is SIP over a secure WebSocket. Audio is WebRTC. A TypeScript backend answers Vobiz webhooks and wakes the handset with Firebase Cloud Messaging.

This post is the walkthrough: what the dialer does, how an outbound call leaves the keypad, how an inbound call arrives when the app is not running, and where this proof sits next to Plugin.Maui.VoipCore.

What Vobiz VoIP is

Vobiz VoIP is a public Android proof. The application id is com.Vobiz.vobizvoip. The UI is Jetpack Compose. One Vobiz SIP endpoint is registered per device. One Vobiz number, in E.164, is that device’s caller ID.

The phone holds the SIP username and password. The Vobiz Auth ID and Auth Token stay in the backend. They are not compiled into the APK.


App	Vobiz VoIP · `com.Vobiz.vobizvoip`
Platform	Android 12+ (API 31) · Kotlin · Jetpack Compose
Signaling	SIP over `wss://registrar.vobiz.ai:5063/`
Media	WebRTC audio (DTLS-SRTP)
Wake-up	Firebase Cloud Messaging, including a terminated process
Source	github.com/nuvyntralabs/VOBIZ-VOIP-Call
Research	nuvyntralabs.github.io/research/vobiz-voip-call/
Setup	SETUP_GUIDE.md

The repository contains the Android app and a local Node.js backend. The backend exposes the Answer URL, call state, and the FCM send. A tunnel publishes that process at an HTTPS origin Vobiz can reach.

Why the dialer is native

Vobiz ships a Flutter Android sample and a Java REST SDK for the Voice API. The REST SDK does not open a WebRTC audio session, and the sample is not a Kotlin dialer. This proof is the native client: OkHttp for the SIP WebSocket, the Android WebRTC library for media, and a phone-shaped UI on top.

Android dialer
    |  SIP over WSS          WebRTC audio
    v
Vobiz registrar  +  media edge
    |
    v
Public phone network
    ^
    |  Answer and Hangup webhooks
Backend  --Firebase push-->  the same phone

Call phases on the device run IDLE → OUTGOING → RINGING → INCOMING → CONNECTING → ACTIVE → ENDING → FAILED. A finished call is stored as COMPLETED, MISSED, DECLINED, CANCELED, or FAILED. That history is the app’s own log. It is not written to Android’s system CallLog.

The phone UI

The shell matches a handset dialer.

Home lists recents, grouped into Today, Yesterday, and Older. A matching device contact supplies the name.
Search on Home filters those contacts. A match can be called from the result.
Keypad is the second bottom tab.
The side menu holds Contacts, Settings, and Clear call history.

A leading 0 is replaced with the country code. A bare national number gets the country code prepended. A number that already starts with + is left unchanged. The country code comes from the SIM. With no SIM, Settings Default country is used. The last fallback is India (+91).

What was typed	What is dialed
`+9198…`	Unchanged
`0091…`	`00` becomes `+`
`098…`	Leading `0` becomes `+` and the country code
`987…`	Country code prepended
`*` or `#` feature codes	Left as entered

Place a call

Outbound starts on the keypad, from a contact, from a recent row, or from another app. The dialer normalizes the number, then asks the backend to start the call. Vobiz dials the PSTN number. When the other phone answers, the WebRTC session carries both directions of audio.

On the call screen the user can mute, route audio to the speaker, send DTMF, and hang up. While a native cellular call is off-hook, the VoIP microphone mutes itself.

Answer when the app is closed

Every inbound PSTN call is parked in a short-lived Vobiz conference, then delivered by push. The same path runs in the foreground, in the background, and after the app has been removed from Recents.

Someone dials this device’s Vobiz number.
Vobiz POSTs the Answer webhook. The backend checks that a device registered that DID.
The caller is parked in a conference. A high-priority FCM message wakes the phone.
The incoming-call screen is shown. On a locked phone that needs notifications, full-screen incoming calls, and unrestricted battery. The app asks for those.
Answering registers SIP if needed and joins the same conference. Two-way audio starts.
If nobody answers within 30 seconds, the pending call expires and the caller is released. The log row is MISSED. Declining writes DECLINED.

The caller hears silence, or the conference wait sound, for the few seconds between the push and the app joining. A DID with no registered device is rejected. The backend logs No device registered this DID.

Do not test by calling the configured caller ID from the same device.

What you enter once

Save and connect stays disabled until the required fields are valid. SIP credentials are encrypted with an Android Keystore AES-GCM key.

Settings field	What it is
SIP username and password	This device’s Vobiz SIP endpoint. One endpoint per phone.
Registrar WSS URL	`wss://registrar.vobiz.ai:5063/`
SIP domain	`registrar.vobiz.ai`
Public backend HTTPS URL	The tunnel in front of the local backend.
POC device token	The same `DEVICE_TOKEN` as `backend/.env`.
Vobiz caller ID	This device’s DID, E.164, starting with `+`.
Default country	Used only when the device has no SIM.
Record calls	On by default. Playback is available from Recents.

A healthy status row reads Registered and ready for calls for SIP, and Online with Firebase ready for the backend. The Vobiz Auth ID, Auth Token, and webhook token are backend secrets. The Answer and Hangup URLs are set on the Vobiz Voice Application, not in the Android form.

Grant microphone, notifications, contacts, phone state, and nearby-devices (Bluetooth) when prompted.

Let another app place the call

The app does not register as the OS default dialer. Other apps open it with an intent. Numbers are normalized before dialing.

// Open the dialer, optionally pre-filled
startActivity(Intent(Intent.ACTION_DIAL, Uri.parse("tel:+919876543210")))

// Place the call
startActivity(
    Intent("com.Vobiz.vobizvoip.action.CALL").apply {
        setPackage("com.Vobiz.vobizvoip")
        putExtra("number", "09876543210")
    },
)

The call history, including a recording path when recording is on, is a content provider. The caller declares com.Vobiz.vobizvoip.permission.READ_CALL_LOG and queries content://com.Vobiz.vobizvoip.provider.calllog/calls. Columns include number, display_name, type (1 incoming, 2 outgoing, 3 missed), date, duration, and recording_path. The provider streams the recording. The backend auth token stays inside Vobiz VoIP.

When something looks wrong

What you see	What to do
SIP stays disconnected	Confirm the endpoint username, password, `wss://` registrar, and domain. Use the SIP refresh action in Settings.
Backend stays offline	The tunnel URL must be the current `PUBLIC_URL`, and the backend process must be running. `GET /health` on that origin should succeed.
Inbound never rings, backend is online	`GET /health` reports Firebase only when the service-account key loaded. The app needs `google-services.json`, notifications, full-screen incoming calls, and unrestricted battery.
Caller hears an error and drops	No device has registered that DID. Open the app on the phone that owns the number so it can register.
The other device rings	You called device 1’s caller ID. Each handset has its own DID and its own SIP username.
Call ends with no answer	The pending inbound call expires after 30 seconds.
Two-way audio fails on some networks	STUN alone does not cross every mobile or symmetric NAT. Production media needs TURN.
A second open of the same SIP user fights the first	One SIP endpoint per device. Do not share an endpoint across phones.

Where this dialer sits next to the other tools

This repository is the Android proof for one vendor path. It is not a MAUI package, and it is not pulled in by nuvyn init.

Need	Tool
A native Android dialer for Vobiz PSTN, with recents, keypad, and push wake-up	Vobiz VoIP — VOBIZ-VOIP-Call
A MAUI session model: call state, hold, mute, pluggable signaling	Plugin.Maui.VoipCore
The written map of this proof	Research: VOBIZ VoIP Call

Use Vobiz VoIP when the product is an Android handset on Vobiz and the UI has to be the dialer. Use VoipCore when a .NET MAUI app needs a session model and the signaling stack stays replaceable.

Try it

You need JDK 17, Android SDK 36, a physical Android 12+ device, Node.js 22+, a tunnel, one Vobiz number, one SIP endpoint for that device, and a Firebase project for com.Vobiz.vobizvoip. A second phone on the public network is the other leg.

./gradlew testDebugUnitTest assembleDebug
adb install -r app/build/outputs/apk/debug/app-debug.apk

Then, in order: status shows ready, an outbound call to the second phone has two-way audio, an inbound call works in the foreground, the same inbound works after the app is swiped away, and a second device rings only when its own caller ID is dialed.

Repository: github.com/nuvyntralabs/VOBIZ-VOIP-Call
Research page: nuvyntralabs.github.io/research/vobiz-voip-call/
Setup: SETUP_GUIDE.md
Call paths: CALL_WORKFLOWS.md
Settings and intents: CONFIGURATION_AND_INTEGRATION.md

By Niladri

AI Tools Used in Modern Software Development

NuvyntraLabs — Wed, 23 Sep 2026 12:22:30 +0000

AI Tools Used in Modern Software Development

AI is no longer just a tool for generating code. It is becoming part of the entire software development workflow — from understanding requirements to writing code, debugging, testing, documenting, and even reviewing pull requests.

For developers, the question is no longer “Should I use AI?” but rather “Where can AI actually improve my development workflow?”

1. AI Coding Assistants

The most visible use of AI in development is coding assistance.

Tools such as GitHub Copilot, Cursor, Claude Code, and Gemini Code Assist can help developers:

Generate code from natural-language requirements
Explain existing code
Refactor code
Generate unit tests
Find potential bugs
Create documentation
Suggest implementation approaches

The important point is that AI should be treated as a coding partner, not an autonomous developer. Generated code still needs to be reviewed, tested, and understood.

2. AI-Powered IDEs and Editors

AI is increasingly integrated directly into development environments.

Modern AI-enabled editors can understand multiple files and sometimes an entire repository. This allows developers to ask questions such as:

“Where is authentication handled?”

“Find all places where this API is called and update the error handling.”

This is much more powerful than traditional autocomplete because the AI can work with the context of the project.

3. AI for Debugging

Debugging is another area where AI can save significant time.

Developers can provide an exception, stack trace, log output, or problematic code and ask AI to:

Explain the error
Identify possible root causes
Suggest fixes
Analyze logs
Generate debugging steps
Explain platform-specific behavior

However, AI explanations should be treated as hypotheses until verified against the actual application.

4. AI for Testing

AI can accelerate the testing process by generating:

Unit tests
Integration tests
Mock data
Test cases
Edge cases
Regression scenarios

For example, instead of manually creating dozens of test cases for a validation method, AI can generate an initial test suite that developers can review and improve.

The biggest value is often not simply writing tests faster, but helping developers think about cases they might have overlooked.

5. AI for Code Review

AI can also act as an additional code-review layer.

It can identify potential:

Null-reference issues
Security problems
Performance bottlenecks
Duplicate code
Poor error handling
Unnecessary complexity
Missing tests

AI review should complement, not replace, human code reviews.

6. AI for Documentation

Documentation is often one of the first things developers postpone.

AI can help generate:

README files
API documentation
XML documentation
Architecture descriptions
Migration guides
Release notes
Code comments

This becomes particularly useful for open-source projects where documentation is critical for adoption.

7. AI for Git and DevOps

AI can also assist with everyday development operations:

Commit messages
Pull request descriptions
GitHub issue summaries
CI/CD troubleshooting
YAML configuration
Build error analysis
Release notes

This reduces the amount of repetitive work surrounding the actual coding process.

8. AI for Architecture

This is where things become more interesting.

AI can help developers explore architectural alternatives.

For example:

“Design an offline-first MAUI application with local SQLite storage, background synchronization and conflict resolution.”

AI can propose architecture options, identify potential problems, and generate an initial implementation structure.

But architecture decisions still require human judgment.

AI does not know your organization's business constraints, operational requirements, team capabilities, security policies, or long-term maintenance strategy unless you provide that context.

9. AI + Repository Knowledge

One of the biggest changes in AI-assisted development is the move from prompt → code to repository → context → implementation.

Developers increasingly want AI tools that understand:

Project structure
Coding conventions
Existing services
APIs
Documentation
Dependencies
Architecture
Previous implementation decisions

This is why repository-aware AI agents and RAG-based developer tools are becoming increasingly important.

10. The Developer Still Matters

AI can generate impressive amounts of code.

But generating code is not the same as engineering software.

Developers still need to understand:

Why is this architecture being used?

Is the generated code secure?

Will it scale?

Does it work across platforms?

What happens when the network is unavailable?

What happens six months from now when someone has to maintain it?

AI can accelerate implementation, but engineering judgment remains essential.

My AI Development Workflow

A practical AI-assisted workflow can look like this:

Requirement → Architecture → AI-assisted implementation → Human review → AI-assisted testing → Build → Debug → Code review → Documentation → Release

The goal is not to let AI replace the developer.

The goal is to remove repetitive work so developers can spend more time on architecture, product decisions, problem solving, and quality.

Final Thoughts

AI development tools are rapidly becoming another layer of the software development ecosystem.

The developers who benefit the most may not necessarily be the ones who generate the most code with AI.

They will be the developers who know when to use AI, what context to provide, how to verify the output, and when not to trust it.

AI is changing the way software is built.

But good software engineering still starts with understanding the problem.

By Niladri

MAUI vs React Native vs Flutter vs Ionic

NuvyntraLabs — Wed, 23 Sep 2026 12:09:36 +0000

An Honest Cross-Platform Comparison — No Sugar Coating

Cross-platform development promises something attractive: build once and run everywhere.

The reality is different.

.NET MAUI, React Native, Flutter, and Ionic all solve cross-platform development differently. None is perfect, and none completely eliminates the need to understand Android and iOS.

The Core Difference

Framework	Technology	Main Approach
.NET MAUI	C# / .NET	Native controls through handlers
React Native	TypeScript / JavaScript	Native components
Flutter	Dart	Own rendering engine/widgets
Ionic	HTML / CSS / JS	WebView

That architectural difference matters more than most benchmark comparisons.

.NET MAUI

MAUI is particularly attractive for C#/.NET teams.

Strengths

Excellent C# and .NET ecosystem
Strong native platform integration
Shared business logic and services
Good fit for enterprise applications
Natural choice for teams already using ASP.NET Core/Azure
Windows support is an important advantage

Reality check

MAUI does not mean writing XAML once and forgetting Android and iOS.

You will still encounter:

Platform-specific APIs
Android/iOS lifecycle differences
Background execution restrictions
Permissions
Notifications
Device-specific issues
Native code

The MAUI ecosystem is also smaller than the JavaScript ecosystem.

Best fit: .NET-centric teams and enterprise applications.

React Native

React Native is a natural choice for teams already invested in React and TypeScript.

Strengths

Huge JavaScript ecosystem
Large developer community
TypeScript support
Excellent React knowledge reuse
Strong native integration

Reality check

The npm ecosystem is both a strength and a weakness.

Large projects can accumulate:

Dependency conflicts
Native module complexity
Gradle/Xcode issues
JavaScript/native integration problems

For serious applications, you should expect some Kotlin/Java and Swift work.

Best fit: React/TypeScript teams and products heavily invested in the JavaScript ecosystem.

Flutter

Flutter takes a different approach by controlling its own rendering.

Strengths

Excellent UI consistency
Powerful custom UI
Strong animations
Good performance for many workloads
Great for highly branded applications

Reality check

Flutter's consistency comes from its own rendering system rather than simply using native controls.

Dart is also another ecosystem to adopt, and deep platform integration still requires native Android/iOS knowledge.

Best fit: applications where custom UI and consistent visual experience are major priorities.

Ionic

Ionic takes the web-first approach.

HTML + CSS + JavaScript/TypeScript run through a WebView, with Capacitor providing native integration.

Strengths

Excellent for web developers
Reuse web skills and code
Fast development
Great for forms, dashboards and business applications
Easy web/mobile technology sharing

Reality check

A WebView-based architecture has different characteristics from native-rendered applications.

It can be perfectly suitable for many business applications, but demanding graphics, animations or highly native experiences can expose its limitations.

Best fit: web-first teams and business applications.

Quick Comparison

	MAUI	React Native	Flutter	Ionic
Language	C#	TypeScript/JS	Dart	TypeScript/JS
Native UI	✅	✅	Own rendering	❌
Custom UI	✅	✅	⭐ Strong	✅
Web reuse	Low	Medium	Low	⭐ Excellent
.NET integration	⭐ Excellent	Low	Low	Low
JS ecosystem	Small	⭐ Huge	Small	⭐ Huge
Native integration	Strong	Strong	Strong	Via plugins
Best for	.NET teams	React teams	Custom UI	Web teams

The Most Important Reality

Cross-platform does not mean platform-independent.

Android is still Android.

iOS is still iOS.

If your application uses:

Bluetooth
Camera
Location
VoIP
Audio
Background services
Push notifications
File systems
Deep links

you will eventually need to understand the underlying platforms.

The framework reduces duplicated work. It doesn't eliminate platform complexity.

So Which One Is Best?

There isn't a universal winner.

Choose based on your team, product and requirements.

Choose MAUI if your organization is deeply invested in .NET and C#.

Choose React Native if React/TypeScript is already your team's strength.

Choose Flutter if highly customized and consistent UI is a major requirement.

Choose Ionic if you're primarily a web team and your application is well suited to web technologies.

Final Thought

The best cross-platform framework isn't the one with the most GitHub stars or the loudest marketing.

It's the one your team can:

Build → Debug → Release → Scale → Maintain

for years.

Cross-platform development isn't about eliminating platform differences.

It's about managing them efficiently.

By Niladri

DEV Community: NuvyntraLabs

From Xamarin to .NET MAUI: An Enterprise Migration Playbook

1. Why Enterprise Migration Is Different

2. The Migration Mindset

3. Phase 1 — Assess the Existing Application

4. Build a Dependency Risk Matrix

Green

Yellow

Red

5. Phase 2 — Establish a Production Baseline

6. Phase 3 — Stabilize Xamarin Before Migration

7. Don't Automatically Convert Everything

Does this code contain business logic?

Does this code exist only because Xamarin required it?

Is this code solving a problem that MAUI already solves?

8. Decouple the Business Layer

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

10. Build the MAUI Foundation First

11. Migrate One Vertical Slice

12. Renderers → Handlers

13. Create Platform Abstractions

14. Treat Native Functionality as a Separate Migration Track

Android

iOS

15. Firebase and Push Notifications

16. Authentication Must Be Tested End-to-End

17. Keep Xamarin and MAUI Side-by-Side

18. Use Feature Flags

19. CI/CD Should Be Migrated Early

20. Automated Testing Is a Migration Requirement

Unit tests

Integration tests

Device tests

21. Performance Testing

22. Observability During Migration

23. Don't Combine Migration With a Major Rewrite

Release 1 — Migration

Release 2 — Stabilization

Release 3 — Modernization

24. Track Migration Debt

25. Enterprise Migration Scorecard

26. Recommended Migration Roadmap

27. The Golden Rules

1. Don't start with the .csproj

2. Establish a baseline

3. Don't migrate everything at once

4. Decouple business logic

5. Migrate vertical slices

6. Isolate native code

7. Don't blindly convert renderers

8. Use feature flags

9. Automate validation

10. Separate migration from modernization

Conclusion

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

What VideoPipeline is

Install and register

Pick, limit, thumbnail, encrypt

What each platform encodes

Permissions the host still requests

When something looks wrong

Where VideoPipeline sits next to the other tools

Try it

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

What OfflineSync is

Install and register

Write locally

Conflicts

What the HTTP remote looks like

Background sync permissions

When something looks wrong

Where OfflineSync sits next to the other tools

Try it

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

What TlsPin is

Install and pin one host

Report-only staging

When something looks wrong

Where TlsPin sits next to the other tools

Try it

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

A client that does not touch `Current`