ai consumer product studios

A local streaming stack for two iPhones offline

Pair nearby iPhones with Multipeer Connectivity, then use local WebRTC for video—while designing around permissions, radio limits and reconnects.

By Katarina Milosevic·October 19, 2026·4 min read
What matters here
  1. Multipeer Connectivity can handle nearby discovery and WebRTC signaling without a cloud relay.
  2. A local-only WebRTC connection depends on reachable host candidates, not just successful peer discovery.
  3. Offline streaming still needs careful testing for permissions, radio availability, battery use and reconnects.

A two-iPhone baby monitor has a simple promise: put one phone near the crib, keep another with the caregiver, and send a live view without depending on internet access. The hard part is not opening a camera. It is finding the other phone, negotiating a connection, and keeping video usable when the network is only the room around you.

Veronata’s Tuck turns two iPhones into an AI baby monitor system and is described as working anywhere, even in airplane mode. That product description does not specify its networking implementation. The stack below is a practical pattern for teams building similar offline iPhone streaming: Multipeer Connectivity for nearby discovery and signaling, with WebRTC for the media path.

Separate discovery from video

Multipeer Connectivity is useful for finding nearby Apple devices and opening a peer session. It can carry small messages between peers, which makes it a reasonable channel for exchanging the information WebRTC needs to establish a connection. WebRTC, in turn, is built for real-time audio and video transport and gives the app controls for tracks, connection state and media statistics.

Keep those jobs distinct. Use the peer session to exchange a session description and ICE candidates. Use the WebRTC connection to carry video. Sending every video frame through a generic peer data stream may look simpler at first, but then the app must take responsibility for media framing, congestion behavior and recovery that WebRTC already addresses.

Build the connection in deliberate steps

  1. Start with device roles. Decide which phone publishes video and which one views it. Make the role visible and easy to recover if either device leaves the session. For a monitor, keep the camera phone’s task narrow: capture, publish and report its state.
  2. Discover and pair nearby phones. Advertise a service through Multipeer Connectivity and let the second phone find it. Give users a clear way to confirm the intended peer. Discovery is not proof that the video path will work; treat it as the beginning of setup, not the connection itself.
  3. Exchange WebRTC setup messages locally. Create a peer connection on each phone. Send the offer, answer and ICE candidates over the established peer session. This signaling can stay on the local link; it does not require a cloud signaling service if both devices can discover and reach each other there.
  4. Keep ICE local. For a no-relay design, do not configure STUN or TURN servers. Let WebRTC gather host candidates and verify that the selected candidate pair is local. If the phones cannot reach one another directly, the session should report that plainly rather than silently falling back to a remote route.
  5. Publish and observe video. Capture from the camera, attach the video track, and watch connection state and media statistics. Start with a conservative resolution and frame rate. Raise quality only after testing on the devices and distances the product is meant to support.

What “offline” does and does not mean

Offline iPhone streaming means the media and setup path do not depend on a working internet connection. It does not mean the phones can communicate with every radio disabled. A local connection still needs a usable transport, and iOS permissions and device settings affect whether nearby discovery can proceed. Airplane mode is not a reliable shorthand for “no internet but local networking works”: radio behavior can vary with settings and user actions.

Test the exact setup instructions on real devices. Check first launch, permission denial, a disabled radio, a locked screen and an app returning from the background. Also test with the home router disconnected. A lab test on one Wi-Fi network can hide an accidental dependency on local infrastructure or remote services.

Design for the failures that matter

Local transport avoids relay-server bandwidth and keeps the video path off a remote service. It also removes a convenient fallback. Walls, distance, interference, device heat and battery limits can reduce quality or end the connection. Reconnection should be an explicit state, not a frozen image that looks live. Show when the view was last updated, and make loss of connection unmistakable.

For a baby-monitor use case, privacy is only part of the safety case. A local-only path can reduce exposure, but it cannot guarantee continuous monitoring. Set expectations about range and placement, and avoid presenting a stale frame as current video. Measure time to first frame, dropped frames, reconnect time, battery drain and thermal behavior across long sessions.

Choose the stack for the constraint

Multipeer Connectivity plus local WebRTC is a practical combination when two nearby iPhones need discovery and real-time media without a relay. Its trade-off is operational complexity at the edges: permissions, candidate selection, app lifecycle and radio conditions all become product behavior. A cloud-assisted design can be easier to reach across networks, but adds infrastructure, cost and a different privacy boundary.

For teams exploring dual-device sync, the useful test is not whether a demo streams across a desk. It is whether both phones can establish, maintain and clearly report a local session under the conditions users will encounter. Build that test before optimizing video quality.

More from Veronata News