MAUI
Recommended for most apps. One line in MauiProgram.cs wires everything up. Use this if you’re building a .NET MAUI app.
Document DB v12 - Improved Interceptors with Soft Delete Integration, AI protections, & Admin UI with Aspire Integration!How!?
Hosting Models
Shiny libraries rely on platform lifecycle events — push token registration on iOS, permission callbacks on Android, background transfer completions, and more. A hosting model is the thin layer that wires these OS-level events into Shiny’s internal infrastructure so your modules (BLE, Push, Jobs, etc.) just work.
Why do I need one?
Section titled “Why do I need one?”Mobile platforms require you to override specific methods in your AppDelegate (iOS) or Application/Activity (Android) to receive system events. Without these hooks, Shiny modules can’t receive push tokens, respond to permission results, or handle background wake-ups.
A hosting model handles this wiring for you — either automatically through base class inheritance or manually through explicit lifecycle forwarding.
Which should I use?
Section titled “Which should I use?”Native
For .NET iOS/Android apps without MAUI. Inherit from Shiny’s base classes (ShinyAppDelegate, ShinyAndroidApplication) and override a single method.
Manual
For apps with existing platform boilerplate you can’t change. You forward lifecycle events to Host.Lifecycle yourself. Most complex, but fully flexible.
Platform Notes
Section titled “Platform Notes”| Platform | Hosting Required? | Notes |
|---|---|---|
| iOS / Mac Catalyst | Yes | Push tokens, background transfers, deep links all need AppDelegate hooks |
| Android | Yes | Permissions, activity results, and intent filters need Application + Activity hooks |
| macOS (AppKit) | Partial | Only needed if using Push — forward NSApplicationDelegate callbacks |
| Linux | No | No OS lifecycle callbacks — register services directly on IServiceCollection |
| Blazor WebAssembly | No | No native lifecycle — register services directly on WebAssemblyHostBuilder.Services |