r/iOSProgramming • u/unpluggedcord • 3d ago

Article Connecting two iOS simulators over BLE (or connecting a simulator to a real BLE device)

https://kylebrowning.com/posts/ble-between-two-simulators/
7 Upvotes

77% Upvoted

4 comments sorted by

3

u/ThatGuy739 3d ago

Neat. Two things I'd still test on hardware after adopting this: MTU and the denied path.

Real BLE negotiates an ATT MTU, and maximumWriteValueLengthForType: is the ceiling you actually get. A loopback TCP link has no such ceiling, so a write that sails through the shim can truncate on a device.

And CBManagerStateUnauthorized only really shows up when someone denies the permission prompt. If the shim never produces that state, the denied branch is the one you ship untested.

1

u/unpluggedcord 2d ago edited 2d ago

The shim doesn’t let oversize writes sail through, the virtual radio enforces the real ATT ceilings (512 for .withResponse, 182 for .withoutResponse) and drops or clips anything over, exactly as CoreBluetooth does, so the truncation behavior is tested.

What it doesn’t emulate is MTU negotiation, a real device may negotiate below 185, which is why the docs tell you to ask maximumWriteValueLength(for:) rather than assume, and use --passthrough for a device’s real ceiling.

0

u/Spare_Lychee_8755 1d ago

Nice writeup, the loopback shim is a clever way to get past "one simulator, no radio." The pattern generalizes badly in one direction though: anything where the simulator fakes the sensor rather than the transport still lies to you. CoreLocation is the worst offender for me, since a GPX route in Xcode moves CLLocation but never produces real CLHeading or CoreMotion behavior, so compass and geofence logic passes in the sim and falls over on a phone in a parking lot. I ended up doing that part on a real device over USB with Waypoint instead of trusting simulator routes. https://waypointapp.dev

1

u/unpluggedcord 1d ago

Why is everyone of your comments an AI written slop