React Native Standortdienste und Geolocation richtig nutzen

1. Warum Standortdienste besondere Sorgfalt brauchen

Geolocation in einer React-Native-App klingt zunächst simpel: einmal getCurrentPosition aufrufen, Koordinaten anzeigen, fertig. In der Praxis stehen Standortdienste aber im Spannungsfeld dreier konkurrierender Anforderungen: Genauigkeit, Akkuverbrauch und Nutzer-Privatsphäre. Ein GPS-Fix mit hoher Genauigkeit verbraucht spürbar mehr Strom als eine netzwerkbasierte Positionsbestimmung, und jede kontinuierliche Standortabfrage im Hintergrund summiert sich über den Tag zu messbarem Akkuverlust.

Wer Geolocation ohne Konzept integriert, merkt das meist erst spät: Nutzer beschweren sich über leeren Akku, oder die App fällt beim App-Store-Review durch, weil die Permission-Begründung fehlt oder Hintergrund-Tracking ohne erkennbaren Zweck angefordert wird. Sowohl Apple als auch Google prüfen inzwischen aktiv, ob eine App Standortzugriff tatsächlich für ihren Kernzweck benötigt, und lehnen Einreichungen ab, bei denen der Zusammenhang nicht klar ersichtlich ist.

Die folgenden Abschnitte zeigen, wie Standortdienste in React Native sauber implementiert werden: von der Wahl der richtigen Bibliothek über korrekte Permission-Anfragen bis zu Background Tracking und Geofencing. Der rote Faden ist immer derselbe: so viel Genauigkeit wie für den jeweiligen Anwendungsfall nötig, nicht mehr.

2. APIs im Überblick: expo-location vs. react-native-geolocation-service

Für Geolocation in React Native gibt es im Wesentlichen zwei aktiv gepflegte Wege. Im Expo-Managed-Workflow ist expo-location die naheliegende Wahl: Es kapselt sowohl die einmalige Positionsbestimmung als auch kontinuierliches Tracking und Geofencing hinter einer einheitlichen, gut dokumentierten API, ohne dass native Module manuell verlinkt werden müssen.

Im Bare Workflow, also einem React-Native-Projekt ohne Expo-Runtime, hat sich react-native-geolocation-service als Ersatz für die inzwischen aus dem React-Native-Core entfernte Geolocation-Web-API-Polyfill etabliert. Der Community-Standard bietet feingranularere Kontrolle über native Android- und iOS-Provider und wird aktiv gegen neue Betriebssystemversionen getestet, während die alte Core-Implementierung seit Jahren keine Updates mehr erhielt.

Die Entscheidung zwischen beiden hängt vom Projekt-Setup ab, nicht vom Geschmack: Wer bereits mit Expo arbeitet, sollte bei expo-location bleiben, weil zusätzliche Bare-Bibliotheken den Managed Workflow unnötig verkomplizieren. Wer ein bestehendes Bare-Projekt hat oder sehr spezifische native Kontrolle über GPS-Provider braucht, ist mit react-native-geolocation-service besser bedient. Eine Migration von der veralteten, Web-API-artigen navigator.geolocation auf eine der beiden Bibliotheken ist für Standortdienste in produktiven Apps praktisch immer die richtige Entscheidung.

3. Permissions korrekt anfordern

Standortdienste dürfen unter iOS und Android nur nach expliziter Nutzerzustimmung aktiv werden, und beide Plattformen verlangen dafür eine sichtbare Begründung. Unter iOS trägt man den Text für Foreground-Zugriff in NSLocationWhenInUseUsageDescription in der Info.plist ein, für Hintergrundzugriff zusätzlich NSLocationAlwaysAndWhenInUseUsageDescription. Fehlt einer dieser Einträge, stürzt die App beim Zugriffsversuch ab, statt einen Fehler zurückzugeben, ein Verhalten, das in der Entwicklung leicht übersehen wird, weil der Absturz nur beim allerersten Zugriff auftritt.

Unter Android werden ACCESS_FINE_LOCATION für präzise GPS-Positionen und ACCESS_COARSE_LOCATION für netzwerkbasierte Näherungswerte als Runtime-Permissions angefordert, also zur Laufzeit über einen Dialog, nicht allein über die Manifest-Deklaration. Seit Android 6 ist die Manifest-Deklaration nur die Voraussetzung, die eigentliche Zustimmung holt die App über PermissionsAndroid.request() oder die entsprechende Expo-API ein.

Ein Detail, das häufig übersehen wird: ACCESS_BACKGROUND_LOCATION muss seit Android 10 in einem separaten, zweiten Dialog angefordert werden und darf nicht zusammen mit den Foreground-Permissions in einer Anfrage gebündelt werden. Google lehnt Apps ab, die versuchen, beide gleichzeitig zu erhalten, weil der Nutzer die Tragweite eines dauerhaften Standortzugriffs erst verstehen soll, nachdem er den Foreground-Zugriff bereits erlebt hat. In der Praxis bedeutet das: Foreground-Permission anfordern, App tatsächlich nutzen lassen, und erst wenn ein konkreter Hintergrund-Anwendungsfall ansteht, die zweite Anfrage stellen.

// LocationTracker.js — request permission then watch position with distanceFilter
import { useEffect, useRef, useState } from 'react';
import { Platform, PermissionsAndroid } from 'react-native';
import Geolocation from 'react-native-geolocation-service';

async function requestLocationPermission() {
  if (Platform.OS === 'ios') {
    const authStatus = await Geolocation.requestAuthorization('whenInUse');
    return authStatus === 'granted';
  }

  const granted = await PermissionsAndroid.request(
    PermissionsAndroid.PERMISSIONS.ACCESS_FINE_LOCATION,
    {
      title: 'Standortzugriff erforderlich',
      message: 'Die App benoetigt deinen Standort, um Lieferungen live zu verfolgen.',
      buttonPositive: 'Erlauben',
    }
  );
  return granted === PermissionsAndroid.RESULTS.GRANTED;
}

export function useLiveLocation() {
  const [position, setPosition] = useState(null);
  const [error, setError] = useState(null);
  const watchId = useRef(null);

  useEffect(() => {
    let isMounted = true;

    requestLocationPermission().then((hasPermission) => {
      if (!hasPermission || !isMounted) return;

      watchId.current = Geolocation.watchPosition(
        (pos) => setPosition(pos.coords),
        (err) => setError(err),
        {
          accuracy: { android: 'high', ios: 'best' },
          distanceFilter: 25, // meters — throttle updates to save battery
          interval: 5000,
          fastestInterval: 2000,
        }
      );
    });

    return () => {
      isMounted = false;
      if (watchId.current !== null) {
        Geolocation.clearWatch(watchId.current);
      }
    };
  }, []);

  return { position, error };
}

4. Einmalige Positionsbestimmung mit getCurrentPosition

Für einmalige Positionsbestimmung ist getCurrentPosition() die richtige Methode, sowohl in expo-location als auch in react-native-geolocation-service. Die wichtigsten Optionen sind accuracy, timeout und maximumAge. accuracy steuert, wie genau, und damit wie stromhungrig, die Positionsbestimmung ausfällt, timeout begrenzt die Wartezeit auf einen Fix, und maximumAge legt fest, wie alt eine gecachte Position maximal sein darf, bevor ein neuer GPS-Fix erzwungen wird.

maximumAge wird in der Praxis zu selten genutzt. Viele Implementierungen erzwingen bei jedem Aufruf einen frischen GPS-Fix, obwohl eine zehn oder zwanzig Sekunden alte, bereits gecachte Position für den jeweiligen Anwendungsfall völlig ausreichen würde, etwa beim Anzeigen der ungefähren Nutzerposition auf einer Karte direkt nach App-Start. Ein sinnvoller Standardwert für maximumAge liegt meist zwischen 10000 und 30000 Millisekunden, abhängig davon, wie zeitkritisch die Position sein muss.

Der timeout-Wert sollte großzügig genug gewählt werden, um auch bei schwachem GPS-Empfang, etwa in Innenräumen oder zwischen Hochhäusern, noch einen Fix zu bekommen, aber nicht so hoch, dass die UI gefühlt einfriert. Zehn Sekunden sind ein gängiger Kompromiss. Schlägt die Anfrage fehl, sollte die UI sofort einen klaren Fehlerzustand zeigen, statt endlos zu laden, denn ein hängender Ladeindikator ist eines der häufigsten Nutzer-Ärgernisse bei Standortdiensten.

5. Kontinuierliches Tracking mit watchPosition

Sobald eine Anwendung kontinuierlich auf Positionsänderungen reagieren muss, etwa bei Live-Tracking während einer Lieferfahrt, kommt watchPosition() ins Spiel. Anders als getCurrentPosition liefert watchPosition wiederholt neue Positionen, solange die Subscription aktiv ist, und muss beim Verlassen des jeweiligen Screens explizit wieder beendet werden, sonst läuft das Tracking im Hintergrund weiter und verbraucht unnötig Akku.

Der wichtigste Hebel zur Akku-Optimierung ist distanceFilter. Er gibt an, wie viele Meter sich die Position mindestens verändert haben muss, bevor ein neues Update ausgelöst wird. Ein distanceFilter von 0 liefert jede noch so kleine Änderung, was bei einem GPS-Signal mit natürlichem Rauschen zu unnötig vielen Updates führt. Ein Wert zwischen 10 und 50 Metern reduziert die Update-Frequenz drastisch, ohne den praktischen Nutzen des Trackings zu beeinträchtigen.

Genauigkeit und Akkuverbrauch stehen bei watchPosition in direktem Zusammenhang: accuracy: 'high' erzwingt GPS und liefert die präziseste Position, kostet aber deutlich mehr Strom als eine netzwerkbasierte Schätzung über Mobilfunkzellen oder WLAN-Access-Points. Für viele Anwendungsfälle, etwa das grobe Anzeigen der Nutzerregion für standortbasierte Inhalte, reicht eine geringere Genauigkeit vollkommen aus und sollte bewusst gewählt werden, statt reflexartig immer die höchste Genauigkeit anzufordern.

6. Background Location Tracking

Background Location Tracking, also Standortdienste, die auch dann weiterlaufen, wenn die App nicht im Vordergrund ist, verlangt unter iOS die Background-Modes-Capability "Location updates" im Xcode-Projekt. Ohne diese Capability pausiert iOS jede Standortabfrage, sobald die App in den Hintergrund wechselt, unabhängig davon, welche Permissions zuvor erteilt wurden.

Android ist seit Version 10, verschärft seit Version 12, deutlich restriktiver: Kontinuierliches Background-Tracking verlangt einen Foreground Service mit einer permanent sichtbaren Notification, die dem Nutzer transparent macht, dass die App aktiv seinen Standort verfolgt. Ein Versuch, Geolocation im Hintergrund ohne Foreground Service laufen zu lassen, wird vom System nach kurzer Zeit beendet, unabhängig von erteilten Permissions.

Für die praktische Umsetzung bieten sich zwei Wege an: react-native-background-geolocation als vollständige, kommerzielle Lösung mit eingebautem Foreground-Service-Management, Batching und Offline-Queueing, oder die Kombination aus expo-task-manager und expo-location für einfachere Anwendungsfälle im Expo-Ökosystem. Letztere registriert eine Task, die auch bei geschlossener App vom Betriebssystem periodisch aufgeweckt wird, während erstere für durchgehendes, hochfrequentes Tracking wie bei Fitness- oder Lieferdiensten ausgelegt ist.

7. Geofencing

Geofencing ergänzt Standortdienste um die Fähigkeit, auf das Betreten oder Verlassen einer definierten geografischen Region zu reagieren, ohne dass die App dafür kontinuierlich die exakte Position auswerten muss. Sowohl iOS als auch Android bieten dafür native Region-Monitoring-APIs, die Enter- und Exit-Events auslösen, die das Betriebssystem selbst verarbeitet und nur bei tatsächlichem Grenzübertritt an die App weiterreicht.

Diese systemseitige Verarbeitung ist deutlich effizienter als eigenes, periodisches Abfragen der Position und Vergleichen mit gespeicherten Koordinaten, weil das Betriebssystem die Überwachung mit angepasster Genauigkeit und minimalem Energieverbrauch übernimmt. Typische Anwendungsfälle sind der automatische Check-in beim Betreten eines Ladengeschäfts oder geofenced Benachrichtigungen, etwa eine Erinnerung, sobald der Nutzer in der Nähe einer bestimmten Filiale ist.

Ein praktisches Limit, das viele Entwickler überrascht: iOS überwacht pro App maximal rund 20 Regionen gleichzeitig. Wer mehr Standorte abdecken muss, etwa alle Filialen einer Kette bundesweit, sollte serverseitig anhand der ungefähren Nutzerposition immer nur die nächstgelegenen 20 Regionen aktiv registrieren und die Liste bei größeren Positionswechseln dynamisch aktualisieren, statt zu versuchen, alle Standorte gleichzeitig zu überwachen.

{
  "expo": {
    "name": "mironsoft-demo",
    "plugins": [
      [
        "expo-location",
        {
          "locationAlwaysAndWhenInUsePermission": "Diese App nutzt deinen Standort, um Lieferungen live zu verfolgen.",
          "locationWhenInUsePermission": "Diese App nutzt deinen Standort, um dir Inhalte in deiner Naehe zu zeigen.",
          "locationAlwaysPermission": "Diese App verfolgt Lieferungen auch im Hintergrund.",
          "isAndroidBackgroundLocationEnabled": true,
          "isIosBackgroundLocationEnabled": true
        }
      ]
    ],
    "ios": {
      "infoPlist": {
        "UIBackgroundModes": ["location"]
      }
    },
    "android": {
      "permissions": [
        "ACCESS_FINE_LOCATION",
        "ACCESS_COARSE_LOCATION",
        "ACCESS_BACKGROUND_LOCATION"
      ]
    }
  }
}

8. Genauigkeit, Fehlerbehandlung und Testing

GPS-Signale sind in Innenräumen, in Tiefgaragen oder zwischen hohen Gebäuden systembedingt ungenau oder gar nicht verfügbar, weil das Signal von Satelliten durch Wände und Reflexionen gestört wird. Eine robuste Implementierung von Standortdiensten zeigt in solchen Fällen einen klaren Zustand an, etwa "Standort konnte nicht ermittelt werden", statt eine veraltete oder offensichtlich falsche Position stillschweigend zu übernehmen.

Für das Testen auf Android lohnt sich ein Blick auf die Mock-Location-Erkennung in den Entwickleroptionen: Apps mit sicherheitskritischen Standort-Anwendungsfällen sollten explizit prüfen, ob eine Position von einer Mock-Location-App stammt, und diese gegebenenfalls ablehnen, um Manipulation zu verhindern. Für reines Entwicklungs-Testing lässt sich die Position im Android-Emulator dagegen bequem über die Extended Controls simulieren, inklusive Abspielen aufgezeichneter GPS-Routen.

Unter Xcode simuliert man Standorte über die Location-Simulation im Scheme, entweder mit einer festen Koordinate oder einer vordefinierten Route wie einer Autofahrt durch eine Stadt. Das erlaubt es, watchPosition-basierte Features zu testen, ohne das Gerät tatsächlich zu bewegen. Timeout- und Permission-Denied-Fehler sollten in der UI immer unterschiedlich behandelt werden: Ein Timeout rechtfertigt einen Retry-Button, eine verweigerte Permission dagegen einen Hinweis mit direktem Link zu den Systemeinstellungen.

# Install the two most common React Native geolocation libraries
npm install react-native-geolocation-service
npx expo install expo-location

# iOS Simulator — set a fixed location
xcrun simctl location booted set 52.520008,13.404954

# iOS Simulator — play back a simulated route (walk/run/drive)
xcrun simctl location booted run --speed 20 route-berlin.gpx

# Android Emulator — set location via adb (requires emulator console access)
adb emu geo fix 13.404954 52.520008

# Android Emulator — connect to the console directly for scripted routes
telnet localhost 5554
# then inside the telnet session:
# geo fix 13.404954 52.520008

// LocationManager.swift — minimal background location updates
import CoreLocation

final class LocationManager: NSObject, CLLocationManagerDelegate {
    private let manager = CLLocationManager()

    override init() {
        super.init()
        manager.delegate = self
        manager.desiredAccuracy = kCLLocationAccuracyHundredMeters
        manager.allowsBackgroundLocationUpdates = true
        manager.pausesLocationUpdatesAutomatically = false
    }

    func start() {
        manager.requestAlwaysAuthorization()
        manager.startUpdatingLocation()
    }

    func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) {
        guard let location = locations.last else { return }
        // Forward the coordinate to the React Native bridge event emitter
        print("Background update: \(location.coordinate.latitude), \(location.coordinate.longitude)")
    }

    func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) {
        print("Location error: \(error.localizedDescription)")
    }
}

// LocationModule.kt — minimal FusedLocationProviderClient usage
import com.google.android.gms.location.*

class LocationModule(private val context: Context) {
    private val client = LocationServices.getFusedLocationProviderClient(context)

    private val request = LocationRequest.Builder(
        Priority.PRIORITY_HIGH_ACCURACY, 5000L
    ).setMinUpdateDistanceMeters(25f).build()

    private val callback = object : LocationCallback() {
        override fun onLocationResult(result: LocationResult) {
            val location = result.lastLocation ?: return
            // Forward coordinates to the React Native bridge event emitter
            println("Update: ${location.latitude}, ${location.longitude}")
        }
    }

    fun start() {
        client.requestLocationUpdates(request, callback, Looper.getMainLooper())
    }

    fun stop() {
        client.removeLocationUpdates(callback)
    }
}

9. Geolocation-Ansätze im Vergleich

Die Wahl zwischen einmaliger Positionsbestimmung, kontinuierlichem Tracking und echtem Background Geolocation ist keine Stilfrage, sondern hängt direkt vom Anwendungsfall ab. Die folgende Übersicht vergleicht die drei gängigsten Ansätze für Standortdienste in React Native.

In der Praxis empfiehlt sich, mit dem einfachsten passenden Ansatz zu starten: einmalige Positionsbestimmung, solange sie ausreicht, watchPosition nur während der Nutzer aktiv mit der App interagiert, und echtes Background Geolocation ausschließlich dann, wenn der Kernzweck der App das zwingend erfordert. Diese Reihenfolge hält sowohl Akkuverbrauch als auch Implementierungsaufwand für Standortdienste im Rahmen.

10. Zusammenfassung

Standortdienste und Geolocation in React Native lösen sich nicht mit einem einzelnen API-Aufruf, sondern verlangen eine bewusste Entscheidung pro Anwendungsfall. expo-location passt zum Managed Workflow, react-native-geolocation-service zum Bare Workflow. Foreground- und Background-Permissions müssen getrennt und zum richtigen Zeitpunkt angefordert werden, sowohl unter iOS über die Info.plist-Einträge als auch unter Android über die zweistufigen Runtime-Dialoge.

getCurrentPosition mit sinnvollem maximumAge reicht für die meisten einmaligen Abfragen, watchPosition mit passendem distanceFilter für Live-Tracking während aktiver Nutzung, und echtes Background Geolocation nur, wenn der Kernzweck der App dauerhaftes Tracking zwingend erfordert, mit sichtbarem Foreground Service unter Android. Geofencing ersetzt eigenes Positions-Polling durch effiziente, systemseitige Region-Überwachung. Wer diese Bausteine passend zum eigenen Anwendungsfall kombiniert, baut Standortdienste, die zuverlässig funktionieren, ohne Akku oder Nutzervertrauen zu opfern.

11. FAQ: React Native Standortdienste und Geolocation