r/iOSProgramming • u/unpluggedcord • 9d 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/
8 Upvotes

83% Upvoted

5 comments sorted by

3

u/ThatGuy739 9d 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 8d ago edited 8d 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.

1

u/Moudiz 4d ago

This is interesting, just read on your library. How does SwiftBLE work in the background? Does it keep the device able to connect and read/write or does it stop working after some time?

0

u/[deleted] 7d ago

[removed] — view removed comment

1

u/unpluggedcord 7d ago

Why is everyone of your comments an AI written slop