Platform Comparison

This page provides a factual comparison of implemented behavior in current code.

1. Core Capability Matrix

Legend:

  • ✅ implemented
  • ⚠️ implemented with platform-managed behavior
  • ❌ not implemented
Capability Android iOS/macOS Windows
Scanning
Device connection
GATT service discovery
Characteristic read/write
Characteristic listen/notify
Descriptor read/write
Request MTU ✅ API 21+
Read current MTU
Request connection priority
Read PHY ✅ API 26+ ⚠️
Set PHY ✅ API 26+
Open L2CAP channel ✅ API 29+ ✅ iOS 11+/macOS 10.13+
Read RSSI while connected
Broadcaster start/stop
Local GATT service creation
Force-disconnect a subscribed GATT client

2. Unsupported Operation Semantics

Windows behavior:

  • Unsupported operations throw NotSupportedException.
  • This includes L2CAP APIs, some advanced connected-device APIs, and force-disconnecting a subscribed GATT client from a broadcaster (Windows exposes no API for a peripheral to disconnect a specific central).

DotNetCore fallback behavior:

  • BLE runtime APIs throw PlatformNotSupportedException.

iOS/macOS behavior:

  • Some operations that are configurable on Android are system-managed and exposed as no-op or unsupported paths depending on API.
  • Reliable write transactions are not supported.

3. API Shape Is Shared, Behavior Varies

The same abstraction can have different runtime behavior by platform.

Example: connection priority

await device.RequestConnectionPriorityAsync(BluetoothConnectionPriority.High);

Behavior:

  • Android: executes native connection-priority request.
  • iOS/macOS: platform-managed behavior.
  • Windows: throws NotSupportedException.

Example: L2CAP

try
{
    var channel = await device.OpenL2CapChannelAsync(psm);
    await channel.WriteAsync(payload);
}
catch (NotSupportedException)
{
    // Windows fallback path.
}

4. Configuration Differences

Android has the broadest explicit tuning surface in options objects (scan settings, connection priority, PHY, API-gated capabilities).

iOS/macOS supports platform-specific options for scanning/connection/broadcasting integration points, but many transport details are managed by CoreBluetooth.

Windows option surface is narrower for advanced transport controls because those operations are currently not implemented.

5. Practical Cross-Platform Baseline

If a single behavior baseline is required across all native platforms, use:

  • Scanning
  • Connect/disconnect
  • Service/characteristic/descriptor discovery
  • Characteristic read/write
  • Characteristic notifications/indications

Treat the following as optional capability paths with guards:

  • L2CAP
  • Connection priority tuning
  • PHY tuning
  • Connected RSSI reads
  • Broadcasting