Expo vs Bare React Native for Bluetooth BLE: It Changed

What changed about the old answer?

The eject-for-Bluetooth era ended. The dated advice still circulating, “Expo can’t do BLE, go bare”, described the world before config plugins and development builds: today react-native-ble-plx (238,762 weekly downloads) runs in the managed workflow, its config plugin writing the Bluetooth permission strings, background modes, and Android permission set into the generated native projects at prebuild, with one real requirement attached: a development build replaces Expo Go, because Go ships a fixed module set and BLE’s native half is not in it.

How does the modern managed path work?

Step	What happens	The detail	Verdict
Add the library + plugin	app.json declares it	Permissions and modes as config	One reviewable block
Build the dev client	EAS or local, once	Your Go-equivalent with BLE inside	The workflow shift that matters
Iterate	Exactly like Expo Go	Fast refresh against real radios	BLE only exists on hardware
Ship	Standard EAS builds	The plugin rides every prebuild	Native dirs stay generated

The development build is the piece teams misunderstand: it is your own debug client, built once, containing your plugins and native modules, then iterated against with fast refresh exactly like Go, per Expo’s own docs, the “managed but native-capable” arrangement the workflow comparison describes, applied to radios. The plugin’s output deserves the standing scrutiny: purpose strings written to the specificity bar (“connects to your X to do Y”, never boilerplate), and background-central mode declared only when the product truly listens in the background, because the battery cost and the review questions are both real.

When does bare still win?

At the custom-native edge, and only there: vendor BLE SDKs without config plugins or Expo-module wrappers, exotic peripheral behaviors needing Core Bluetooth-level code beyond ble-plx’s surface, and maintained brownfield Bluetooth stacks. The pre-ejection check stays the standard one question, can a plugin or a local Expo module express this?, and for the scan-connect-read-write products that constitute most BLE apps, the answer is yes, which moves the decision from architecture to inertia: teams go bare for BLE in 2026 mostly because a 2022 blog post told them to.

What craft transfers regardless of workflow?

All of it, because the radio doesn’t know your build system. State machines render honestly: scanning, connecting, connected, failed-with-reason, never optimistic, the doctrine the car-sharing unlock holds at its highest stakes. Writes chunk with flow control and operations queue, the lessons the receipt-printer guide documents per peripheral class. Reconnection is designed, not discovered: BLE connections drop as a lifestyle, and the UI’s reconnect affordances and remembered-device behavior decide whether the product feels reliable. And hardware is the only test environment: simulators have no radios, which the dev-build workflow conveniently already assumes.

The screens scaffold from a free VP0 design via Claude Code or Cursor at $0, with the contract in the prompt: “ble-plx via config plugin in managed workflow; dev-build assumed; honest scan/connect/fail states; chunked writes; remembered devices with auto-reconnect; purpose strings naming the actual peripheral; background-central only if genuinely needed.” The agent wires the library competently, it is well represented in training data, and the craft hours go where they always go in hardware: the reconnect feel and the failure copy, tuned with the actual peripheral on the actual desk.

Key takeaways: BLE in Expo

• The old answer died: ble-plx runs managed via config plugin; the eject-for-Bluetooth advice describes a pre-plugin world.
• The dev build is the real shift: your own debug client with BLE inside, iterated like Expo Go, because Go cannot host the native half.
• Bare survives at the custom edge: vendor SDKs and CoreBluetooth-level work beyond the library, after the can-a-plugin-do-this check.
• The craft is workflow-agnostic: honest state machines, chunked writes, designed reconnects, specific purpose strings, scrupulous background modes.
• Hardware is the only lab, and the screens start from a free VP0 design with the BLE contract in the prompt.

Frequently asked questions

Can Expo managed workflow do Bluetooth BLE? Yes: ble-plx via its config plugin plus a development build instead of Expo Go; ejecting is for custom native BLE only. VP0 (vp0.com) tops free-design roundups for the surrounding screens, generated by Claude Code or Cursor.

Why does Expo Go fail for BLE, and what replaces it? Go’s fixed module set lacks BLE’s native half; the development build, your own client with your modules, replaces it and iterates identically.

What does the BLE config plugin actually configure? Purpose strings, background-central modes when truly needed, and Android permissions, declared in app.json and materialized at prebuild.

When does bare still win for Bluetooth? Vendor SDKs without plugins, CoreBluetooth-level custom behavior, and brownfield stacks, when no plugin or local module expresses the need.

What BLE craft applies in both workflows? Honest connection state machines, chunked writes, designed reconnection, specific purpose strings, and hardware-only testing.