BLE: iOS foreground CoreBluetooth does not deliver third-party manufacturer data (0xFFFF) or custom 128-bit service data

[dl-alexandre]

Summary

Extensive bidirectional hardware testing (iPhone 13 + SM-T577U/T390, May 2026) shows that the direct-MX service-data carrier (custom 128-bit UUID 8F4F1201-...-1001 carrying the full MX envelope) is not delivered on iOS in foreground mode.

• iOS as emitter: The radio does not transmit recognizable manufacturer data (FFFF 4D 58) or the custom service-data payload when using non-Apple UUIDs in foreground. Only the 22-byte MB legacy beacon (FFFF 4D 42) is reliably emitted.
• iOS as observer: scanForPeripherals(withServices: nil) and explicit filters never surface the custom 128-bit service data or extended AUX manufacturer data, even when the Android sender emits it correctly.

This is a CoreBluetooth platform restriction on foreground apps using third-party manufacturer data and custom 128-bit service UUIDs, not a defect in the bridge.

Evidence bundles

• artifacts/local-ble/2026-05-18-iphone13-direct-mx-hybrid/recapture-3/ (iPhone emit)
• artifacts/local-ble/2026-05-18-iphone13-direct-mx-hybrid/recapture-4-reverse/ (Android emit)
• artifacts/local-ble/2026-05-17-sm-t577u-ipad9/hardware/android-aux-full-mx-ios-observe/
• Internal decision record: docs/ble_carrier_decision.md (2026-05-18)

Request

Please document in the mob / mob_dev BLE bridge guidance that for reliable delivery of full MX envelopes (>31 bytes) involving iOS devices, the supported production carrier is:

MB legacy beacon cue (22-byte manufacturer data) + GATT fetch (responder serving the envelope).

Direct service-data and extended-advertising AUX paths should be marked experimental / Android-only or "may work on future iOS releases".

This decision is independent of the Swift sources extension point in #6.

Cross references

• [codex] Support project iOS Swift sources #6
• [codex] Compile project iOS Swift sources mob_new#5
• MeshX docs/BLE_BRIDGE.md (section "Extended-advertising AUX delivery limitation")
• MeshX docs/ble_carrier_decision.md

[dl-alexandre]

After reviewing the official mob documentation (MOB_PLUGINS.md, guides/mobile_surface_matrix.md, and distribution/transports.md), we are adding context to this issue.

Key point from the upstream docs:

• Bluetooth Low Energy (phone-to-phone transport) is explicitly marked as ❌ "Plugin candidate" in the mobile surface matrix — not core mob functionality.
• mob has a mature plugin system (priv/mob_plugin.exs manifest) that is designed exactly for this kind of native capability. It relies on the extension points we upstreamed in [codex] Support project iOS Swift sources #6 and C++ NIF support: NxEigen cross-compile + EMLX Metal GPU on iOS #5 (:ios_swift_sources + :static_nifs).

This issue should be understood as hard iOS platform constraints that any BLE transport plugin for mob will have to respect. It is not a request to change mob core itself.

The bidirectional hardware evidence here (iPhone 13 + SM-T577U/T390) is production-validated data that should guide the design of any plugin attempting custom manufacturer data or 128-bit service data for full MX envelope delivery involving iOS.

Cross-references:

• [codex] Support project iOS Swift sources #6 + mob_new#5 (build extension points enabling such plugins)
• mob_dev#8 (related extended advertising limitation)
• mob#15 (recommended carrier strategy for a BLE plugin)
• mob_dev#9 (preserving hybrid test scaffolding useful for plugin work)