Table of Contents

Enum NearbyAvailability

Namespace
Plugin.Maui.NearbyConnectivity
Assembly
Plugin.Maui.NearbyConnectivity.dll

What prevents nearby connectivity from working, worst first.

public enum NearbyAvailability

Fields

Available = 0

Nothing blocks advertising or discovery.

BluetoothDisabled = 2

Bluetooth is supported but currently turned off. Prompt the user to turn it on; an application cannot enable it directly.

Android only, where Nearby Connections uses Bluetooth for discovery. Multipeer Connectivity has not used Bluetooth since roughly 2016. Apple removed the implementation and its peer-to-peer support is Wi-Fi only, so iOS never reports this, and telling an iOS user to enable Bluetooth would be advice about a radio the platform does not use.

InvalidConfiguration = 5

This application is not configured for nearby connectivity on the current platform.

iOS only, and a build-time fault rather than something to handle at run time. Two causes, both reported with the detail written to the log:

ServiceId is not valid. Starting with an invalid service identifier raises an exception inside Multipeer Connectivity that terminates the process and cannot be caught. Options validation normally rejects one during application startup; this covers callers who construct the session outside that pipeline.

The application's Info.plist is incomplete: NSLocalNetworkUsageDescription is missing, or NSBonjourServices names the configured service identifier under no transport at all. Neither can be validated at startup, because both live in the application's bundle rather than in NearbyOptions. Without them advertising and discovery start and never find a peer, which is the silent failure this value exists to make visible. Declaring only one of _<ServiceId>._tcp and _<ServiceId>._udp is reported as a warning in the log rather than here, because Apple does not document whether both are required.

MissingPermissions = 3

One or more required permissions have not been granted.

Request them with NearbyPermission, which resolves the right set for the current platform and OS version. This reports only that a permission is missing. It does not distinguish one the user has not been asked for from one they permanently denied.

PlayServicesUnavailable = 4

Google Play services is missing, disabled, or requires an update.

Android only, and a hard failure there: Nearby Connections is provided by Google Play services.

Unsupported = 6

The current platform does not support nearby connectivity.

Reported on every target other than Android and iOS. Unlike every other value, this cannot be resolved at run time.

WifiDisabled = 1

Wi-Fi is off. Connections still work over Bluetooth alone, at substantially lower throughput.

A warning rather than a blocker, and the lowest-severity value for that reason: the start methods proceed on it, because blocking it would block a working setup. Android only. Multipeer Connectivity gives no equivalent signal, and being Wi-Fi only on modern systems it has no slower fallback to report.

Examples

var message = await nearby.CheckAvailabilityAsync(cancellationToken) switch
{
    NearbyAvailability.Available => null,
    NearbyAvailability.BluetoothDisabled => "Turn on Bluetooth.",
    NearbyAvailability.WifiDisabled => "Turn on Wi-Fi.",
    NearbyAvailability.MissingPermissions => "Grant nearby devices permission.",
    _ => "Nearby connectivity is unavailable on this device.",
};

Remarks

Ordered rather than a bit field, and shaped like NetworkAccess: a device can fail more than one condition at once, but a user can be told only one thing to fix first. Compare against Available to test readiness.

Which values a platform can report differs. The documentation on each says so. Render guidance from the value actually returned rather than assuming which ones a platform produces.

See Also