'm building a peer-to-peer mesh messaging app using MultipeerConnectivity. The app implements TTL-bounded flooding relay so messages can traverse multiple hops across devices that aren't directly connected to each other.
The core limitation I'm hitting: MPC stops browsing and advertising when the app is backgrounded, which means a node can no longer relay messages for the rest of the mesh. For the mesh to be useful in practice, nodes need to stay active as relays even when users switch to other apps.
I'm aware of the standard options:
. Background task extension (beginBackgroundTask) — only buys ~30 seconds, not a real solution . Push notifications (APNs) — requires a server, defeats the goal of a fully offline/local mesh . CoreBluetooth with state preservation/restoration — genuine background capability, but essentially a full rewrite of the transport layer, and BLE throughput (~100–250 kbps) would hurt larger payloads
Before committing to a CoreBluetooth rewrite, I want to make sure I'm not missing anything.
specifically questions are:
-
Is there any way to keep an MCNearbyServiceAdvertiser or MCNearbyServiceBrowser running in the background that I'm not aware of?
-
Does MCSession maintain existing connections long enough in the background to be useful for relay (i.e., does it survive past the background task expiry)?
-
Is Network.framework's local network discovery (NWBrowser with Bonjour) any more background-friendly than MPC's browser/advertiser?
-
• Has anyone successfully implemented a hybrid approach — CoreBluetooth for background discovery/signaling + a higher-bandwidth channel (WiFi Direct or Network.framework TCP) negotiated when foregrounded?
-
• Are there any entitlements or capabilities (e.g., AccessorySetupKit, NEAppProxyProvider, or anything in the networking extension family) that could help here that aren't commonly discussed?
The relay/routing layer, E2EE, and message dedup all sit above the transport and are transport-agnostic, so the rewrite scope is limited to the discovery and session management layer — but it's still significant.
Any experience with this pattern would be very helpful.
First up, Multipeer Connectivity has been officially deprecated in Xcode 27 beta, and I encourage you to think about how you’ll update your app to account for that reality. See Moving from Multipeer Connectivity to Network Framework.
Second, I want to talk about this:
The core limitation I'm hitting: MPC stops browsing and advertising when the app is backgrounded
This is one of those bad news, good news, bad news kinda things:
- Multipeer Connectivity was never meant to be used in the background, so the behaviour you’re seeing is not surprising.
- Our other networking APIs do work in the background just fine. So, you might think that a move to Network framework is warranted, but…
- You then run into a second problem, namely suspension. While our other networking APIs work in the background, they don’t work when the app is suspended in the background. See iOS Background Execution Limits.
So, if you want to use another networking API then your question become:
- How do I resume my app in the background based on network activity?
- Failing that, how do I keep my app running indefinitely in the background?
There aren’t general purpose ways to achieve either of those goals. All the solutions require some sort of additional constraint. For example, if you were deployed in a managed environment, you could use local push. iOS Background Execution Limits lists some of the constraints and the APIs that they open up, but it’s not comprehensive.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"