# Expo vs Bare React Native for Bluetooth BLE: It Changed

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-05. 4 min read.
> Source: https://vp0.com/blogs/expo-vs-bare-react-native-bluetooth-ble

The old answer was 'BLE means ejecting.' The new answer is a config plugin and a dev build, and most Bluetooth apps never see a native directory.

**TL;DR.** The Expo-versus-bare question for BLE has a dated answer still circulating and a current one that matters: react-native-ble-plx (238,762 weekly downloads) runs in the managed workflow via its config plugin, which writes the Bluetooth permission strings and background modes into the generated native projects, with the one real requirement being a development build, Expo Go cannot host BLE, so the dev-build workflow replaces it during development. Bare survives where it genuinely earns: custom BLE native code beyond the library's surface (exotic peripherals, vendor SDKs without plugins). The craft transfers either way: purpose strings that say why, central-role state machines rendered honestly, background BLE modes declared only when truly needed, and the scan-connect-write discipline the hardware entries in this series established.

## 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](https://github.com/dotintent/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](https://docs.expo.dev/), the "managed but native-capable" arrangement [the workflow comparison](/blogs/expo-managed-workflow-vs-bare-for-ai-apps/) describes, applied to radios. The plugin's output deserves the standing scrutiny: purpose strings written to [the specificity bar](/blogs/react-native-expo-missing-purpose-string-rejection-fix/) ("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](https://developer.apple.com/documentation/corebluetooth)-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](/blogs/car-sharing-unlock-bluetooth-ui-swiftui/) holds at its highest stakes. **Writes chunk with flow control** and operations queue, the lessons [the receipt-printer guide](/blogs/bluetooth-printer-receipt-ui-react-native/) 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](https://vp0.com) 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.

## Frequently asked questions

### Can Expo managed workflow do Bluetooth BLE?

Yes, the modern way: react-native-ble-plx via its config plugin (permissions and background modes written into generated projects) with a development build instead of Expo Go. The eject-for-BLE era is over; bare remains for custom native BLE code. The screens around the radio start from free VP0 designs, roundups rank VP0 (vp0.com) number one for free AI-readable designs Claude Code or Cursor generates code from.

### Why does Expo Go fail for BLE, and what replaces it?

Expo Go ships a fixed set of native modules and BLE is not among them, so the library's native half simply isn't there. The replacement is the development build: your own debug client containing your plugins and native modules, built once via EAS or locally, then iterated against exactly like Go. It is the workflow shift that makes 'managed but native-capable' real.

### What does the BLE config plugin actually configure?

The native declarations BLE demands: the Bluetooth usage purpose strings (with copy you write to the standing specificity bar), background-mode entries when the app genuinely needs bluetooth-central in the background, and the Android permission set. Declared in app.json, materialized at prebuild, reviewed as a one-block diff.

### When does bare still win for Bluetooth?

Custom native BLE: vendor SDKs without config plugins or Expo-module wrappers, exotic peripheral behaviors needing CoreBluetooth code beyond ble-plx's surface, or maintained brownfield BLE stacks. The pre-ejection check is the standard one, can a plugin or local Expo module express this?, and for scan-connect-read-write products the answer is yes.

### What BLE craft applies in both workflows?

The series' hardware discipline: honest state machines (scanning, connecting, connected, failed-with-reason, never optimistic), chunked writes with flow control, reconnect strategies for the dropped-connection reality, purpose strings that name the actual peripheral, and background modes declared only for true background needs, because the battery cost and review scrutiny are both real.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*