What it does
Multipeer Connectivity is an Apple framework that lets an app discover services offered by nearby devices and communicate with them using messages, streams and resources such as files. Apple introduced it in iOS 7, and its documentation lists iOS, iPadOS, Mac Catalyst, macOS, tvOS and visionOS. There is no Android version. What is MultipeerConnectivity? has the glossary definition.
The app does not pick the radio. On iOS the framework uses infrastructure Wi-Fi networks, peer-to-peer Wi-Fi and Bluetooth personal area networks underneath; on macOS and tvOS it uses infrastructure Wi-Fi, peer-to-peer Wi-Fi and Ethernet. Because it uses the local network, an app must supply a NSLocalNetworkUsageDescription string and declare the Bonjour services it browses under NSBonjourServices.
Discovery, then a session
Apple describes two phases.
Discovery. One app runs an advertiser (MCNearbyServiceAdvertiser, or MCAdvertiserAssistant with a standard accept screen) to say it is willing to join sessions of a named service type. Another runs a browser (MCNearbyServiceBrowser, or MCBrowserViewController with a standard picker) to find it. Each app instance on a device is identified to its neighbours by an MCPeerID. During this phase apps know little about each other: only the small discoveryInfo dictionary a peer advertises and any context sent with an invitation.
Session. The browsing app invites the chosen peers into an MCSession. The other app can accept or decline, and can ask its user first. Once a peer accepts, the browser connects to the advertiser and the two can communicate directly; the framework reports peers joining and leaving through delegate callbacks.
A session supports up to 8 peers, including the local one. Inside it, an app has three ways to send:
- Data with
send(_:toPeers:with:), in reliable mode, where delivery is guaranteed, or unreliable mode for data that is useless if it arrives late. - Resources with
sendResource(at:withName:toPeer:withCompletionHandler:), which sends a file or URL and returns a progress object the app can use to cancel. - Streams with
startStream(withName:toPeer:), a byte stream the app manages itself.
Security is a session setting: MCEncryptionPreference is none, optional or required. TN3213 says the required model needs the app to supply a digital identity, and that optional security adds complexity without any actual security benefit.
The limits that shape apps
- Apple only. An Android phone cannot join a session. Multipeer Connectivity alternatives that work with Android covers what to use instead.
- Foreground only. If the app moves to the background, the framework stops advertising and browsing and disconnects open sessions. When the app returns, advertising and browsing resume, but the app must set up the closed sessions again. Bluetooth has its own background rules on iOS, covered in Can a BLE app run in the background on iOS?.
- Small groups. The 8-peer limit applies per session, and members talk to each other directly. A larger group needs a different design, such as a mesh that relays through other devices.
- Not Wi-Fi Direct. TN3213 separates Apple peer-to-peer Wi-Fi from industry-standard peer-to-peer Wi-Fi, which Apple supports through Wi-Fi Aware. So when a framework or library says it uses peer-to-peer Wi-Fi on an iPhone, that does not mean Android’s Wi-Fi Direct.
Deprecated: what replaces it
Apple’s framework page now says Multipeer Connectivity is deprecated and that code using it should move to the Network framework. TN3213 says Xcode 27 deprecates the entire framework, and the API reference marks classes such as MCSession deprecated in iOS 27 and the aligned releases, with the message “Use Network Framework instead”. The technote’s advice to developers with Multipeer code is to plan the migration.
TN3213 maps each part of the framework to a Network framework equivalent, using the API introduced in iOS 26 (NetworkConnection, NetworkListener and NetworkBrowser):
| Multipeer Connectivity | Approach in TN3213 |
|---|---|
| Advertiser and browser for a service type | A listener that advertises a Bonjour service, and a browser for that service type |
| Standard picker and invitation screens | No direct equivalent; DeviceDiscoveryUI to pair for Wi-Fi Aware, or the app’s own interface |
| Metadata a peer advertises during discovery | Bonjour TXT records |
| Reliable send mode | A reliable stream, with QUIC as the suggested default, or TCP or WebSocket |
| Unreliable send mode | QUIC datagrams or a UDP flow |
| Required encryption | TLS with a local identity, mutual authentication and a custom check of the peer’s certificate |
Two details in the technote matter for offline apps. First, the Network framework does not enable peer-to-peer Wi-Fi by default; an app opts in, and Apple warns that doing so can reduce network performance for that app and others on the device, suggesting Wi-Fi Aware instead. Second, Wi-Fi Aware with QUIC is not supported before iOS 27. Wi-Fi Aware itself needs iOS 26 or later, and pairing through Apple’s interfaces, before two devices can connect.
For an app that runs only on Apple devices, the Network framework is now the documented path. For an app whose iPhone and Android users must reach each other, neither Multipeer Connectivity nor its replacement is enough on its own, and Can an iPhone and an Android phone connect directly without internet? goes through the links the two platforms share.