BLE-App-Entwicklung mit React NativeiOS und Android, eine Codebase
Die meisten App-Entwickler kommen bei Bluetooth Low Energy nicht weit. Wir bauen Apps, die wirklich mit Ihrer Hardware reden: Provisioning, Live-Daten, Offline-first.
- Stabile BLE-Verbindungen
- Provisioning ohne Internet
- Live-Sensordaten in Echtzeit
Apps, die wirklich mit Hardware reden
Eine App, die ein REST-Backend abfragt, kann fast jedes Team bauen. Eine App, die eine stabile Bluetooth-Low-Energy-Verbindung zu einem physischen Gerät aufbaut, GATT-Services ausliest, mit Verbindungsabbrüchen umgeht und im Hintergrund weiterläuft, können die wenigsten. Genau hier fängt unsere Stärke an.
Wir bauen seit Jahren Apps, die direkt mit Sensoren, Gateways und Embedded-Geräten kommunizieren, statt nur Daten aus der Cloud anzuzeigen. Das ist echtes Engineering an der Schnittstelle zwischen Hardware und Software, nicht nur eine schöne Oberfläche.
Was BLE in der Praxis schwer macht
Und wie wir es lösen.
Instabile Verbindungen
BLE funkt im überfüllten 2,4-GHz-Band. Reichweite, Störungen und Supervision-Timeouts führen zu Abbrüchen. Wir kapseln die Verbindung in einer State-Machine mit definierten Zuständen und kontrolliertem Retry statt naiver Promise-Ketten.
Reconnect-Handling
Nach einem Abbruch reicht kein simples connect(). Services und Characteristics müssen neu entdeckt, Subscriptions neu aufgesetzt und der App-State sauber resynchronisiert werden. Wir behandeln Reconnect als Normalfall, nicht als Ausnahme.
Background-Scanning
Im Hintergrund gelten andere Regeln: iOS scannt nur mit explizitem Service-UUID-Filter, drosselt Intervalle und verlangt die passenden Background-Modes. Wir konfigurieren das so, dass die App auch im Hintergrund zuverlässig auf Geräte reagiert.
iOS vs. Android
CoreBluetooth und der Android-BLE-Stack verhalten sich unterschiedlich: MTU-Aushandlung, Permission-Modelle (ab Android 12 BLUETOOTH_SCAN/CONNECT), Caching von GATT-Tabellen und Bonding. Wir kennen die Fallstricke beider Plattformen.
GATT-Services & Characteristics
Daten liegen in Characteristics innerhalb von GATT-Services, oft als rohe Bytes. Wir lesen das Geräteprotokoll korrekt aus, parsen Little-Endian-Werte, Flags und Skalierungen und mappen sie auf saubere Datenmodelle.
Pairing & Bonding
Pairing-Flows reichen von Just Works bis Passkey-Eingabe mit verschlüsselter Bindung. Wir bauen den Flow so, dass Nutzer im Feld ohne Support-Anruf durchkommen und die Bindung auch nach App-Neustart hält.
Provisioning ohne Internet
Der klassische Fall im Feld: Ein Techniker steht vor einem nagelneuen Gerät, kein WLAN, kein Mobilfunk, kein Cloud-Onboarding. Die App übernimmt die Erstkonfiguration komplett über BLE.
QR scannen
Der Techniker scannt den QR-Code am Gerät. Die App kennt sofort Typ, Seriennummer und die erwartete BLE-Kennung.
BLE verbinden
Die App verbindet sich direkt per BLE mit dem Gerät, ohne Umweg über eine Cloud oder ein lokales Netzwerk.
Parameter setzen
Die Konfiguration wird in die Characteristics geschrieben: Messintervalle, Schwellwerte, Netzwerk-Keys, Kalibrierung. Alles lokal, alles offline.
Im Backend registrieren
Sobald wieder Verbindung besteht, meldet die App das Gerät am Backend an. Die Registrierung wird offline in einer Queue gehalten und automatisch synchronisiert.
Viele BLE-konfigurierbare Geräte, etwa die LoRaWAN-Sensoren von Milesight, lassen sich genau so in Betrieb nehmen.
Live-Daten via BLE
Kein Pull-to-Refresh, keine 30-Sekunden-Polls. Über BLE-Notifications abonniert die App Characteristics und bekommt neue Werte gepusht, sobald das Gerät sie sendet. Vibration, Temperatur, Druck oder Füllstand erscheinen praktisch in Echtzeit auf dem Screen, mit Diagrammen, die live mitlaufen.
Echtzeit-Notifications
Die App abonniert Characteristics und bekommt neue Werte gepusht, statt zu pollen.
Live-Diagramme
Eingehende Bytes landen in einem Ringpuffer und laufen als flüssiges Diagramm mit.
Schwellwert-Alarme
Überschreitet ein Wert eine Grenze, alarmiert die App sofort, auch lokal ohne Backend.
Der Stack
Bewährte Bausteine statt Experiment.
React Native
Eine Codebase für iOS und Android, mit Zugriff auf native Module dort, wo es nötig ist.
react-native-ble-plx
Die ausgereifte BLE-Bibliothek: Scannen, Verbinden, GATT, Notifications, plattformübergreifend.
WatermelonDB
Offline-first-Datenbank für tausende Datensätze, mit Sync-Layer zum Backend, sobald wieder Netz da ist.
So sieht ein minimaler Scan-, Verbindungs- und Lese-Flow mit react-native-ble-plx aus:
import { BleManager } from "react-native-ble-plx";
import { Buffer } from "buffer";
const manager = new BleManager();
const SERVICE_UUID = "0000181a-0000-1000-8000-00805f9b34fb";
const CHAR_UUID = "00002a6e-0000-1000-8000-00805f9b34fb";
manager.startDeviceScan(null, null, (error, device) => {
if (error) {
console.warn(error);
return;
}
if (device?.name === "MerkaioSensor") {
manager.stopDeviceScan();
device
.connect()
.then((d) => d.discoverAllServicesAndCharacteristics())
.then(async (d) => {
const char = await d.readCharacteristicForService(
SERVICE_UUID,
CHAR_UUID,
);
// characteristic.value is base64-encoded
const bytes = Buffer.from(char.value ?? "", "base64");
const tempC = bytes.readInt16LE(0) / 100;
console.log("Temperature:", tempC, "C");
})
.catch((e) => console.warn(e));
}
});iOS und Android aus einer Codebase
Sie brauchen keine zwei nativen Teams. React Native liefert eine gemeinsame Codebase, während die BLE-Operationen über native Module mit voller Performance laufen. Wo eine Plattform Spezialverhalten braucht, lösen wir das gezielt, ohne die ganze App zu spalten.
Eine Codebase
Eine App, zwei Stores, identisches Verhalten. Ein Budget statt zwei nativen Teams.
Native BLE-Performance
Die BLE-Operationen laufen über native Module mit voller CoreBluetooth- und Android-BLE-Performance.
Beide Stores
Auslieferung in App Store und Play Store, inklusive Zertifikate, Profile und Review.
Typische Projekte
Smart-Product-App
Die Companion-App zu Ihrem Hardware-Produkt: koppeln, steuern, Firmware-Status, Einstellungen, alles per BLE. Im Store unter Ihrer Marke.
Installer-App
Für Techniker im Feld: Geräte per BLE in Betrieb nehmen, konfigurieren und dokumentieren, auch ohne Internet vor Ort.
Wartungs-App
Vor Ort Live-Sensordaten auslesen, Grenzwerte prüfen, Inspektionen erfassen und offline protokollieren, später synchronisieren.
Die Apple-Hürde bei Hardware-Apps
Apple lehnt Hardware-Apps regelmäßig ab, weil der Reviewer das physische Gerät nicht hat und die Funktion nicht testen kann. Wir kennen den Weg durch das App Review: aussagekräftiges Demo-Video, präzise Review-Notes, ein Demo-Modus oder Test-Credentials und eine saubere Begründung der genutzten Bluetooth- und Background-Modes. So kommen IoT-Apps durch die Freigabe, statt in Endlosschleifen aus Rückfragen zu landen. Praktisches Wissen statt Trial-and-Error.
Wann nativ die bessere Wahl ist
Ehrlich gesagt: Nicht jede App gehört in React Native. Wenn Sie sehr hochfrequente BLE-Streams mit minimaler Latenz brauchen, tief in OS-Spezifika wie CoreBluetooth State Restoration oder spezielle Hintergrund-Szenarien eingreifen oder ohnehin schon ein natives Team haben, ist natives Swift oder Kotlin oft die sauberere Lösung. Wir sagen Ihnen das in der Discovery, bevor Sie Geld ausgeben, nicht danach. In den allermeisten IoT-App-Projekten überwiegen die Vorteile einer gemeinsamen Codebase aber deutlich.
Lassen Sie uns Ihre Hardware-App bauen
Bringen Sie Ihre Idee mit, wir bringen die BLE-Erfahrung. In einer Discovery klären wir Hardware, Protokoll und Scope, und Sie bekommen ein belastbares Konzept.
Häufige Fragen zu BLE-Apps
Sprechen wir über Ihre Infrastruktur. Digital und vor Ort.
Ob IoT-Plattformentwicklung, Hardwareauswahl, Managed Hosting für ChirpStack, ThingsBoard, Grafana oder NetBird VPN, oder Migration von einem Self-Hosted-Setup - wir finden die passende Lösung für Ihren Anwendungsfall. Buchen Sie ein kostenloses 30-Minuten-Gespräch, unverbindlich.
Ihr Ansprechpartner
Timo Wevelsiep
Gründer, merkaio
15 Minuten, unverbindlich, direkt mit Timo.