Shiny Client Release Notes

IGattCharacteristic.Notify could hang forever, or silently drop the value, when the transmit queue was full. UpdateValue returns false when CoreBluetooth’s queue is full, and Notify only attached its ReadyToUpdateSubscribers handler after that call returned - so a ready callback that arrived in between was missed and the returned task never completed. When the callback was caught, the retry ignored UpdateValue’s result, so a queue that had filled again dropped the notification while Notify still reported success. The handler is now attached before every attempt, and Notify retries on each ready callback until CoreBluetooth accepts the value - the task completes only once the notification is actually queued. Applies to iOS, Mac Catalyst and macOS.

Enhancement

IGattCharacteristic.Notify(data, cancellationToken, params centrals) - a new overload that stops waiting when the token is cancelled. It matters on iOS, Mac Catalyst and macOS, where Notify waits while CoreBluetooth’s transmit queue is full; that wait now also ends with an InvalidOperationException if Bluetooth stops being powered on, since a powered-off manager never drains the queue and the task would otherwise never complete. Generated [BleService] classes get a matching NotifyX(data, cancellationToken, params centrals), and the reply a [RequestResponseCharacteristic] sends now passes BleHostToken, so tearing the service down abandons it. The existing Notify(data, params centrals) is unchanged.

FixiOS

Notify(data, centrals) ignored the centrals you named and sent to every subscriber - UpdateValue was always called with a null central list. The named centrals are now passed through, so a targeted notification (including every generated request/response reply) reaches only the central it was meant for. Applies to iOS, Mac Catalyst and macOS.

FixAndroid

Notify(data) with no centrals sent to nobody. The fallback to “every subscriber” was written as centrals.OfType<Peripheral>() ?? SubscribedCentrals, and OfType never returns null, so the empty list was used as-is. An empty list now means every subscriber, as documented.

Fix

SubscribedCentrals stayed empty unless SetNotification was given a subscribe hook, because subscriptions were only tracked when there was a hook to call. The source generator registers class-level [NotifyCharacteristic] and every [RequestResponseCharacteristic] without one, so XSubscribers / HasXSubscribers always read empty and every generated request/response reply was dropped through OnBleResponseDropped. On Android it was worse: the CCCD descriptor was only added when a hook existed, so a central could not subscribe to such a characteristic at all. Subscriptions are now tracked, and the descriptor added, whenever the characteristic can notify or indicate. Applies to iOS, Mac Catalyst, macOS, Android and Windows; Linux already tracked them.

BREAKINGFixAndroid

IPeripheral.Uuid for a connected central was the literal string System.Byte[] - the identifier was built with byte[].ToString() - so every central had the same id and none could be told apart. It is now the same MAC-derived GUID Shiny.BluetoothLE uses for the central role. This is a behaviour change: anything that stored or compared the old value will see a different, per-device identifier.

FixAndroid

Back-to-back notifications were silently dropped. Android allows one notification in flight per central and refuses the next until onNotificationSent arrives, but Notify sent without waiting and ignored the result - so a burst lost everything after the first while every call reported success. Notify now waits for onNotificationSent before sending that central its next value (different centrals are sent in parallel), throws if Android refuses a notification or reports a failed status, and stops waiting when the central disconnects, the GATT server closes, or the token is cancelled. On API 33+ it uses the notifyCharacteristicChanged overload that carries the value rather than writing it onto the shared characteristic first. Indications were never confirmed either: confirm was always false, so a central that enabled indications received plain notifications. It now gets indications.

FeatureLinux

The Linux GATT server is implemented. AddService threw NotSupportedException - the BlueZ plumbing behind it was a TODO - so nothing could be read, written or subscribed to, and Notify always threw “not registered with BlueZ yet”. Shiny now exports the application BlueZ expects - an org.freedesktop.DBus.ObjectManager root with an org.bluez.GattService1 object per service and an org.bluez.GattCharacteristic1 object per characteristic - and registers it with GattManager1. ReadValue and WriteValue reach your SetRead / SetWrite handlers with the requesting central, offset and MTU; WriteRequest.Respond sends its status back as the GATT response immediately, and a write without response (type=command) reports IsReplyNeeded = false. StartNotify / StopNotify drive SubscribedCentrals and your subscribe hook, and Notify sends the value as PropertiesChanged on Value, which BlueZ turns into a notification or indication. BlueZ reads the object tree only once, at registration, so adding or removing a service re-registers the whole application. Two BlueZ limits: it tells an external application only whether notifications are enabled, not which central enabled them, so while any central is subscribed every connected central is reported as subscribed; and it sends each value to every subscribed central, so Notify(data, centrals) cannot narrow the recipients - a targeted notification is skipped when none of the named centrals is subscribed and otherwise reaches every subscriber, [RequestResponseCharacteristic] replies included.

5.6.0 - September 11, 2026

Core & Hosting

FixBlazor

IConnectivity and IBattery now report real values in the browser. Shiny.Core.Blazor’s managers imported their JS module but never called its init(), so navigator.getBattery() was never resolved and navigator.connection was never read - battery reported “not charging” at 100% forever and the connection type was always Unknown. Nothing called StartAsync() either, so the module was never even imported unless an app knew to reach for the concrete type and start it. Both managers now initialize the module as part of starting, and start themselves the first time a property is read or Changed is subscribed to, reporting Unknown only until that completes. await host.Services.UseShinyCore() starts them up front when the first read needs to be accurate. Where a browser has no Battery Status API (Firefox, Safari), Status now stays Unknown instead of claiming the device is discharging.

FixiOS

ShinyAppDelegate no longer crashes the app on launch. FinishedLaunching ended with return base.FinishedLaunching(...), but didFinishLaunchingWithOptions is an optional protocol member, so the binding’s base implementation throws Foundation.You_Should_Not_Call_base_In_This_Method - the host was built and run, then the exception took the process down before the first frame. It returns true directly now. Affects every app hosting through Shiny.Hosting.Native on iOS, tvOS and Mac Catalyst; MAUI hosting (UseShiny()) was never on this path.

FeaturetvOS

tvOS support. Shiny.Core and Shiny.Hosting.Native now ship net10.0-tvos targets. tvOS reuses the iOS platform layer wholesale - IosPlatform, IosLifecycleExecutor, ShinyAppDelegate and the IIosLifecycle hooks are all the same types - so a tvOS head boots Shiny exactly the way an iOS one does. Two deliberate differences: IBattery reports a permanently full battery, because an Apple TV is mains powered and UIDevice carries no battery API on tvOS; and IIosLifecycle.INotificationHandler does not exist on tvOS, because notifications there can only change the app icon badge and there is no UNNotificationResponse to hand back. Modules with tvOS targets: Shiny.BluetoothLE, Shiny.Net.Discovery, Shiny.Jobs, Shiny.Net.Http, Shiny.Push, Shiny.ScreenRecorder and Shiny.Data.Sync.

BluetoothLE

FeatureBlazor

Web Bluetooth advertisement payloads reach the app at last. IAdvertisementData.ManufacturerData and .ServiceData both returned null on Blazor - the JS layer read neither off the advertisementreceived event, so anything that lives in a payload rather than in the device name or service UUID list was invisible. Both are now marshalled across (Web Bluetooth reports them as Maps, which do not survive JSON, so they are flattened to arrays with base64 payloads). This is what makes Shiny.Beacons work in the browser. The chooser fallback still carries no payload - requestDevice reports none - so this only applies where navigator.bluetooth.requestLEScan is available.

FixiOS

A scan started before CoreBluetooth finished powering on found nothing, forever. Scan() called ScanForPeripherals the moment it was subscribed, and IBleManager.Manager builds the CBCentralManager lazily - on the first call that is the same statement, so the central was still reporting Unknown. CoreBluetooth drops commands issued below PoweredOn without calling back and without an error (it logs API MISUSE to the native console and nothing reaches your ILogger), so no native scan ever started: DiscoveredPeripheral was never called, the observable never emitted, and IsScanning returned true the whole time. A retry a moment later worked, which made it look as though only peripherals already advertising when the scan began were discoverable. The scan request is now parked exactly as a connect below PoweredOn already was (#1652) and issued as soon as the central reports powered on, so Scan() no longer requires you to await RequestAccess() first. A scan also survives the user cycling Bluetooth: CoreBluetooth tears it down on power-off, and Shiny re-issues it on power-on rather than leaving a live subscription attached to a dead scan. IsScanning now tracks the native scan and reads false while a request is parked. Applies to iOS, tvOS, Mac Catalyst and macOS - Platforms/MacOS is a separate compiled tree and carried the same bug. Android and Windows were unaffected: Android reads adapter state synchronously, and Windows still gated the scan on RequestAccess(). Regression introduced in 5.0.

FixiOS

The first advertisement of a scan is no longer dropped. Scan() subscribed to the internal scan-result subject after calling ScanForPeripherals, and CoreBluetooth can deliver a cached advertisement synchronously from that call - so the earliest result went to nobody. The subscription is now in place before the native scan is issued. Applies to iOS, tvOS, Mac Catalyst and macOS.

Fix

IBleManager.StopScan() now clears IsScanning. Only the scan subscription’s disposal cleared it, so stopping a scan through the manager - which the API docs recommend when the original subscription is out of reach - left the flag set and every later Scan() threw There is already an existing scan for the life of the process. Applies to iOS, tvOS, Mac Catalyst, macOS and Android; Windows already did this.

FeaturetvOS

tvOS support. Shiny.BluetoothLE now ships a net10.0-tvos target. CoreBluetooth’s central role is complete on tvOS - scanning, connecting, GATT, and L2CAP channels all work through the same IBleManager API as iOS, with no tvOS-specific code on your side. Two things differ from iOS and neither is Shiny’s to fix: tvOS has no bluetooth-central background mode, so scans and connections end when the app is suspended and AppleBleConfiguration.RestoreIdentifier buys you nothing there; and the peripheral role is absent entirely, so Shiny.BluetoothLE.Hosting has no tvOS target - CBMutableService and CBMutableCharacteristic carry no constructors on tvOS, which is Apple stating that an Apple TV cannot be a GATT server.

BREAKINGFix

Turning Bluetooth off and on is now propagated to connected peripherals. Neither platform told the peripheral anything about an adapter power cycle - the event reached IBleDelegate.OnAdapterStateChanged and stopped there - and neither OS reports the resulting drop per peripheral (CoreBluetooth does not call didDisconnectPeripheral on power-off, and several Android devices deliver no OnConnectionStateChange either). So WhenStatusChanged() stayed on Connected for a link that no longer existed, contradicting IPeripheral.Status, which reads the platform live and already said Disconnected; notifiers were never cleared, queued operations were never broken (the deadlock family of #1637), and AutoConnect - which is edge-triggered on a Disconnected emission - never fired, so the link never came back. An adapter that drops below available now runs the same teardown a real disconnect gets on iOS, Mac Catalyst, macOS and Android, and an adapter that returns re-issues the connect for every peripheral connected with AutoConnect: true. Connect calls made while the adapter is down - Shiny’s own reconnect, or your Connect() from OnAdapterStateChanged - are parked rather than issued, because ConnectPeripheral below PoweredOn and ConnectGatt with the adapter off are silent no-ops that never report back; they replay when the adapter returns. CancelConnection() stays final and discards anything parked, and starting a scan no longer evicts a peripheral that is waiting to reconnect - the manager’s adapter hooks only reach peripherals still in its cache, so a Scan() while the link was down used to silently cancel the pending reconnect. Not applicable to Linux (BlueZ), where the adapter’s Powered state is not tracked, or to Blazor, where Web Bluetooth does not expose adapter state at all; Windows needs none of it, since ConnectionStatusChanged fires on a radio power-down by itself. This is a behaviour change: consumers now receive a Disconnected on WhenStatusChanged() / WhenDisconnected() when the user turns Bluetooth off. If you drive your own reconnect off that stream, gate it on the adapter being available - AutoConnect: true already handles the cycle for you.

FixiOS

A Connected that Apple actually delivered is no longer swallowed when the status stream is stale. ReceiveStateChange only emitted when the new state differed from the subject’s current value, so after a link died without a didDisconnectPeripheral - exactly what an adapter power cycle produces - a subsequent didConnectPeripheral was dropped: the link was up, WhenConnected() never fired, and the managed notification re-hook that hangs off that transition never rebuilt the subscription, leaving a connected peripheral that delivered nothing. CoreBluetooth only calls didConnectPeripheral for a brand new link, so that combination now emits the Disconnected the platform never sent followed by the Connected it did, repairing the stream instead of discarding the event. Applies to iOS, Mac Catalyst, and macOS.

FixmacOS

The macOS target framework now shares the connection lifecycle the other Apple platforms have. Platforms/MacOS is a separate compiled tree from Platforms/Apple, and it had been left behind: auto-reconnect used a skipFirst flag on a stream seeded from the live peripheral state, so the first real disconnect was swallowed whenever the peripheral was already connected at the time Connect() was called; there was no retry on FailedToConnectPeripheral, so a cold-start failure never retried; the previous pending connection slot was never cancelled before re-issuing; and WhenConnectionFailed() did not replay, so a subscriber that hooked up straight after Connect() missed the failure. macOS now behaves as iOS and Mac Catalyst do, including the adapter power-cycle handling above.

FixAndroid

Auto-reconnect now also retries from WhenConnectionFailed(), as Apple has always done. A ConnectGatt that fails outright - a null client, or the GATT binder not yet being up in the instant ACTION_STATE_CHANGED/STATE_ON arrives - reports on the connection-failure stream and emits nothing on the status stream, and the reconnect subscription only listened to the latter. Since the adapter-on replay is the one thing that re-issues a parked connect, a single failure there left the peripheral disconnected for the life of the process even with AutoConnect: true. Retries are throttled to one per second and skip an attempt while a GATT client is already open.

FixiOS

Connect(new ConnectionConfig(AutoConnect: false)) now disposes an auto-reconnect armed by an earlier Connect(). The disposal sat inside the AutoConnect: true branch, so downgrading a peripheral to manual reconnection left the old subscription live and the peripheral kept reconnecting on a config that no longer asked for it - including across an adapter power cycle. Android already did this. Applies to iOS, Mac Catalyst, and macOS.

FixAndroid

[GitHub #1650] by martijnthe

DoConnect now resets RequiresServiceDiscovery whenever it opens a new BluetoothGatt client. The flag was only cleared by the two teardown paths (CancelConnection and a reported disconnect), so a Connect() on a peripheral whose previous client was never reported disconnected - the adapter power cycle again - arrived with the flag still false. BluetoothGatt.getServices() on a fresh client returns an empty but non-null list, so the cache check short-circuited, discovery was never issued, and every service, characteristic, and notify lookup threw No service found with uuid: ... for the life of the connection. A new client has by definition discovered nothing, so the invariant now lives where the client is created.

FixAndroid

[GitHub #1648] by martijnthe

ConnectionConfig.AutoConnect now actually reconnects a dropped link on Android. ConnectGatt’s autoConnect flag only keeps the platform’s background reconnect pending while the GATT client stays open, and OnConnectionStateChange has to close that client on every disconnect - closing it is what releases Android’s 7-client limit and terminates in-flight operations. Nothing re-opened it, so a peripheral that was powered off or carried out of range stayed Disconnected indefinitely even though the option is documented as enabling automatic reconnection. Connect(new ConnectionConfig(AutoConnect: true)) now arms a subscription that re-issues ConnectGatt when the link drops - the same shape Apple has always had - so the platform’s own background reconnect is restored rather than replaced by a retry loop: one ConnectGatt is issued and Android holds it pending until the peripheral returns. Reconnect attempts are throttled to one per second so a peripheral that rejects the reconnect cannot produce a status 133 connect/disconnect storm, an explicit CancelConnection() tears the subscription down before it can undo the cancel, and a Disconnected emitted while a fresh connect is already in flight is ignored. Fixes #1647.

BluetoothLE Hosting

FeatureLinux

BlueZ advertising is implemented. StartAdvertising and AdvertiseBeacon both threw NotSupportedException on Linux - the D-Bus plumbing behind them was a TODO. BlueZ inverts the model the other platforms use: rather than handing a payload to an API, the application exports an org.bluez.LEAdvertisement1 object and registers its path with LEAdvertisingManager1, and BlueZ then calls back into the process to read the properties. Shiny now exports that object - answering Properties.GetAll/Get, and Introspect so busctl can read it back - and registers it, mapping AdvertisementOptions onto BlueZ’s Type, LocalName, ServiceUUIDs, ServiceData, ManufacturerData and Includes. Two details that make it behave rather than merely work: Discoverable is omitted entirely on a broadcast-type advertisement, which BlueZ rejects the whole registration over, and every property that has no value is omitted rather than sent empty, which it also rejects. BlueZ’s Release() is honoured, so an adapter power-down, a bluetoothd restart, or another client taking the last advertising slot clears IsAdvertising instead of leaving it stuck on. Each registration takes a fresh object path, so a Stop immediately followed by a Start cannot collide with the previous registration BlueZ has not finished dropping. Note the consequence of the callback model: the process must stay alive and on the system bus for the advertisement to keep running.

BREAKINGFix

AdvertiseBeacon broadcast a byte-swapped UUID, major and minor - no receiver could match the beacon. Every multi-byte field in an iBeacon payload is big-endian, but the packet was assembled from Guid.ToByteArray() and BitConverter.GetBytes(), both of which are little-endian on every platform Shiny targets. The UUID’s first three fields and both the major and minor therefore went out reversed. Android additionally prefixed 0xBE 0xAC - AltBeacon’s identifier - where iBeacon requires 0x02 0x15, so the payload was not an iBeacon at all, and Mac Catalyst/macOS wrote the same reversed bytes into kCBAdvDataAppleBeaconKey. All three now build the packet through IBeaconPacket, which is big-endian throughout and covered by round-trip tests against a known-good advertisement. This is a behaviour change: a receiver that was matching the previously-broadcast (reversed) UUID will stop matching, because the device now advertises the UUID you actually asked for.

FeatureWindows

Windows can broadcast iBeacon. AdvertiseBeacon threw NotSupportedException on Windows, but WinRT has no problem with it - an iBeacon is a manufacturer data section, and BluetoothLEAdvertisementPublisher takes those. It now works the same as everywhere else.

Feature

AdvertisementOptions can carry a real payload. New ServiceData, ManufacturerData, IsConnectable and IncludeTxPower properties, so a peripheral can advertise arbitrary data rather than only a local name and service UUIDs - which is what beacon formats, and most proprietary discovery schemes, actually need. Supported on Android, Windows and Linux. Apple’s startAdvertising reads only the local name and service UUID keys and silently discards anything else in the dictionary, so setting either payload property throws there with a message naming the limit, rather than advertising something that never goes out.

Chore

AdvertisementServiceData and ManufacturerData moved from Shiny.BluetoothLE to Shiny.BluetoothLE.Common, so the peripheral role can describe the payloads it advertises without depending on the central role. Same namespace, so nothing recompiles, and type forwards keep already-compiled assemblies resolving.

Feature

IBeaconPacket (in Shiny.BluetoothLE.Common, so both roles can reach it) reads and writes the 23-byte iBeacon manufacturer payload - Build(uuid, major, minor, txPower), Read(span) and IsIBeacon(companyId, span). Use it rather than hand-rolling the bytes; the endianness trap above is easy to fall into and silent when you do.

FixiOS

AddService(...) and StartAdvertising(...) hung when called before the peripheral manager powered on. A CBPeripheralManager reports Unknown until its first state callback lands, and CoreBluetooth drops addService / startAdvertising issued below PoweredOn without ever invoking the completion delegate. Both methods await exactly that delegate, so a call made at startup - registering [BleService] classes from a hosting builder, say - never completed and never faulted. Both now wait out the power-on handshake first and throw when the adapter turns out to be unusable, instead of awaiting a callback the OS will not send. This does not prompt for anything; you still call RequestAccess() yourself to surface permission state to the user. Applies to iOS, Mac Catalyst and macOS. Regression introduced in 5.0.

Beacons

Feature

Shiny.Beacons is back, and now covers every platform. iBeacon ranging, background region monitoring, and broadcasting across iOS, Mac Catalyst, macOS, Android, Windows, Linux and Blazor WebAssembly, with Eddystone (UID, URL and TLM) added as a first-class citizen alongside it. AddBeaconRanging(), AddBeaconMonitoring<TDelegate>(), AddEddystoneScanning() and AddBeaconBroadcasting() register the four capabilities independently, so an app that only wants to read a beacon does not pay for the foreground service or the always-on location prompt that monitoring needs. There is no tvOS target: tvOS binds no CLBeacon type of any kind, so iBeacon is impossible there and an Eddystone-only surface that threw for half its members was not worth shipping.

Feature

Eddystone - UID, URL and TLM. IEddystoneScanner.WhenFrameReceived() emits typed frames: EddystoneUidFrame (10-byte namespace + 6-byte instance), EddystoneUrlFrame (with the full scheme and top-level-domain compression table, so https://www.example.com/ costs 9 bytes on the air), and EddystoneTlmFrame (battery volts, temperature, advertisement count, uptime). The spec’s two sentinel values are honoured rather than passed through: 0 millivolts means the beacon is mains powered and 0x8000 means no temperature sensor is fitted, both surfaced as null instead of as a flat battery and a 128°C beacon. Encrypted TLM is handed back intact for a caller holding the identity key, and EID frames surface their raw rotating identifier - resolving one needs the Curve25519/AES-EAX derivation from the EID spec, which is not implemented. Because Eddystone rides in service data under 0xFEAA rather than manufacturer data, it works identically on every platform including Apple’s, and filtering the scan on that UUID is also what lets it keep delivering while an iOS app is backgrounded.

Feature

Distance estimates are filtered, and the estimator is pluggable. BLE RSSI swings 10 dBm or more between consecutive advertisements from a stationary beacon, which a per-packet distance calculation turns into metres of jitter - and per-packet is exactly what the pre-5.0 module did. Every sample now goes through RssiFilter, a windowed trimmed mean (20 seconds, top and bottom tenth discarded) before it reaches an IBeaconDistanceEstimator. Two ship: PathLossDistanceEstimator (d = 10^((txPower-rssi)/(10n)), the default, with n configurable from free-space 2.0 up towards 3-4 for cluttered indoor spaces) and CurveFitDistanceEstimator (the Radius Networks/AltBeacon empirical fit, for parity with other Android beacon stacks). Window, trim fraction, default calibration power, proximity thresholds and region exit timeout are all on BeaconRangingOptions. On Apple platforms CoreLocation does its own smoothing and hands back a distance directly, so the filter and estimator are deliberately bypassed there and only the thresholds apply.

Fix

Proximity was computed from a formula that was not a distance in any unit. CalculateProximity evaluated Math.Pow(10, (txpower - rssi) / 20) and compared the result against 6E-6 and 0.5E-6, so in practice every beacon at every distance came back Immediate. Proximity is now derived from the estimated distance against Apple’s own boundaries - under 0.5 m immediate, under 3 m near, beyond that far - and both thresholds are configurable.

Fix

A beacon region entered from cold never raised an entry event. The Android monitoring task seeded the first sighting with state.IsInRange ??= true and then tested if (!state.IsInRange.Value) before firing, so the very transition monitoring exists to report was swallowed on every first encounter. Only a beacon that had already been seen, gone out of range, and come back could produce an Entered. The state machine is now a separate testable type (BeaconRegionMonitor) with no Bluetooth dependency, covered by tests driving a fake clock through entry, silence, exit, re-entry, and per-region notify flags.

Fix

Restarting monitoring crashed with a duplicate key. StartScan added every stored region into a dictionary it never cleared, and the repository-change handler added again on top of that, so a second start - or a region re-registered with new bounds - threw An item with the same key has already been added. Re-registering an identifier now updates the region in place, which is a legitimate way to change what a region matches.

Fix

Major = 0 was rejected as invalid. BeaconRegion threw ArgumentException on major < 1, making zero - a perfectly legal iBeacon major and minor value - impossible to monitor or range. Only the genuine rule remains: a minor requires a major.

Fix

Any manufacturer payload starting 0x02 0x15 was parsed as an iBeacon, whichever company identifier it arrived under. The company id is now checked against Apple’s 0x004C; BeaconRangingOptions.AllowNonAppleCompanyId re-enables the loose behaviour for the handful of vendors that ship iBeacon-shaped payloads under their own identifier.

FixAndroid

The monitoring foreground service declared the wrong type. It ran as ForegroundService.TypeLocation, but a BLE scan is a connected-device activity, and from Android 14 the declared type has to match what the service does or the service is refused outright. It is now TypeConnectedDevice and asks for FOREGROUND_SERVICE_CONNECTED_DEVICE - which also means beacon monitoring no longer prompts for a location permission it never used. Add <uses-permission android:name="android.permission.FOREGROUND_SERVICE_CONNECTED_DEVICE" /> to your manifest.

FixAndroid

Ranging scanned in ScanMode.Balanced, which delivers a fraction of the advertisements the radio could report - and averaging is only as good as its sample count. Ranging now uses LowLatency and monitoring LowPower, with scan batching off for both: batched results arrive with stale, coalesced RSSI values that defeat the filter.

FeatureiOS

Region monitoring uses CLMonitor with CLBeaconIdentityCondition on iOS and Mac Catalyst 18+, the same path Shiny.Locations already takes for geofences - including the CLServiceSession background delivery needs and the cold-start replay suppression that stops a re-attached condition from firing a spurious entry. Below 18 it falls back to CLLocationManager region monitoring, where iOS’s 20-region-per-app cap (shared with geofences) is now enforced with a named error instead of iOS silently dropping the excess.

FeaturemacOS

macOS ranges iBeacons and reads Eddystone. It has no beacon region API in CoreLocation at all, so the monitoring manager registers - keeping shared startup code compiling and running - but reports AccessState.NotSupported and throws from StartMonitoring. Branch on CurrentStatus, not on OperatingSystem.IsMacOS().

FeatureLinux

Linux broadcasts both formats. This needed BlueZ advertising implementing in Shiny.BluetoothLE.Hosting.Linux first, where StartAdvertising was an unimplemented stub - see the BluetoothLE Hosting release notes. Linux is now the only non-Apple platform where every beacon capability works: ranging, monitoring, Eddystone and broadcasting.

FeatureBlazor

Shiny.BluetoothLE.Blazor now surfaces manufacturerData and serviceData from Web Bluetooth advertisements, which it previously discarded - IAdvertisementData.ManufacturerData and .ServiceData both returned null. Both beacon formats are therefore readable in the browser wherever navigator.bluetooth.requestLEScan is available (Chromium, behind #enable-experimental-web-platform-features). The chooser fallback carries no advertisement payload, so beacons stay invisible through that path.

Network Discovery

FeaturetvOS

tvOS support. Shiny.Net.Discovery now ships a net10.0-tvos target with the full API - mDNS/DNS-SD browsing, resolution and publishing over NSNetService, plus the managed SSDP and WS-Discovery transports. As on iOS, Bonjour goes through the system mDNSResponder rather than raw multicast, so you need NSBonjourServices and NSLocalNetworkUsageDescription in Info.plist but not the multicast entitlement.

Screen Recording

FeaturetvOS

tvOS support. Shiny.ScreenRecorder now ships a net10.0-tvos target. ReplayKit records the app’s own UI on tvOS just as it does on iOS, including system audio, pause/resume, bitrate control and downscaling. ScreenRecorderCapabilities.Microphone is not advertised on tvOS - an Apple TV has no microphone and RPScreenRecorder carries no MicrophoneEnabled there - so a request with IncludeMicrophone is rejected by validation.

Initial Release

Feature

New Shiny.ScreenRecorder package — cross-platform screen recording for Android, iOS, Mac Catalyst, macOS and Windows, with Shiny.ScreenRecorder.Linux covering Linux through the xdg-desktop-portal ScreenCast API and Shiny.ScreenRecorder.Blazor covering the browser. Register services.AddScreenRecorder() and inject IScreenRecorder to record the screen to a video file with optional microphone and system audio, pause and resume, and pick a display or window on desktop.

Feature

IScreenRecorder.Capabilities publishes a ScreenRecorderCapabilities flags value describing what the current platform can actually do, and a request asking for something outside it throws ScreenRecorderNotSupportedException before any native call happens — because a recording that silently came out without the microphone, at the wrong frame rate, or of the wrong display is worse than one that refused to start. The flags are read off the instance rather than inferred from the target framework, because they differ within a platform as well as between them.

Feature

Start(request) returns an IScreenRecording only once frames are genuinely being written, not when the request was accepted — so a consent dialog, a compositor picker or an Android foreground-service promotion all complete first. Stop() returns a ScreenRecordingResult with the path, duration, byte size, encoded dimensions and the MIME type actually produced. Disposing the session without stopping cancels it and deletes the partial file. One recording at a time: Start throws while another is in flight, matching the restriction every platform underneath already has.

Feature

IScreenRecording.Faulted reports the OS ending a recording without being asked — the user revoking the capture, the system pre-empting it, the target going away, the encoder failing, or MaxDuration elapsing — and carries whatever was salvaged, so a recording cut short still yields a playable file rather than a silent truncation. This is not an edge case: it is the normal way a screen recording ends on several of these platforms.

Feature

Pause()/Resume() close the gap in the timeline rather than leaving a frozen stretch in the middle of the file — later timestamps are shifted back by the paused span. Only the browser pauses natively; everywhere else the capture keeps running and frames are dropped, so a long pause still costs battery. Elapsed excludes the paused span and matches the duration of the finished file.

Feature

GetTargets() lists displays, windows and applications on macOS and Windows so an app can offer its own picker, with Target on the request selecting one. Mobile has no concept of a target, and Linux and the browser hand selection to the compositor — both throw here and show their own picker during Start instead.

FeatureAndroid

Backed by MediaProjection into a VirtualDisplay, encoded with MediaCodec (a surface-fed H.264 encoder plus AAC) into a MediaMuxer. MediaCodec rather than the far simpler MediaRecorder for one reason: MediaRecorder.setAudioSource takes a single source and playback capture is not one of them, so app audio is only reachable through AudioRecord + AudioPlaybackCaptureConfiguration — wanting it at all forces the whole pipeline down. Mic and app audio are summed with saturation when both are requested.

FeatureAndroid

Consent runs through a transparent, no-history activity in the package, and the required mediaProjection foreground service is started before getMediaProjection is called — the ordering Android 14 (API 34) made mandatory and which throws SecurityException if reversed. Both are merged into the consuming app’s manifest automatically. Screen consent cannot be pre-granted, so RequestAccess answers only for the microphone and reports AccessState.Unknown for the screen.

FeatureiOS

Backed by RPScreenRecorder.startCapture feeding an AVAssetWriter — not startRecording, which keeps the movie inside ReplayKit and only surrenders it through RPPreviewViewController, a user-facing share sheet that is no use to a library promising a file path. This records the app’s own UI only; system-wide capture needs a Broadcast Upload Extension, a second app target no NuGet package can deliver. The app must be in the foreground, and ReplayKit stopping on an incoming call or a screen lock arrives as Faulted rather than as a truncated file.

FeaturemacOS

Backed by ScreenCaptureKit, with two paths. macOS 15+ uses SCRecordingOutput, which writes the MP4 itself and adds microphone capture — but cannot be paused, since a recording output cannot be detached and reattached mid-file. macOS 12.3–14 pumps SCStream sample buffers through the same AVAssetWriter the Apple mobile backend uses, which can synthesise a pause but has no microphone source. PauseResume and Microphone therefore differ by OS version rather than the modern path being crippled to make the flags uniform. SCShareableContent supplies displays, windows and applications for GetTargets(), and CGPreflightScreenCaptureAccess/CGRequestScreenCaptureAccess drive the Screen Recording prompt — neither is bound in the macOS SDK, so both are reached by LibraryImport.

FeatureWindows

Backed by Windows.Graphics.Capture — a free-threaded Direct3D11CaptureFramePool bridged into a MediaStreamSource and encoded to MP4 by MediaTranscoder, so no frame is ever copied into managed memory. Displays and windows come from IGraphicsCaptureItemInterop rather than the system picker, so GetTargets() returns a real list the app controls. The COM and D3D11 interop is hand-rolled through vtable calls rather than ComImport, keeping the package AOT- and trim-clean.

FeatureWindows

Windows records video only. Windows.Graphics.Capture has no audio path at all — unlike every other platform here, its capture API captures pixels and nothing else. Capabilities reports neither Microphone nor SystemAudio and requesting either throws, rather than silently producing a silent file. System audio would require a hand-written WASAPI loopback capture and is tracked separately.

FeatureLinux

Shiny.ScreenRecorder.Linux drives org.freedesktop.portal.ScreenCast over D-Bus for consent and frames, then hands the PipeWire node to gst-launch-1.0 (Wayland and X11) or falls back to ffmpeg -f x11grab on X11. Stopping sends SIGINT rather than SIGKILL, because both encoders need it to flush and write the MP4 index — a killed encoder leaves a file no player will open. Encoder availability, the session type and the PulseAudio monitor source are all probed at runtime, so a machine missing the pieces reports ScreenRecorderCapabilities.None rather than failing when the user presses record. Flatpak sandboxes are not supported.

FeatureBlazor

Shiny.ScreenRecorder.Blazor records through getDisplayMedia and MediaRecorder. It is the only platform where pause is native, and the only one where ScreenRecordingResult.FilePath is null — the browser has no filesystem, so OpenRead() streams the blob back through an IJSStreamReference and DownloadRecording(result, fileName) hands it to the user. The container varies by browser and the result says which: Safari and recent Chrome produce MP4/H.264, Firefox produces WebM/VP9. Display audio and the microphone are summed through a WebAudio graph when both are requested, since MediaRecorder encodes only one audio track. Requires a secure context and a user gesture, and Probe() must run once before Capabilities reports anything.

Feature

ScreenRecordingResult.OpenRead() is the portable way to read a recording back — it opens the file where there is one and streams the blob out of JavaScript where there is not, so calling code stays the same across every platform. MimeType reports what was actually produced rather than what was asked for.

Feature

MaxWidth downscales while preserving aspect ratio, rounding both sides to even because H.264 cannot encode odd dimensions — worth setting on almost any recording, since a modern phone or Retina display at native resolution produces very large files for very little visible gain. When no bitrate is given, one is estimated from the resolution and clamped to a range that keeps screen text legible without producing gigabyte files.

Jobs

FeaturetvOS

tvOS support. Shiny.Jobs now ships a net10.0-tvos target. tvOS carries the same BGTaskScheduler iOS does, so background processing jobs schedule and run identically - declare BGTaskSchedulerPermittedIdentifiers and the processing background mode in Info.plist exactly as you would on iOS. Jobs do not run on the tvOS simulator, matching the iOS behaviour.

Fix

Fixed trim/AOT warning IL2091 from JobRegistrar.Register<TJob>. The TJob generic on Register<TJob> and AddJob<TJob> now carries DynamicallyAccessedMemberTypes.Interfaces alongside PublicConstructors, matching what AddSingletonAsImplementedInterfaces requires so the job’s interfaces survive trimming.

Push Notifications

FeaturetvOS

tvOS support. Shiny.Push now ships a net10.0-tvos target. Registration, token handling and silent/background push (IPushDelegate.OnReceived) work as they do on iOS. What tvOS does not have is any notification a user can see or tap: UNNotificationContent there carries nothing but a badge count, so there is no UNNotificationResponse, no foreground presentation, and OnEntry is never raised. RequestAccess() accordingly asks for UNAuthorizationOptions.Badge alone on tvOS rather than Alert + Badge + Sound.

Live Activities

FeatureAndroid

The notification channel is no longer hard-coded English. AddLiveActivities(configure) and AddLiveActivities<TDelegate>(configure) take a new LiveActivityOptions carrying ChannelName and ChannelDescription - what the user reads in Android’s per-app notification settings. They are re-applied on every startup rather than only at first channel creation, because Android treats a repeat registration with the same channel id as an update to those two fields, so a translation that ships after first launch still reaches the settings screen. Channel importance and sound stay unconfigurable on purpose: Android ignores both once the channel exists, and from that point they belong to the user. iOS is unaffected - an ActivityKit activity has no channel.

Feature

New module: Shiny.Mobile.LiveActivities. One typed API in front of the persistent, updating status surface both phone platforms grew independently - iOS/iPadOS Live Activities (ActivityKit, Lock Screen and Dynamic Island) and Android 16 Live Updates. ILiveActivityManager starts, updates and ends them; LiveActivityContent carries title, body, short status, progress, stale date, relevance score and a free-form string/string data bag your own widget reads. The shared contract is a state, not a UI tree, so the two platforms cannot drift in what they say. See Getting Started.

FeatureiOS

ActivityKit is Swift-only with no Objective-C interface, so it is reached through an @objc shim built from an Xcode project and shipped as Shiny.iOS.LiveActivities.Binding - pulled in automatically, never referenced directly. Requires iOS/iPadOS 16.2+ and a SwiftUI widget extension in the app bundle; a ready-made one ships in templates/WidgetExtension and its Swift is compile-checked in CI. See The iOS Widget Extension.

FeatureAndroid

Android 16 (API 36+) uses Notification.ProgressStyle with requestPromotedOngoing and setShortCriticalText, earning the status bar chip and always-on-display treatment. Android 8-15 degrades to an ordinary ongoing notification with a determinate progress bar. RequestAccess() asks for POST_NOTIFICATIONS on API 33+.

FeatureiOS

Both APNs token kinds are surfaced through ILiveActivityDelegate: OnPushTokenChanged for a single activity’s update token, and OnPushToStartTokenChanged for the device’s push-to-start token (iOS 17.2+), which lets a server start an activity with the app closed. They pair with PushTokenKind.LiveActivityUpdate / .LiveActivityStart in Shiny.Extensions.Push. Send an ordinary alert to one of these and APNs answers DeviceTokenNotForTopic, so keep the kinds separated. See Push Tokens & Server Updates.

Feature

LiveActivityProgress.FromRange(start, end) emits a self-animating time range the system advances on its own, instead of a fixed fraction. Strongly preferred for anything time-based: every push update costs budget, and a suspended iOS app sends none at all, so a fraction-based bar freezes until the app wakes.

Feature

LiveActivityContentSchema is public - the JSON contract shared by this library, the Swift ShinyActivityAttributes.ContentState a widget renders, and the content-state a server pushes - so a server payload can be built or verified against exactly the shape the app produces. Note that dates inside content-state are seconds since 2001-01-01 (Swift’s stock Codable encoding), not Unix; a drift here does not throw, it silently stops the activity refreshing.

Chore

Mobile only, and the package name says so. iOS/iPadOS and Android are the entire supported list; macOS, Mac Catalyst, tvOS, Windows, Linux and Blazor resolve NoOpLiveActivityManager, where IsSupported is false and every call is a safe no-op - so shared view models need no platform checks. There is no Apple desktop implementation to add: ActivityKit.framework ships in the macOS SDK, but every public type in it is annotated @available(macOS, unavailable) / @available(macCatalyst, unavailable) / @available(tvOS, unavailable) / @available(watchOS, unavailable). What a Mac shows is an iPhone’s activity mirrored over iPhone Mirroring, which no Mac app declares or drives - hence Shiny.iOS.LiveActivities.Binding rather than Shiny.Apple.*.

HTTP Transfers

EnhancementiOS

The Live Activity renderer for transfer progress now ships inside Shiny.Net.Http. There is no longer a separate package and no second registration call - AddTransferProgress() registers the iOS renderer exactly as it already registered the Android one, and pulls Shiny.Mobile.LiveActivities in on the -ios target alone, so no other head carries ActivityKit. The two ActivityKit-only knobs moved onto the same options object as opts.LiveActivity.Kind and opts.LiveActivity.RequestPushToken. iOS still needs the widget extension from templates/WidgetExtension and NSSupportsLiveActivities in Info.plist. See Transfer Progress and Live Activities.

FeaturetvOS

tvOS support. Shiny.Net.Http now ships a net10.0-tvos target backed by the same background NSUrlSession the iOS implementation uses, so uploads and downloads continue while the app is suspended. Note that an Apple TV has no user-visible file system and limited persistent storage - write transfer output to the cache directory and treat it as evictable.

Data Sync

FeaturetvOS

tvOS support. Shiny.Data.Sync now ships a net10.0-tvos target, using the same NSUrlSession-backed DataSyncManager as iOS and Mac Catalyst.

5.5.0 - August 26, 2026

BluetoothLE

FixAndroid

[GitHub #1646] by martijnthe

IBleManager.GetKnownPeripheral(uuid) now resolves a persisted identifier without a scan. The lookup only ever searched the in-process peripheral cache, which is populated by scanning, so after a process restart it could never hit and reconnecting to a saved device required a fresh scan on every cold start. It now falls back to BluetoothAdapter.GetRemoteDevice - decoding the MAC back out of the identifier that Peripheral.GetUuid encoded it into - and returns the same cached peripheral instance a later scan would hand back, matching what Apple already does with RetrievePeripheralsWithIdentifiers. Note that Android has no way to ask whether the OS has seen an unbonded LE device, so a well-formed identifier now always resolves and an absent peripheral fails at connect rather than at lookup.

BluetoothLE Hosting

Fix

IPeripheral.Mtu and BleServiceContext.Mtu now mean the same thing on every platform. Both were documented as the “negotiated MTU” while the value returned differed by platform - Apple gave the usable ATT payload (MaximumUpdateValueLength), Android, Windows, and Linux gave the raw ATT MTU. Sizing a notification against it was therefore correct on Apple and 3 bytes over the link limit everywhere else, which some stacks silently truncate rather than reject. The property is now the usable payload - the negotiated ATT MTU minus the 3-byte ATT header - on all platforms, matching Shiny.BluetoothLE’s IPeripheral.Mtu. Cap notification and read payloads at Mtu directly; do not subtract the header again. Linux hosting’s pre-negotiation default drops from 23 to 20 for the same reason.

BREAKINGFixAndroid

IPeripheral.Mtu was assigned the raw onMtuChanged value with no header subtraction, so it started life as a payload (20) and became an ATT MTU after the central negotiated - two different units on one property. It now subtracts BleConstants.AttHeaderSize consistently. If you were compensating with context.Mtu - 3, remove the subtraction; if you were using Mtu as-is you were overshooting by 3 and are now correct.

BREAKINGFixWindows

IPeripheral.Mtu returned GattSession.MaxPduSize, which is the ATT MTU. It now subtracts the 3-byte ATT header. Same migration note as Android.

Feature

Source generator for GATT services and L2CAP listeners. Put [BleService] / [L2CapService] on a partial class and the generator emits the AddService(...) / OpenL2Cap(...) calls, the GattResult wrapping, the IsReplyNeeded/Respond and offset handling, the notify push API (NotifyX / XSubscribers / HasXSubscribers), and AddBleHostedServices() / AttachBleHostedServices(sp) / StartBleHostedAdvertising(name) extension methods on IBleHostingManager. Handler parameters bind by type in any order and any subset — ReadRequest/WriteRequest, the raw byte[], the offset, IPeripheral, a CancellationToken, and the generated context all just work. Nothing reflective is emitted, so it replaces the managed pattern removed in 5.0.0 without giving up AOT-cleanliness. The generator ships inside Shiny.BluetoothLE.Hosting under analyzers/dotnet/cs — nothing extra to install. See the new Source Generator page.

Feature

Per-connected-central context. Each [BleService] class gets a generated {ServiceClass}Context — a partial class you add your own properties to — created lazily per central and passed to any handler that declares it as a parameter. It carries Peripheral, ConnectionId, Mtu, ServiceUuid, Service, and a loosely typed Items bag, in the spirit of SignalR’s Hub.Context. Storage is a ConditionalWeakTable keyed on the peripheral rather than the public IPeripheral.Context slot, so it never collides with app state.

Feature

[RequestResponseCharacteristic] registers a characteristic as Write | Notify and pushes the handler’s returned bytes back to the central that wrote — a GATT write response cannot carry a payload, so the reply travels as a notification addressed to that central. Implement the generated OnBleResponseDropped hook to observe the case where the central was not subscribed.

Feature

[L2CapService(PsmService = ..., PsmCharacteristic = ...)] publishes the platform-assigned PSM as a GATT read characteristic (two little-endian bytes) on a service in the same compilation, which is the only in-band way a central can learn it. Listeners are opened before AddService, so a read immediately after registration returns a live value. L2CapChannel.ReadAll(cancellationToken) is a new IAsyncEnumerable convenience over the Rx DataReceived observable.

Enhancement

Several [BleService] classes may declare the same service UUID — the generator merges them into a single AddService call, which matters because BleHostingManager keys its services by UUID and would throw on a second registration. Declaring the same characteristic UUID in two merged classes is a compile error.

Enhancement

Fourteen compile-time diagnostics (SBH001-SBH014) cover invalid UUIDs, duplicate handlers for one characteristic, unbindable signatures, dangling PSM publications, and merge conflicts — mistakes that used to surface as a silent no-op or a runtime throw on device.

Enhancement

Generated UUIDs are always emitted in the full 128-bit form. Short forms like "180D" are accepted by Apple’s CBUUID.FromString but throw on Android, which goes through java.util.UUID.fromString — so a service that worked on iOS could fail on Android. This only applies to generated code; write full UUIDs yourself when calling AddService directly.

Locations

FixiOS

A background RequestAccess can now raise the “always” prompt after a foreground one has already run. GpsManager kept a single CLServiceSession and created it with ??=, so the first caller fixed the authorization requirement for the life of the process — an app that asked for GpsRequest.Foreground first (anything with a live map or a HUD) opened a when-in-use session, and every later GpsBackgroundMode.Standard / Realtime request reused it and could never escalate. The short-circuit above it made that silent: AuthorizedWhenInUse maps to AccessState.Restricted the moment a background request asks about it, which is exactly the state the “always” prompt exists to upgrade, so RequestAccess returned a refusal without presenting anything. The session is now created per requirement and replaced when a stronger one is needed — an existing always session still covers a foreground request, so a background grant is never torn down to ask for less.

FixiOS

RequestAccess no longer times out while the user is reading the permission dialog. The 30-second wall clock covered the whole exchange, so anyone who took their time answering got a TimeoutException thrown out from under a dialog still on screen. It now covers only the session failing to report any diagnostic at all, and is disarmed as soon as the OS says a request is in progress.

FixiOS

Concurrent RequestAccess calls are serialized. Each call now owns the session it waits on, so two in flight together would otherwise leave the first waiting on a handler that had been replaced.

Network Discovery

FixAndroid

Resolving a service on Android 14 (API 34) or later no longer crashes the app with Java.Util.Concurrent.RejectedExecutionException. NsdManager dispatches the unregistration confirmation through the Executor handed to registerServiceInfoCallback after unregisterServiceInfoCallback returns, so shutting that executor down at the end of a resolve left the framework rejecting its own task on its handler thread - an uncaught exception that killed the process. Callbacks now run inline on NsdManager’s dispatch thread with nothing to shut down. Affects Browse/BrowseOnce with MdnsBrowseConfig.ResolveServices enabled and direct IMdnsManager.Resolve(...) calls.

Wi-Fi

Initial Release

Feature

New Shiny.Net.Wifi package — cross-platform Wi-Fi for Android, iOS, Mac Catalyst, macOS and Windows, with Shiny.Net.Wifi.Linux covering Linux through NetworkManager. Register services.AddWifi() and inject IWifiManager to scan for access points, join and leave networks, manage the networks the device has saved, read the current network, and power the radio. Backed by WifiManager + ConnectivityManager on Android, NEHotspotConfiguration + CaptiveNetwork on iOS/Mac Catalyst, CoreWLAN on macOS, the WiFiAdapter WinRT API on Windows, and NetworkManager over D-Bus on Linux.

Feature

IWifiManager.Capabilities publishes a WifiCapabilities flags value describing what the current platform can actually do, and anything unavailable throws WifiNotSupportedException naming the specific limit. Wi-Fi is the most unevenly exposed capability across these platforms — iOS has no scanning API, neither phone OS will show an app the networks the user saved, only three platforms can raise a hotspot — and the API states that rather than returning empty results that are indistinguishable from a quiet neighbourhood.

Feature

Scan(...) returns one WifiNetwork per BSSID — SSID, WifiSecurity (Open/WEP/WPA/WPA2/WPA3/Enterprise/OWE), signal in both dBm and a 0-100 percentage, frequency, and derived Band and Channel. Results are strongest-first. Networks in a WPA2/WPA3 or OWE transition mode report the stronger scheme, so a caller never sees a network as weaker than it is.

Feature

Connect(new WifiConnectionRequest(ssid) { Passphrase = ... }) joins a network and returns only once an address has been assigned, not merely on association — a result with no IP on it is not useful to the caller. Disconnect() leaves. WifiConnectionException carries the reason a join failed: wrong passphrase, out of range, user declined the system prompt, or DHCP timeout.

Feature

Known networks — GetKnownNetworks() lists what the device has saved as KnownWifiNetwork (an opaque platform-issued Id, plus SSID, security, hidden flag and AddedByThisApp), Forget(id) deletes one, and Connect(id) rejoins one without the passphrase being handed over again. The three sit behind the KnownNetworks, ForgetNetwork and ConnectKnownNetwork capability flags. Id is the platform’s own handle — a NetworkManager connection UUID on Linux, a numeric network id on Android below API 29, the SSID everywhere else — so round-trip it rather than parsing it.

Feature

What counts as “known” is scoped differently per platform and the API says which rather than papering over it: iOS, Mac Catalyst and Android disclose only the entries your own app created, while Windows, macOS and Linux hand back every profile on the machine. Neither phone OS will show an app the networks the user saved themselves, so AddedByThisApp exists to tell the two cases apart and a “manage all my Wi-Fi networks” screen is a desktop-only idea.

FeatureiOS

Saved networks on iOS and Mac Catalyst map onto NEHotspotConfigurationManager — getConfiguredSSIDs for the listing and removeConfiguration(forSSID:) for Forget. Only names come back; a stored configuration carries no security type or hidden flag. Connect(id) is not available: a configuration is a standing instruction iOS acts on when the network is in range, and there is no call to force the join.

FeatureAndroid

Remember = true now does something on Android 11+. The specifier join is still what gets the device onto the network, but a WifiNetworkSuggestion is registered alongside it so the OS can rejoin later — which is also what makes the network visible to GetKnownNetworks(). The suggestion only takes effect once the user approves the notification Android raises, and a failure to register one never fails the join. Below API 29 the legacy WifiConfiguration list is used instead, and its numeric network id is a real handle, so Connect(id) works there.

FeatureWindows

Saved profiles are outside WinRT entirely — WiFiAdapter cannot list, delete or join one — so GetKnownNetworks(), Forget() and Connect(id) P/Invoke wlanapi.dll directly (WlanGetProfileList, WlanGetProfile, WlanDeleteProfile, WlanConnect) rather than shelling out to netsh and parsing localised console output. Security and the hidden flag are read out of each profile’s XML; one that cannot be parsed is still reported, as unknown.

Feature

macOS lists the machine’s preferred-network list from CWConfiguration.networkProfiles and rejoins from the login keychain, so your app never sees the passphrase. Forget() there means committing a whole CWConfiguration, which macOS gates behind an SFAuthorization a normal app cannot raise — it throws WifiPermissionException explaining that. Linux reads, activates and deletes NetworkManager’s saved connections directly, with deletion gated on the polkit action org.freedesktop.NetworkManager.settings.modify.system.

Feature

IWifiManager.GetCurrentNetwork(ct) reports the joined network as a WifiNetworkInfo — SSID, BSSID, security, signal and frequency alongside every IP address, DNS resolver, gateway and subnet mask, with IPv4Address/IPv6Address shortcuts. The Changed event fires with the new WifiNetworkInfo? (null when the device drops off Wi-Fi) and is de-duplicated: the native watchers behind it all fire several times per real change. Subscribing now delivers the current network once up front, so a handler does not sit blind until the network next moves. WifiNetworkInfo compares its address lists by value rather than by reference, so snapshots can be diffed directly. The addressing fields are best-effort individually: a platform is allowed not to implement one — GatewayAddresses is unsupported on Android, and the sandboxed platforms vary on the rest — and a refused field comes back null or empty rather than throwing, so one missing field never costs the caller the whole read.

FixiOS

The SSID and BSSID of the joined network came back null on iOS 14 and later. CNCopyCurrentNetworkInfo was the source, and since iOS 14 it returns nothing unless the calling app itself configured the network being asked about — it succeeds and hands back an empty dictionary otherwise, so nothing failed and the name was simply missing. Reading now goes through NEHotspotNetwork.fetchCurrent, the iOS 14 replacement, which needs only the Access WiFi Information capability and location — not the case-by-case NEHotspotHelper entitlement its instance-side API once did. It reports more than CaptiveNetwork ever could, so Security and SignalStrengthPercent are now populated on iOS and Mac Catalyst instead of sitting at their defaults.

FixAndroid

The SSID and BSSID of the joined network came back null on Android 12 (API 31) and later even with ACCESS_FINE_LOCATION granted. API 31 redacts both out of every pull-style read — WifiManager.getConnectionInfo and the WifiInfo hanging off getNetworkCapabilities alike — regardless of permissions, and hands them out only through a NetworkCallback registered with FLAG_INCLUDE_LOCATION_INFO. Shiny now registers its watcher with that flag and serves reads from what it delivers, falling back to a short-lived callback (with a timeout, so a device that is off Wi-Fi returns null rather than hanging) when no watcher is running. Below API 31 the legacy getConnectionInfo path is unchanged — the redaction is what arrived in 31, not the deprecation.

BREAKINGFeature

IWifiManager.CurrentNetwork is replaced by Task<WifiNetworkInfo?> GetCurrentNetwork(CancellationToken ct = default). The synchronous property could not be made correct: the two platforms the module exists for both stopped answering synchronously, and a property that silently reports a null SSID is worse than one that makes the cost visible. Replace wifi.CurrentNetwork with await wifi.GetCurrentNetwork(); a Changed handler needs no change at all, since the new network already arrives in the event argument. On macOS, Windows, Linux and plain .NET the read is still synchronous underneath and the Task completes immediately.

Enhancement

New WifiSecurity.Psk — a pre-shared key whose WPA generation the platform did not name. iOS reports “personal” and nothing finer, and reporting that as Unknown would throw away what iOS does know while picking one of WPA/WPA2/WPA3 would be a guess. A switch over WifiSecurity that only handles Wpa2Psk/Wpa3Psk needs a case for this.

Feature

New IWifiHotspot (services.AddWifiHotspot()) raises an access point. Start(...) returns an IHotspotSession carrying the SSID and passphrase actually in use; disposing it brings the access point down. GetClients() lists joined devices with MAC address, IP and host name.

FeatureAndroid

The Android hotspot is a local-only hotspot — clients reach the device but get no route to the internet, because real tethering sits behind the signature permission TETHER_PRIVILEGED. The OS also generates the SSID and passphrase and offers no supported way to choose them (SoftApConfiguration.Builder exposes only the channel to non-system apps), so read them back off IHotspotSession.Info and show them to the user. GetClients() throws — Android has never exposed a client list and blocked the /proc/net ARP table apps read instead in Android 10.

FeatureWindows

Windows hotspot support goes through NetworkOperatorTetheringManager — real tethering that shares the machine’s current internet connection, honours the SSID, passphrase and band you supply, and can enumerate connected clients. Starting one with the machine offline fails, since there is no connection to share.

Feature

Linux hotspot support runs NetworkManager AP mode with ipv4.method=shared for DHCP and NAT, honours the full HotspotConfiguration, and lists clients from the kernel neighbour table filtered to the hotspot interface.

FeatureiOS

iOS and Mac Catalyst support joining, leaving and reading the current network, and nothing else. There is no scanning API — the only one that lists nearby networks lives inside a NEHotspotHelper, an entitlement Apple grants case by case — no hotspot API and no radio toggle. Requires the Hotspot Configuration and Access WiFi Information App ID capabilities plus NSLocationWhenInUseUsageDescription; without the location grant the SSID and BSSID come back null rather than failing, which is why RequestAccess() asks for it.

FeatureAndroid

Android needs ACCESS_WIFI_STATE, CHANGE_WIFI_STATE and ACCESS_FINE_LOCATION, plus NEARBY_WIFI_DEVICES from API 33. Joining uses a WifiNetworkSpecifier from API 29 (a system dialog, and the join itself is never persisted) and falls back to the legacy WifiConfiguration path below it. The radio toggle drops out of Capabilities from API 29, where setWifiEnabled was revoked for third-party apps.

Feature

macOS is backed by CoreWLAN and supports the full station API — scanning, associating, disassociating and powering the interface. Needs NSLocationWhenInUseUsageDescription, since macOS 14 gates scan results and the SSID on location the way iOS does. Windows needs the wiFiControl and radios capabilities; Linux gates the mutating calls behind the polkit actions org.freedesktop.NetworkManager.network-control and …enable-disable-wifi.

Enhancement

A scan that comes back empty because a permission was refused throws WifiPermissionException naming what is missing, rather than looking like an empty neighbourhood — Android returns an empty list instead of an error in that case. Android’s <unknown ssid> placeholder and the all-zero BSSID it substitutes without location permission are reported as null rather than passed through as literal strings.

Enhancement

WaitForAddress — the poll every connect path runs so a join returns with an address on it rather than on bare association — moved onto AbstractWifiManager instead of being copied into the Android, macOS, Windows and Linux managers. Linux also dropped the cache it kept purely to satisfy the old synchronous property, along with the blocking Task.Run(...).Wait(5s) prime behind it, and AndroidWifiManager.Dispose no longer blocks on its own Disconnect task.

FixAndroid

The internal receiver that picks up scan results below API 30 no longer carries a [BroadcastReceiver] attribute. It is registered from code — it has to be, since SCAN_RESULTS_AVAILABLE_ACTION is an implicit broadcast a manifest-declared receiver cannot get on API 26+ — but the attribute still put a <receiver> node in the generated manifest, and .NET for Android then failed the build of any app referencing the package with XA4213: The type 'Shiny.Net.Wifi.ScanReceiver' must provide a public default constructor.

Chore

The plain .NET target of the base package is a deliberate stub rather than a fallback: GetCurrentNetwork() still reports the IP, DNS, gateway and mask of the wireless interface and Changed still fires off NetworkChange, because that comes from the managed network stack — but every Wi-Fi-specific call throws, pointing at Shiny.Net.Wifi.Linux where relevant. Capabilities reports None.

Local Notifications

BREAKINGFeatureAndroid

New AndroidConfiguration sets app-wide defaults for how a notification tap launches your app - LaunchActivityFlags and LaunchActivityType - registered with services.AddNotifications(new AndroidConfiguration(...)). The shipped default is unchanged (NewTask | ClearTask), but apps whose taps should resume the running activity rather than cold start a fresh copy can now register NewTask | ClearTop | SingleTop instead. Breaking: AndroidNotification.LaunchActivityFlags is now ActivityFlags? (null = use the configured value) rather than ActivityFlags; assignment is unaffected, only code that reads the property needs updating. AndroidNotificationManager’s constructor also takes the new AndroidConfiguration, which matters if you subclass or construct it yourself. See Platform Specific.

FixAndroid

AndroidNotification.LaunchActivityType no longer loses its intent flags. Setting a specific launch activity built the intent with no flags at all, while the ClearTask branch that decides between TaskStackBuilder and PendingIntent.GetActivity still read the configured value - so a custom activity launched with mismatched behaviour. The flags are now applied on both paths.

HTTP Transfers

Feature

Transfer progress surfaces. New services.AddTransferProgress() mirrors background transfers onto whatever surface the platform offers - an iOS Live Activity, or the Android foreground-service notification - from one TransferProgressManager on every platform. It subscribes to UpdateReceived at startup, coalesces the progress firehose to one update a second, aggregates a batch into a single figure, and starts/updates/retires the surface, including when iOS relaunches the app in the background to finish a transfer. Nothing goes in your transfer delegate. What is shown is configured with the TransferProgressFields flags (file name, direction, percent, bytes, speed, time remaining, host) and TransferProgressShortStatus; wording is overridable through ITransferProgressDelegate. See Transfer Progress.

FixAndroid

Transfers no longer post two notifications. Android needs a foreground service to move bytes in the background, and that service must post a notification - but PerTransferNotificationStrategy posted its progress as a second notification, leaving the user with a progress entry alongside a redundant “Shiny service is continuing to transfer data in the background”. The new ForegroundNotificationRenderer re-posts the service’s own notification id instead, so there is exactly one.

EnhancementAndroid

The transfer notification is promoted to an Android 16 live update on API 36+ - Notification.ProgressStyle with requestPromotedOngoing and setShortCriticalText, which earns the status bar chip and always-on-display treatment. Android 8-15 degrades to an ordinary determinate progress bar.

EnhancementiOS

Progress can be emitted as a self-animating time range rather than a fraction (ProjectTimeRemaining, on by default). A background NSURLSession delivers no callbacks at all while the app is suspended, so a fraction-based bar freezes for most of a long transfer; a range keeps advancing with no app involvement, anchored in the past so the bar already sits at the true fraction rather than snapping to zero on every update. Falls back to a fraction when the transfer is stalled, paused, of unknown size, or the estimate exceeds MaximumProjection.

Feature

ITransferProgressRenderer is public: register your own and the same manager drives it, so you inherit the aggregation, coalescing and lifetime and implement only the drawing. TransferProgressContentBuilder is public and static too - FormatBytes, FormatRate, FormatDuration and FormatPercent are reusable in ordinary in-app progress UI.

BREAKINGChoreAndroid

PerTransferNotificationStrategy has been removed, along with AbstractTransferNotificationStrategy and the never-implemented SummaryTransferNotificationStrategy. It was the source of the duplicate notification above. Delete services.AddShinyService<PerTransferNotificationStrategy>() and call services.AddTransferProgress() instead - it covers Android and iOS from one registration, and ForegroundNotificationRenderer is protected virtual where the old strategy’s Customize was, so custom notification styling ports over. See Transfer Progress.

5.4.0 - August 2026

Core & Hosting

FixAndroid

AndroidLifecycleExecutor is now built from an explicit factory delegate instead of via container constructor selection. It derives from Java.Lang.Object and therefore must expose the (IntPtr, JniHandleOwnership) JNI constructor; containers that select a constructor by “most resolvable arguments” (DryIoc’s ConstructorWithResolvableArguments, used by Prism) had to weigh that overload and reported a misleading Error.UnableToFindCtorWithAllResolvableArgs on the executor whenever a real dependency further down the graph failed to resolve. The dependency that actually failed in practice was the keyed IKeyValueStore injected by AndroidPlatform — see the Stores 5.1.4 release notes for that half of the fix.

BluetoothLE

Fix

IPeripheral.Mtu is documented correctly at last. Mtu, ICanRequestMtu.RequestMtu, TryRequestMtu, and TryRequestMtuAsync all described their value as the “negotiated MTU”, but every platform returns the usable ATT payload - the negotiated ATT MTU minus the 3-byte ATT header. Anyone who took the docs literally and subtracted the header before fragmenting removed it twice; worse, anyone who “corrected” working code on the strength of the docs, or fed Mtu to an API that genuinely wants an ATT MTU, ended up 3 bytes over the link limit, which some stacks silently truncate rather than reject. The behaviour is unchanged on Android, Apple, and Windows - Shiny.BluetoothLE’s own WriteCharacteristicBlob has always chunked to Mtu as a payload - only the XML docs and the site were wrong. Note the deliberate asymmetry: RequestMtu(512) takes an ATT MTU (it goes straight to BluetoothGatt.requestMtu()) and emits 509, the payload.

FixLinux

IPeripheral.Mtu on BlueZ reported 512 - an ATT MTU, not the payload every other platform returns. Code that fragmented to peripheral.Mtu was writing 3 bytes over the link’s actual limit on every operation. It now reports 509, matching the contract above.

Feature