Two phones, no Wi-Fi: the local multiplayer case every tutorial leaves out

The trade on offer here is substitution, not subtraction. The post's case against a backend lists four costs a server adds to a two-person game or icebreaker: latency, a line item, an account system nobody wants to sign up for, and a single point of failure for a feature that is two people in the same room ^[3]. The peer-to-peer version hands four obligations back, all of them inside your client. Decode incoming data off a background queue and hop to main before touching published state, or SwiftUI drops the update without complaint ^[8]. Render `.connecting` as its own screen, because a handshake that takes a couple of seconds reads as a frozen app ^[12]. Impose ordering yourself, either by sending one serialized snapshot per update or by carrying a sequence number ^[13]. And rebuild the link when discovery works and then drops mid-session, which the author names as the part everyone forgets to build ^[14]. Four operational costs out, four correctness problems in ^[1].

The best idea in the piece is the smallest. Early versions had Host and Join buttons, and users picked the wrong one, or one app opened its browser late and missed the advertisement window entirely ^[10]. The fix is to advertise and browse on both devices from the moment the screen opens and let whichever pairing the OS completes first win ^[11]. That takes the number of setup choices a user can get wrong from one to zero ^[2], and it follows from the shape of the API rather than fighting it: both peers run both roles anyway, so there is no host to designate ^[7].

Everything else in the connection model derives from a single delegate callback. `didChange` maintains `connectedPeers`, and the author's rule is to derive all connection state from that array rather than keeping a separate flag that can disagree with it ^[9]. Configuration is one string, lowercase, one to 15 characters, hyphens as the only punctuation ^[5], and the template asks for required encryption on the session, so the link is not something you bolt on later ^[16].

What the post does not supply is measurement. It says Bluetooth and peer-to-peer Wi-Fi differ in range and reliability, and that an app tested on a desk with both radios strong will surprise you in a noisy room ^[14], but no ranges, no discovery times. The reconnect gap it identifies is named and left there: the listings cover session setup and the two delegate callbacks, not recovery ^[3]. Which makes the closing promise of a five-minute addition with no backend ticket ^[15] true only of the part that was already easy.