How does Wi-Fi Aware work?

Wi-Fi Aware is a Wi-Fi Alliance standard, also known as Neighbor Awareness Networking (NAN), for discovering and connecting to nearby devices without network infrastructure. The Alliance lists what it adds: device-to-device connections with no access point, internet connection or GPS signal; sharing in several directions at once; groups that keep working when one device moves out of range; both native and IP-based data exchange; scheduling of device-to-device communication for low latency and power efficiency; and privacy features, including a pairing identity that only paired devices can resolve and over-the-air identities that change periodically.

Where Wi-Fi Direct builds a group around one device acting as an access point, Wi-Fi Aware starts from a different question: which services are near me right now? What is Wi-Fi Aware? gives the short definition. Android’s guide gives the steps for a connection, and Apple’s covers the iPhone side.

Wi-Fi Aware devices form clusters with their neighbours, or create a new cluster if a device is the first one in the area. On Android this is handled for the whole device by a system service; apps have no control over clustering.

An app joins by calling attach(). That turns on the Wi-Fi Aware hardware, joins or forms a cluster, and creates a session with its own namespace for everything the app does next. Android’s guide warns that while any session is active the system keeps the device synchronised with the cluster, which uses resources and battery, so apps close sessions they no longer need.

Discovery uses two roles, and a device can take both at once.

• Publish. An app makes a service discoverable by name, optionally with a match filter and extra service-specific information.
• Subscribe. Another app subscribes to the same service name. When a matching publisher comes into Wi-Fi range, the subscriber’s app is told it has discovered a service and receives a handle for that peer.

The publisher is not notified when someone discovers it. It hears about the subscriber only when the subscriber sends it a message. Those messages are for light use: Android’s guide says they might not be delivered, might arrive out of order or more than once, and are limited to about 255 bytes. Apps that use them need message deduplication and should not treat the peer handle as a permanent identity.

Android has added refinements. From Android 12 (API level 31) an app is told when a discovered service is lost because it stopped or moved out of range. From Android 13 (API level 33), devices that support instant communication mode can speed up discovery and data path setup; because it uses extra power, the mode stays on for only 30 seconds after a discovery session starts.

For anything larger than a short message, the two devices set up a Wi-Fi Aware network connection without an access point. On Android the steps run like this:

1. The subscriber sends a message to the publisher it discovered.
2. The publisher opens a ServerSocket, then asks ConnectivityManager for a Wi-Fi Aware network that names its discovery session and the subscriber’s handle, and messages the subscriber back.
3. The subscriber requests the same kind of network.
4. When the network is available, the subscriber reads the publisher’s IPv6 address and port from the network’s capabilities and opens an ordinary socket to it.

From Android 12 the responder can be set to accept any peer, which speeds up setup and lets one network request serve several point-to-point links. Devices with Wi-Fi round-trip-time ranging can also limit discovery to a distance band; Android’s example only discovers a file-sharing service between 3 and 10 metres away.

Apple added a Wi-Fi Aware framework in iOS 26, iPadOS 26 and Mac Catalyst 26. Apple’s model starts with pairing: devices pair first, through AccessorySetupKit or DeviceDiscoveryUI. After that, an app can open connections to paired devices on demand, in the foreground or the background, using the Wi-Fi Aware and Network frameworks. Apple says those connections are authenticated and encrypted at the Wi-Fi layer, can run to several Wi-Fi Aware devices at once, and can run alongside a normal Wi-Fi network.

The publish and subscribe roles carry over. An app requests the com.apple.developer.wifi-aware entitlement with Publish, Subscribe or both, and declares each service in its Info.plist under WiFiAwareServices. Service names follow RFC 6763 and RFC 6335 rules, run to at most 15 characters, and end in _tcp or _udp. Apple’s sample app pairs two devices, then has one advertise and the other discover and connect.

Apple lists iPhone 12 and later, and several iPad models, as supporting the framework, and frames it around connecting to Wi-Fi Aware certified accessories. Its technote TN3213 adds that Wi-Fi Aware with QUIC is not supported before iOS 27. Apple does not list which other makers’ phones will pair, so treat an iPhone-to-Android Wi-Fi Aware link as something to test on the exact devices; Can an iPhone and an Android phone connect directly without internet? covers the alternatives.

• Hardware. Android supports Wi-Fi Aware from Android 8.0 (API level 26), but only on devices that have the feature, so apps check for it first.
• Availability changes. It can be switched off when the user disables Wi-Fi or Location, and some devices cannot run it while Wi-Fi Direct, SoftAP or tethering is in use. When availability changes, Android’s guide tells apps to discard their sessions and check the current state again.
• Permissions. Apps that target Android 13 and higher declare NEARBY_WIFI_DEVICES.
• Range. Android’s guide describes discovery happening when a subscriber comes into the publisher’s Wi-Fi range. Reaching devices further away is up to the application, for example by relaying messages through other devices.