DEV Community: Szymon Walczak

Background Location Permissions in Capacitor — The Complete Guide

Szymon Walczak — Mon, 20 Apr 2026 16:44:05 +0000

You've integrated a background location plugin, configured the tracking, and everything works on the simulator. Then you install on a real device, tap "Start," and... nothing. No GPS. No events. The plugin silently refuses to track.

Nine times out of ten, it's a permissions issue.

Background location is one of the most heavily restricted capabilities on both iOS and Android. The OS doesn't just ask "Allow location?" — it asks multiple times, in multiple stages, with platform-specific quirks that trip up even experienced mobile developers.

This guide walks through the complete permission flow for background location in a Capacitor app using the @bglocation/capacitor plugin: what to configure, how to request permissions correctly, how to handle edge cases like denials and approximate location, and how to pass App Store and Play Store review.

Why Background Location Permissions Are Different

Foreground location is straightforward. Your app asks, the user taps "Allow," and you start receiving coordinates.

Background location is a different beast entirely. Both Apple and Google treat it as a sensitive capability because it has direct privacy implications — an app that tracks location in the background can follow a user 24/7.

As a result:

iOS separates "While Using" from "Always" authorization and auto-escalates through a two-stage system dialog
Android 10+ requires background location as a separate permission request from foreground location
Android 11+ adds a mandatory in-app rationale step before showing the system dialog
Both platforms can silently downgrade your permission if the user revokes it from Settings
Play Store requires a dedicated location permission declaration form

Get any step wrong and your tracking won't start. The plugin won't crash — it'll simply reject the start() call with a clear error.

Platform Setup

Before any runtime permission code, the native projects need the right declarations.

iOS: Info.plist

Add two usage description keys and enable background modes. In Xcode, open your app's Info.plist (or via Signing & Capabilities):

<key>NSLocationWhenInUseUsageDescription</key>
<string>We need your location to track your route.</string>

<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>Background location is needed for continuous tracking.</string>

Then enable Background Modes → Location updates:

<key>UIBackgroundModes</key>
<array>
  <string>location</string>
</array>

Tip: Write clear, specific purpose strings. "We need your location" is vague. "Background location lets us track your delivery route even when the app is minimized" is what Apple reviewers want to see.

Android: Manifest Permissions

The Capacitor plugin contributes its manifest entries automatically during npx cap sync. The required permissions are:

ACCESS_FINE_LOCATION                 <!-- GPS -->
ACCESS_COARSE_LOCATION               <!-- Wi-Fi / Cell -->
ACCESS_BACKGROUND_LOCATION           <!-- Android 10+ -->
FOREGROUND_SERVICE                   <!-- Required for foreground service -->
FOREGROUND_SERVICE_LOCATION          <!-- Android 14+ -->
POST_NOTIFICATIONS                   <!-- Android 13+ notification -->

You don't need to add these manually — the manifest merger handles it.

The Runtime Permission Flow

Here's where it gets interesting. The golden rule:

Request foreground location first. Then request background location as a separate step.

This isn't a suggestion — on Android 10+, requesting both at the same time will silently fail. iOS handles escalation automatically, but the two-step approach gives you explicit control on both platforms.

Step 1: Check Current Status

import { BackgroundLocation } from '@bglocation/capacitor';

const status = await BackgroundLocation.checkPermissions();
console.log('Foreground:', status.location);           // 'granted' | 'denied' | 'prompt'
console.log('Background:', status.backgroundLocation); // 'granted' | 'denied' | 'prompt'

The PermissionState values:

Value	Meaning
`'prompt'`	Never asked, or can ask again
`'granted'`	Permission active
`'denied'`	Explicitly denied or blocked in system Settings

Step 2: Request Foreground Permission

The plugin uses a single requestPermissions() method for both foreground and background — the permissions array controls which permission you're requesting. Passing 'location' asks for foreground (GPS access while the app is visible). Passing 'backgroundLocation' asks for background (covered in the next step).

if (status.location !== 'granted') {
  const result = await BackgroundLocation.requestPermissions({
    permissions: ['location'],  // 'location' = foreground only
  });

  if (result.location !== 'granted') {
    // User denied foreground location — show explanation, open Settings
    console.warn('Foreground location denied');
    return;
  }
}

On iOS, this triggers the standard "Allow While Using" / "Allow Once" / "Don't Allow" dialog.

On Android, this triggers the standard location permission dialog.

Step 3: Request Background Permission

Only request background location after foreground has been granted — otherwise this step will silently fail on Android:

if (status.location === 'granted' && status.backgroundLocation !== 'granted') {
  const result = await BackgroundLocation.requestPermissions({
    permissions: ['backgroundLocation'],  // 'backgroundLocation' = "Allow all the time"
  });

  if (result.backgroundLocation !== 'granted') {
    console.warn('Background location denied');
    return;
  }
}

On iOS, calling this triggers the Always authorization request. If the user already granted "While Using," iOS may show an automatic upgrade dialog asking if they want to allow "Always." This happens once — if the user declines, the state remains 'prompt' (since "While Using" is still active), but the system won't show the upgrade dialog again. The only path forward at that point is directing the user to Settings > Privacy > Location Services.

On Android 10, this shows a system dialog with "Allow all the time" as an option. On Android 11+, there's no in-app dialog — the user is directed to the system Settings screen where they must select "Allow all the time" manually. This is a deliberate Google policy decision to make background location harder to grant.

Step 4: Handle the Permission Rationale (Android 11+)

On Android 11 and above, the plugin emits an onPermissionRationale event before requesting background location. This is your chance to show a custom in-app explanation before the user gets sent to system Settings:

BackgroundLocation.addListener('onPermissionRationale', (event) => {
  // Show your custom UI here
  // event.message contains a human-readable explanation
  // event.shouldShowRationale indicates if the system recommends showing one
  showCustomRationaleDialog(event.message);
});

This event fires when foreground permission is granted but background is not yet. Use it to explain why your app needs "Allow all the time" — users are far more likely to grant it when they understand the reason.

Putting It All Together

Here's a complete permission request flow you can use in a Capacitor app:

import { BackgroundLocation } from '@bglocation/capacitor';

async function requestLocationPermissions(): Promise<boolean> {
  // Check current state
  let status = await BackgroundLocation.checkPermissions();

  // Request foreground if needed
  if (status.location !== 'granted') {
    status = await BackgroundLocation.requestPermissions({
      permissions: ['location'],
    });
  }

  if (status.location !== 'granted') {
    return false; // Can't proceed without foreground location
  }

  // Request background if needed
  if (status.backgroundLocation !== 'granted') {
    status = await BackgroundLocation.requestPermissions({
      permissions: ['backgroundLocation'],
    });
  }

  return status.backgroundLocation === 'granted';
}

Edge Case: iOS Approximate Location

Starting with iOS 14, users can grant only approximate location (a radius of a few kilometers instead of precise GPS). This is a separate toggle from the "While Using" / "Always" choice — and it can silently degrade your tracking accuracy to the point of being useless for most use cases.

The plugin detects this automatically. When you call start(), if the user has granted only approximate location, the plugin emits an onAccuracyWarning event:

BackgroundLocation.addListener('onAccuracyWarning', (event) => {
  console.log('Accuracy:', event.accuracyAuthorization); // 'full' or 'approximate'
  console.log(event.message);

  // Show UI asking user to enable precise location in Settings
});

Note: The plugin automatically requests temporary full accuracy when it detects approximate location. But the user ultimately controls this setting — you should handle the case where they decline.

Edge Case: "Don't Ask Again" (Android)

On Android, if a user denies a permission twice, the system will never show the dialog again. The state becomes permanently 'denied'. At this point, the only option is to send the user to the app's system Settings page:

import { Capacitor } from '@capacitor/core';

const status = await BackgroundLocation.checkPermissions();

if (status.location === 'denied') {
  // Permission permanently denied — direct user to Settings
  if (Capacitor.getPlatform() === 'android') {
    // Show a dialog explaining they need to enable location in Settings
    showSettingsRedirectDialog();
  }
}

What Happens If You Skip a Step?

The plugin is strict about permissions for a reason — tracking without proper authorization wastes battery and violates platform guidelines. Here's what happens:

Scenario	Result
`start()` without any location permission	Rejects with `"Location permission not granted"`
`start()` with foreground only (Android 10+)	Rejects with a message indicating background location permission is required
`start()` with approximate location (iOS)	Starts, but emits `onAccuracyWarning` — tracking works with degraded precision

No silent failures. You get clear error messages and events.

App Store & Play Store Review Tips

Getting permission-related rejections is frustrating. Here's how to avoid them:

Apple App Store

Purpose strings matter. Generic descriptions like "We need your location" will get rejected. Be specific: "Tracks your delivery route in the background so dispatchers can provide real-time ETAs to customers."
Only request "Always" if you truly need it. Apple reviewers will test your app and check whether background location is essential to your core functionality.
Include notes for reviewers. In App Store Connect → App Review Information, explain exactly when and why your app uses background location.
The blue location bar is expected. When background tracking is active, iOS shows a blue bar (or blue pill on newer iOS). This is correct behavior — don't try to suppress it.

Google Play Store

Complete the location permission declaration form in Play Console → App Content → Sensitive app permissions. Without this, your app update will be rejected.
Show an in-app disclosure before requesting background location. This is a Google policy requirement — the onPermissionRationale event is designed exactly for this.
The foreground service notification is required. The plugin handles this automatically via the notification config. Customize it with your app name and purpose.
Record a video. If your background location use isn't obvious from the UI, record a demo video showing the user flow and attach it to the declaration form.

Checklist

Before shipping your Capacitor app with background location:

[ ] iOS: NSLocationWhenInUseUsageDescription and NSLocationAlwaysAndWhenInUseUsageDescription in Info.plist with descriptive strings
[ ] iOS: Background Modes → Location updates enabled
[ ] Android: All required manifest permissions included (auto via cap sync)
[ ] Runtime: Two-step flow — foreground first, background second
[ ] Android 11+: onPermissionRationale listener with custom explanation UI
[ ] iOS 14+: onAccuracyWarning listener handling approximate location
[ ] Denial handling: Check for 'denied' state and direct user to Settings
[ ] Error handling: Handle start() rejection when permissions missing
[ ] Play Store: Location permission declaration form completed
[ ] App Store: Purpose strings reviewed, background usage explained in review notes

What's Next

Once permissions are in place, you're ready to start tracking. If you're new to the plugin, the documentation covers the full setup — from configuration to handling location events.

If your tracking works on a Pixel but dies on a Xiaomi, that's a different problem. Android OEM battery killers are the next boss fight — and the plugin has tools for that too (onBatteryWarning, checkBatteryOptimization()). But that's a story for another post.

Sending Location Data to Your Backend in React Native — Three Approaches Compared

Szymon Walczak — Mon, 13 Apr 2026 15:43:06 +0000

You've got background location tracking working in your React Native app. GPS coordinates are flowing in. Now what? Those coordinates need to reach your server — reliably, even when the user is on a flaky cellular connection, driving through a tunnel, or hasn't opened the app in hours.

This is where most location tracking setups fall apart. Not in getting the GPS fix, but in getting the data home. This article compares three approaches to sending location data from a React Native app to your backend, with real code examples using the @bglocation/react-native plugin.

The Challenge

Sending location data sounds simple — it's just an HTTP POST. But in mobile reality:

The app may be in the background when the location arrives — your JS fetch may never execute
The device may be offline — underground, in a warehouse, in a rural area
The connection may be unreliable — switching between WiFi and cellular, high latency
The OS may kill your app at any moment — any data in memory is lost
You may get hundreds of updates in a burst after re-emerging from a dead zone

A production-grade solution needs to handle all of these. Let's look at three approaches.

Approach 1: Native HTTP Posting (Recommended)

The @bglocation/react-native plugin includes a built-in native HTTP client. When you configure an http block, the native layer (Swift on iOS, Kotlin on Android) sends each location to your server immediately — bypassing JavaScript entirely.

Setup

import * as BGLocation from '@bglocation/react-native';

await BGLocation.configure({
  distanceFilter: 15,
  http: {
    url: 'https://api.example.com/locations',
    headers: {
      'Authorization': 'Bearer YOUR_TOKEN',
      'Content-Type': 'application/json',
    },
  },
});

await BGLocation.start();

That's the entire setup. Every location update now triggers a native HTTP POST to your endpoint.

What gets sent

Each POST contains a single location as JSON:

{
  "latitude": 52.2297,
  "longitude": 21.0122,
  "accuracy": 8.5,
  "altitude": 115.2,
  "altitudeAccuracy": 3.0,
  "speed": 1.4,
  "heading": 185.3,
  "timestamp": 1712678400000,
  "isHeartbeat": false
}

Monitoring delivery

Listen to onHttp events for delivery status:

BGLocation.addListener('onHttp', (event) => {
  if (event.success) {
    console.log(`✓ Delivered (${event.statusCode})`);
  } else {
    console.log(`✗ Failed: ${event.error ?? `HTTP ${event.statusCode}`}`);
    console.log(`  Buffered: ${event.bufferedCount} locations waiting`);
  }
});

Offline buffer

This is where native HTTP really shines. When the POST fails (no network, server error, timeout), the location is automatically stored in a native persistent buffer. When connectivity returns, buffered locations are replayed in order — oldest first — without any JS code running.

Configure the buffer size:

await BGLocation.configure({
  http: {
    url: 'https://api.example.com/locations',
    headers: { 'Authorization': 'Bearer YOUR_TOKEN' },
    buffer: {
      maxSize: 2000, // store up to 2000 locations offline
    },
  },
});

The default is 1,000 locations. At one update every 15 seconds, that's roughly 4 hours of offline capacity.

Why this approach wins

Advantage	Why it matters
Works in background	Native code runs even when JS bridge is suspended
Automatic retry	Failed POSTs are buffered and replayed — zero JS logic needed
Survives app kill	SQLite buffer persists on disk — data isn't lost
No JS overhead	Location → HTTP happens entirely in native code
Ordered delivery	Buffered locations are sent FIFO when connectivity returns

When to choose this

Fleet tracking — vehicles go through tunnels, rural zones, parking garages
Delivery apps — couriers move in and out of coverage constantly
Field service — technicians work in basements, warehouses, remote sites
Any app where data loss is unacceptable

Approach 2: JavaScript-Side Fetch

If you need full control over the request — custom payload format, batching, or integration with an existing API client — you can skip native HTTP and send data from JavaScript.

Setup

import * as BGLocation from '@bglocation/react-native';

// No http config — we handle sending ourselves
await BGLocation.configure({
  distanceFilter: 15,
});

BGLocation.addListener('onLocation', async (location) => {
  try {
    const response = await fetch('https://api.example.com/locations', {
      method: 'POST',
      headers: {
        'Authorization': 'Bearer YOUR_TOKEN',
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        lat: location.latitude,
        lng: location.longitude,
        speed: location.speed,
        ts: location.timestamp,
        device_id: 'device-abc-123',
        trip_id: currentTripId,
      }),
    });

    if (!response.ok) {
      console.error(`Server returned ${response.status}`);
    }
  } catch (error) {
    console.error('Network error:', error);
    // TODO: buffer locally and retry later
  }
});

await BGLocation.start();

The catch

This works fine in the foreground. But there are real problems:

Background execution — on iOS, your JS code may not run when a location arrives in the background. The native layer fires the event, but the JS bridge may be suspended. On Android with a foreground service (which bglocation uses), JS has a better chance of running — but it's not guaranteed.
No automatic retry — if fetch fails, the location is gone unless you build your own queue.
App kill = data loss — anything in JavaScript memory disappears when the OS terminates the process.

Making it more resilient

You can add a basic queue using AsyncStorage or MMKV:

import AsyncStorage from '@react-native-async-storage/async-storage';

const QUEUE_KEY = 'location_queue';

async function enqueue(location: object) {
  const queue = JSON.parse(await AsyncStorage.getItem(QUEUE_KEY) ?? '[]');
  queue.push(location);
  await AsyncStorage.setItem(QUEUE_KEY, JSON.stringify(queue));
}

async function flush() {
  const queue = JSON.parse(await AsyncStorage.getItem(QUEUE_KEY) ?? '[]');
  if (queue.length === 0) return;

  try {
    const response = await fetch('https://api.example.com/locations/batch', {
      method: 'POST',
      headers: {
        'Authorization': 'Bearer YOUR_TOKEN',
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({ locations: queue }),
    });

    if (response.ok) {
      await AsyncStorage.setItem(QUEUE_KEY, '[]');
    }
  } catch {
    // Will retry on next flush
  }
}

BGLocation.addListener('onLocation', async (location) => {
  await enqueue({
    lat: location.latitude,
    lng: location.longitude,
    ts: location.timestamp,
  });
  await flush();
});

This adds resilience — but you've just built a basic version of what the native HTTP buffer does automatically. And it still doesn't work reliably in the background on iOS.

When to choose this

Foreground-only tracking — map display, ride sharing UI active on screen
Custom payload format — your API expects a specific schema, batching, or additional fields
Prototyping — validating a concept before investing in backend integration
Web development background — you're comfortable with fetch and want familiar patterns

Approach 3: Hybrid — Native HTTP + JS Enrichment

The third approach combines native HTTP for reliable delivery with JS-side processing for additional logic. This is useful when you need to:

Add client-side computed fields (trip ID, geofence context, user state)
Filter out unwanted locations before they hit your server
Send to multiple endpoints

Setup

import * as BGLocation from '@bglocation/react-native';

// Native HTTP handles the primary delivery
await BGLocation.configure({
  distanceFilter: 15,
  http: {
    url: 'https://api.example.com/locations',
    headers: {
      'Authorization': 'Bearer YOUR_TOKEN',
    },
  },
});

// JS listener for secondary processing
BGLocation.addListener('onLocation', (location) => {
  // Update local UI
  updateMapMarker(location.latitude, location.longitude);

  // Analytics or secondary API
  analytics.track('location_update', {
    speed: location.speed,
    accuracy: location.accuracy,
  });
});

// Monitor delivery for debugging
BGLocation.addListener('onHttp', (event) => {
  if (!event.success) {
    reportDeliveryFailure(event);
  }
});

await BGLocation.start();

The key insight

Native HTTP is the reliable backbone — it handles delivery, retry, and offline buffering. JavaScript is the optional enrichment layer — it processes data opportunistically when the app is active. If the JS bridge is suspended, native HTTP still delivers. You get the best of both worlds.

Custom headers for context

You can use HTTP headers to pass context that your backend extracts:

await BGLocation.configure({
  http: {
    url: 'https://api.example.com/locations',
    headers: {
      'Authorization': 'Bearer YOUR_TOKEN',
      'X-Device-Id': deviceId,
      'X-Trip-Id': currentTripId,
      'X-Driver-Id': driverId,
    },
  },
});

When trip context changes, reconfigure without stopping tracking:

// Driver starts a new trip
await BGLocation.configure({
  http: {
    url: 'https://api.example.com/locations',
    headers: {
      'Authorization': 'Bearer YOUR_TOKEN',
      'X-Trip-Id': newTripId,  // Updated
    },
  },
});
// Tracking continues — no restart needed

configure() supports partial reconfiguration. Only the fields you pass are updated; the rest are preserved.

When to choose this

Production fleet/delivery apps — reliable delivery + UI updates + analytics
Apps with trip/session context — you need to tag locations with business data
Multi-endpoint scenarios — primary data goes to your API, secondary to analytics

Comparison Table

	Native HTTP	JS Fetch	Hybrid
Background reliability	Excellent	Poor (iOS)	Excellent
Offline support	Built-in native buffer	Manual implementation	Built-in + optional JS
Survives app kill	Yes (persisted to disk)	No	Yes (native part)
Custom payload format	Fixed (Location JSON)	Full control	Headers for context
Setup complexity	Minimal	Moderate	Moderate
Batching	One-at-a-time	Custom	One-at-a-time + custom
JS bridge dependency	None	Full	Partial (enrichment only)

Backend Side: What to Expect

Regardless of approach, your backend will receive location data. Here are practical tips:

Idempotency

The same location may be POSTed more than once (retry after timeout where the server actually received it). Use the timestamp + device identifier as a natural deduplication key:

CREATE UNIQUE INDEX idx_location_dedup
ON locations (device_id, timestamp);

Burst handling

When a device comes back online after an offline period, the buffer flushes rapidly. Your endpoint should handle bursts of dozens of POSTs in quick succession. Consider:

Rate limiting per device (not globally)
Async processing with a queue (SQS, Redis, Kafka)
Batch INSERT on the database side

Timestamp vs server time

Always use the location's timestamp field — it's the time of the GPS fix, not the time it arrived at your server. A location from 30 minutes ago (buffered offline) is still valuable for route reconstruction.

Health monitoring

Use onHttp events (or server-side metrics) to track:

Delivery success rate — what percentage of locations arrive on first attempt?
Buffer depth — how many locations are commonly buffered? If it's consistently high, your endpoint may be too slow
Latency — time between timestamp and server receipt time

Getting Started

Install the plugin and start with native HTTP — it's the simplest path to reliable location delivery:

npm install @bglocation/react-native
cd ios && pod install

import * as BGLocation from '@bglocation/react-native';

await BGLocation.configure({
  distanceFilter: 'auto',
  http: {
    url: 'https://api.example.com/locations',
    headers: { 'Authorization': 'Bearer YOUR_TOKEN' },
  },
});

await BGLocation.start();

The plugin works in trial mode without a license key — full functionality for evaluation. Test the HTTP delivery on a real device, check the onHttp events, pull the network cable (toggle airplane mode), and watch the buffer handle it.

Read the full HTTP Posting documentation for advanced configuration and the API Reference for all available options.

Questions about backend integration? Comment here or reach out at hello@bglocation.dev.

Battery-Efficient GPS Tracking in Mobile Apps — How Adaptive Distance Filter Works

Szymon Walczak — Thu, 09 Apr 2026 18:56:43 +0000

Continuous GPS tracking kills battery. A typical 1 Hz GPS session (one fix per second) burns through 10–15% of battery per hour. For an 8-hour delivery shift or a full-day hike, that's a dead phone before the day is over.

Most location plugins give you one knob to tune: the distance filter — the minimum distance in meters between location updates. Set it low (10m) and you get precise tracking but aggressive battery drain. Set it high (500m) and battery lasts, but you lose detail around turns, stops, and slow-speed movement.

What if the filter adjusted itself — tight when you're walking, loose when you're on a highway? That's what the adaptive distance filter in the bglocation plugin does. This article explains how it works, how to configure it, and what kind of battery savings you can expect in production.

The Problem with Fixed Distance Filters

A distance filter tells the OS: "don't wake me up until the device has moved at least X meters." It's the primary lever for controlling the trade-off between GPS accuracy and battery life.

Here's the dilemma with a fixed value:

Too small (e.g., 10–15m)

GPS hardware stays active almost constantly
Perfect for recording a walking route on a map
Terrible for a delivery driver's 8-hour shift — battery won't survive

Too large (e.g., 300–500m)

GPS can sleep between fixes — great for battery
But you miss turns, stops at traffic lights, and any slow-speed detail
A courier walking to a building entrance? Invisible until they've moved 500m

The "just right" problem

There is no single distance filter that works well for all movement speeds. A courier's day involves highway driving, city streets, walking between buildings, and standing still at a door. Each phase needs different precision. You could change the filter manually based on some heuristic — but then you're reimplementing something the plugin should handle for you.

How The Adaptive Distance Filter Works

The bglocation plugin includes an auto mode that adjusts the distance filter dynamically based on the device's current speed. The algorithm follows a simple principle:

Maintain a consistent time interval between location updates, regardless of speed.

Instead of "give me an update every 15 meters," you're saying "give me an update roughly every 10 seconds." The plugin translates that into a distance filter based on how fast the device is moving.

What this looks like in practice

Activity	Speed	effectiveDistance	Update frequency
Standing still	0 km/h	10m (minDistance)	Heartbeats only
Walking	5 km/h	~14m	Every ~10 seconds
Jogging	10 km/h	~28m	Every ~10 seconds
City driving	40 km/h	~111m	Every ~10 seconds
Highway	120 km/h	~333m	Every ~10 seconds
Fast highway	180+ km/h	500m (maxDistance)	Every ~10 seconds

The update frequency stays roughly constant — the filter adjusts to match. At highway speed, the GPS hardware can sleep for longer stretches. At walking speed, it stays precise.

Smart speed response

The filter doesn't treat all speed changes equally:

Slowing down — the filter tightens quickly, giving you precision right when you need it (approaching a destination, parking, exiting a vehicle)
Speeding up — the filter relaxes gradually, since fast movement on predictable roads doesn't need instant fine-tuning

This means you get accurate tracking exactly when it matters most — during the last-mile approach — without wasting battery on unnecessary updates at highway speed.

Configuration

Enable auto mode by setting distanceFilter to 'auto':

import { BackgroundLocation } from '@bglocation/capacitor';
// or: import { BGLocation } from '@bglocation/react-native';

await BackgroundLocation.configure({
  distanceFilter: 'auto',
});

That's it. The defaults (targetInterval: 10, minDistance: 10, maxDistance: 500) work well for most use cases — especially mixed-mode scenarios like delivery or field service.

Customizing the thresholds

For specific use cases, override the defaults:

// High-precision fitness tracking
await BackgroundLocation.configure({
  distanceFilter: 'auto',
  autoDistanceFilter: {
    targetInterval: 8,    // more frequent updates
    minDistance: 5,        // finer detail when slow
    maxDistance: 200,      // cap for road cycling
  },
});

// Long-haul fleet tracking (battery priority)
await BackgroundLocation.configure({
  distanceFilter: 'auto',
  autoDistanceFilter: {
    targetInterval: 15,   // less frequent
    minDistance: 20,       // coarser detail when slow
    maxDistance: 1000,     // very relaxed at highway speed
  },
});

Recommended settings by use case

Use Case	targetInterval	minDistance	maxDistance	Notes
Walking / Hiking	8–12s	5–10m	100–200m	Frequent updates at low speed
Cycling	8–10s	10–15m	300m	Balanced for moderate speeds
Driving / Fleet	10–15s	10–20m	500–1000m	Larger max for highways, less drain
Delivery / Mixed	10s	10m	500m	Defaults work well here

Verifying the active mode

configure() returns a result that includes which mode is active:

const result = await BackgroundLocation.configure({
  distanceFilter: 'auto',
});

console.log(result.distanceFilterMode); // 'auto' or 'fixed'

Inspecting the current filter

Every Location object in auto mode includes the current effective distance filter:

BackgroundLocation.addListener('onLocation', (location) => {
  console.log(`Speed: ${(location.speed * 3.6).toFixed(1)} km/h`);
  console.log(`Filter: ${location.effectiveDistanceFilter}m`);
});

This field is only present when distanceFilter is set to 'auto'. In fixed mode, it's undefined.

Real-World Battery Impact

Let's compare three configurations over an 8-hour delivery shift with mixed driving and walking:

Fixed 15m filter

GPS stays highly active throughout the day
~2,000+ location points recorded
Battery impact: ~40–50% over 8 hours
Detail: excellent everywhere, but mostly wasted on highways

Fixed 200m filter

GPS sleeps frequently but misses detail
~300–500 location points recorded
Battery impact: ~10–15% over 8 hours
Detail: good for general route, poor for last-mile walking

Auto mode (defaults)

GPS adapts dynamically — tight on foot, relaxed on the road
~800–1,200 location points recorded
Battery impact: ~15–20% over 8 hours
Detail: precise when it matters (stops, walking), efficient when it doesn't (highway)

The auto mode doesn't match the battery efficiency of a 200m fixed filter — it can't, because it's doing more work at low speeds. But it's dramatically better than a 15m fixed filter while capturing meaningful detail that the 200m filter misses entirely.

Note: Battery figures are approximate, based on internal testing across multiple iOS and Android devices. Actual results vary depending on device model, OS version, signal conditions, and other apps running in the background.

Fewer points = less data

The filter doesn't just save battery. Fewer location updates mean:

Less data transferred — fewer HTTP POST requests to your server
Less storage — smaller database, faster queries
Lower bandwidth costs — relevant when tracking thousands of devices

Heartbeat: The Safety Net

There's one scenario the distance filter can't cover: the device is stationary. If a user stops moving, no location events fire regardless of the filter size.

That's where the heartbeat timer comes in. The plugin fires onHeartbeat events at a fixed interval (default: 15 seconds) even when the device hasn't moved:

await BackgroundLocation.configure({
  distanceFilter: 'auto',
  heartbeatInterval: 15, // seconds
});

BackgroundLocation.addListener('onHeartbeat', (event) => {
  console.log('Device alive at:', event.timestamp);

  if (event.location) {
    console.log(`Still at: ${event.location.latitude}, ${event.location.longitude}`);
  }
});

The combination of auto distance filter + heartbeat gives you:

Location updates that adapt to speed → battery efficiency
Regular "alive" signals even when stationary → operational confidence

For fleet management, this means you always know where a vehicle is and that it's still reporting — even if it's been parked for hours.

When to Use Auto vs Fixed

Auto mode isn't always the right choice. Here's a quick decision guide:

Use auto when:

Users switch between transport modes (walking + driving)
Battery optimization is a priority
You prefer time-based update intervals over distance-based
Fleet, delivery, or field service tracking with mixed movement

Use fixed when:

Consistent precision matters regardless of speed
The app targets a single transport mode (e.g., only running)
You need exact distance-based granularity (every 10m for a running app)
Fitness tracking where polyline accuracy on a map is critical

You can switch between modes without stopping tracking — configure() supports partial reconfiguration:

// Start with auto
await BackgroundLocation.configure({ distanceFilter: 'auto' });
await BackgroundLocation.start();

// Later, switch to fixed 10m for a precision phase
await BackgroundLocation.configure({ distanceFilter: 10 });

// Back to auto
await BackgroundLocation.configure({ distanceFilter: 'auto' });

How to Test It

Trial mode

You can test the adaptive filter without a license key. The plugin's trial mode gives you full functionality for a generous evaluation period — including auto mode — so you can verify the behavior on a real device before purchasing.

Debug mode

Enable debug mode to see the filter adapting in real time:

await BackgroundLocation.configure({
  distanceFilter: 'auto',
  debug: true,
  debugSounds: true,
});

You'll see log messages showing the current speed, effective distance filter, and when recalculations happen. With debugSounds: true, you'll hear system sounds on each location update — the frequency of the sounds directly reflects how the filter is behaving.

Test on a real device

This is important: don't test adaptive filtering on a simulator. Simulated location doesn't produce realistic speed values, and the filter won't behave like it does in the real world. Take your phone for a walk, get in a car, and watch the filter adapt.

Summary

The adaptive distance filter solves a real problem: fixed filters force you to choose between battery life and tracking precision. Auto mode eliminates that trade-off by adjusting the filter based on speed — tight where you need detail, loose where you don't.

Key takeaways:

Set distanceFilter: 'auto' to enable speed-adaptive filtering
The formula is speed × targetInterval, clamped to [minDistance, maxDistance]
Defaults (10s / 10m / 500m) work well for mixed-mode tracking
The filter responds faster when you slow down — giving precision where it matters most
Each Location includes effectiveDistanceFilter so you can see the current value
Combine with heartbeat for stationary detection
In production, expect significant battery savings compared to a tight fixed filter (results vary by device)

Want to see it in action? Install the plugin, enable debug mode, and go for a drive. The adaptive filter documentation has the full configuration reference.

# Capacitor
npm install @bglocation/capacitor
npx cap sync

# React Native
npm install @bglocation/react-native
cd ios && pod install

Try the 30-minute trial — watch the distance filter adapt in real-time as you walk, drive, and stop.

Have questions or feedback? Comment here or reach out at hello@bglocation.dev.

Setting Up Geofencing in a Mobile App

Szymon Walczak — Thu, 02 Apr 2026 12:11:59 +0000

Geofencing lets your app react when a user enters or leaves a geographic area. Think delivery notifications ("Your driver is nearby"), attendance systems, location-based reminders, or smart home automation that turns on the lights when you arrive.

Sounds simple. The reality? iOS and Android handle geofencing very differently under the hood, dwell detection is platform-specific, and your app might be suspended or killed before a transition fires.

This guide walks through implementing geofencing in a Capacitor or React Native app using the bglocation plugin — from defining your first region to handling edge cases in production.

What is Geofencing?

A geofence is a virtual boundary around a geographic point. You define a center (latitude, longitude) and a radius in meters. The OS monitors the device's position and triggers events when the user:

Enters the region
Exits the region
Dwells inside the region for a specified time

Unlike continuous GPS tracking, geofencing is power-efficient. The OS uses a combination of cell towers, Wi-Fi, and GPS to determine transitions — your app doesn't need to poll location constantly.

Prerequisites

Install the bglocation plugin in your project:

# Capacitor
npm install @bglocation/capacitor
npx cap sync

# React Native
npm install @bglocation/react-native
cd ios && pod install

Defining a Geofence

Each geofence has an identifier, coordinates, and a radius:

import { BackgroundLocation } from '@bglocation/capacitor';
// or: import { BGLocation } from '@bglocation/react-native';

// Always call configure() first — the plugin rejects geofence calls without it
await BackgroundLocation.configure({
  debug: true,
});

await BackgroundLocation.addGeofence({
  identifier: 'office',
  latitude: 52.2297,
  longitude: 21.0122,
  radius: 200,
  notifyOnEntry: true,
  notifyOnExit: true,
});

There are a few rules that we should follow:

identifier must be unique. Adding a geofence with an existing identifier replaces it.
radius is in meters. Use at least 100 meters for reliable detection — smaller radii lead to inconsistent triggers, especially on Android.
The plugin supports up to 20 simultaneous geofences (matching the iOS platform limit).

Listening for Events

BackgroundLocation.addListener('onGeofence', (event) => {
  console.log(`${event.action}: ${event.identifier}`);

  // GPS coordinates at the moment of transition
  if (event.location) {
    console.log(`${event.location.latitude}, ${event.location.longitude}`);
  }

  // Custom metadata you attached to the geofence
  if (event.extras) {
    console.log('Metadata:', event.extras);
  }
});

The GeofenceEvent includes:

Field	Type	Description
`identifier`	`string`	Which geofence was triggered
`action`	`'enter' \	'exit' \
{% raw %}`location`	`Location \	null`
`extras`	`Record<string, string>`	Your custom metadata
`timestamp`	`number`	Epoch milliseconds

Adding Multiple Geofences

If you need to register several regions at once, use the batch API:

await BackgroundLocation.addGeofences({
  geofences: [
    {
      identifier: 'office',
      latitude: 52.2297,
      longitude: 21.0122,
      radius: 200,
      notifyOnEntry: true,
      notifyOnExit: true,
    },
    {
      identifier: 'warehouse',
      latitude: 52.2450,
      longitude: 21.0350,
      radius: 300,
      notifyOnEntry: true,
      notifyOnExit: false,
      extras: { type: 'pickup-point' },
    },
    {
      identifier: 'client-site',
      latitude: 52.1900,
      longitude: 20.9800,
      radius: 150,
      notifyOnEntry: true,
      notifyOnDwell: true,
      dwellDelay: 300, // 5 minutes
      extras: { clientId: '42', priority: 'high' },
    },
  ],
});

The batch operation is atomic — if adding the batch would exceed the 20-geofence limit, all of them are rejected. No partial state.

Dwell Detection — The Tricky Part

Dwell events fire when a user stays inside a geofence for a specified duration. This is useful for attendance tracking ("employee arrived and stayed for 5+ minutes") or visit confirmation.

await BackgroundLocation.addGeofence({
  identifier: 'store-visit',
  latitude: 52.2297,
  longitude: 21.0122,
  radius: 200,
  notifyOnEntry: true,
  notifyOnDwell: true,
  dwellDelay: 300, // seconds (5 minutes)
});

Here's the catch: iOS and Android handle dwell completely differently.

Android

Android's GeofencingClient supports dwell natively. It works reliably even when the app is terminated. Set it and forget it.

iOS

iOS has no native dwell API. The plugin implements it using an internal timer:

User enters the geofence → timer starts for dwellDelay seconds
Timer expires → dwell event emitted
User exits before timer expires → timer cancelled

The important caveat: if iOS kills your app before the timer fires, the dwell event is emitted retroactively on the next app launch — not in real-time. The plugin persists the entry timestamp internally and checks it when the app restarts.

For most use cases (visit logs, analytics), retroactive dwell is fine. For real-time alerts ("user has been on-site for 5 minutes"), keep this limitation in mind.

Managing Geofences

Check registered geofences

const { geofences } = await BackgroundLocation.getGeofences();
console.log(`Active geofences: ${geofences.length}`);
geofences.forEach(g => console.log(`  ${g.identifier} (${g.radius}m)`));

Remove a specific geofence

await BackgroundLocation.removeGeofence({ identifier: 'office' });

Removing a non-existent geofence is a no-op — no error thrown.

Remove all geofences

await BackgroundLocation.removeAllGeofences();

Attaching Metadata with Extras

The extras field lets you attach key-value metadata to a geofence that gets included in every event:

await BackgroundLocation.addGeofence({
  identifier: 'delivery-zone-7',
  latitude: 52.2100,
  longitude: 21.0200,
  radius: 250,
  notifyOnEntry: true,
  extras: {
    zoneId: '7',
    zoneName: 'Downtown Warsaw',
    priority: 'high',
  },
});

// Later, in the event handler:
BackgroundLocation.addListener('onGeofence', (event) => {
  if (event.action === 'enter' && event.extras?.priority === 'high') {
    sendPushNotification(`Driver entered high-priority zone: ${event.extras.zoneName}`);
  }
});

All extras values must be strings. If you need numbers or objects, serialize them.

iOS vs Android: What You Need to Know

Aspect	iOS	Android
Max geofences	20 (CLLocationManager limit)	20 (plugin-enforced, matching iOS)
Dwell support	Timer-based (plugin)	Native (GeofencingClient)
Survives app kill	Yes (region monitoring persists)	Yes, but not device reboot
Minimum radius	~100m recommended	~100m recommended
Detection method	Cell + Wi-Fi + GPS	Cell + Wi-Fi + GPS

Device Reboot

On iOS, geofence registrations survive device reboots — the OS re-registers them automatically.

On Android, geofences are cleared on reboot. The plugin re-registers them automatically when configure() is called (typically on app launch). Make sure you call configure() early in your app lifecycle.

Debug Mode

Enable debug mode to see geofence operations in real time:

await BackgroundLocation.configure({
  debug: true,
  debugSounds: true,
});

You'll see log messages like:

GEOFENCE ADD office
GEOFENCE ENTER office
GEOFENCE DWELL office
GEOFENCE EXIT office
GEOFENCE REMOVE office

With debugSounds: true, you'll also hear system sounds on geofence add and transition events — useful for testing in the field without staring at the console.

Production Tips

1. Don't use tiny radii

A 50-meter geofence sounds precise, but GPS accuracy varies by 5–30 meters depending on conditions. Use 100m minimum for consistent results. In urban areas with tall buildings, consider 150–200m.

2. Rotate geofences dynamically

With a 20-geofence limit, you can't monitor hundreds of locations simultaneously. Instead, use background location tracking to detect which geofences are nearby, and swap them in and out dynamically.

3. Handle the 20-geofence limit gracefully

const { geofences } = await BackgroundLocation.getGeofences();
if (geofences.length >= 20) {
  // Remove the least relevant geofence before adding a new one
  await BackgroundLocation.removeGeofence({
    identifier: findLeastRelevant(geofences),
  });
}
await BackgroundLocation.addGeofence(newGeofence);

4. Always re-register on app launch

Call configure() on every app start. This ensures geofences are re-registered on Android after a device reboot and that the plugin state is consistent.

5. Combine with HTTP posting

The bglocation plugin includes native HTTP posting with offline buffer. You can use both features together — track locations continuously and get instant notifications when users enter specific zones, all with a single plugin:

await BackgroundLocation.configure({
  distanceFilter: 50,
  http: {
    url: 'https://api.example.com/locations',
    headers: { Authorization: 'Bearer token' },
  },
});

await BackgroundLocation.start();

await BackgroundLocation.addGeofence({
  identifier: 'destination',
  latitude: 52.2297,
  longitude: 21.0122,
  radius: 200,
  notifyOnEntry: true,
});

Trial Mode

You can test geofencing without a license key. The plugin's trial mode gives you 30 minutes of full functionality — including geofencing. After the trial expires, there's a 1-hour cooldown before the next session.

Adding a geofence activates the trial timer (same as start()). On trial expiry, all geofences are automatically removed.

Summary

Geofencing is a powerful tool for location-aware apps, but the devil is in the platform details. The bglocation plugin abstracts the iOS/Android differences behind a single API while giving you the control you need for production use.

Key takeaways:

Use 100m+ radii for reliable detection
Handle the 20-geofence limit with dynamic rotation
Be aware that dwell on iOS is timer-based and retroactive after app termination
Re-register geofences on Android after reboot by calling configure() on launch
Use extras to attach business logic metadata to geofence events
Test with debug mode and trial mode before buying a license

Ready to add geofencing to your app? Check the geofencing documentation or install the plugin and try the 30-minute trial.

Building a Production-Ready Background Location Plugin for Capacitor & React Native

Szymon Walczak — Wed, 01 Apr 2026 10:00:00 +0000

If you've ever tried to track a user's location in the background on iOS or Android, you know the pain. The app gets suspended, GPS stops, and eventually the OS kills your service. And your JavaScript setInterval becomes useless the moment the screen turns off.

We spent over a year trying to solve background location with the solutions already available on the market, and eventually decided to build our own. The result is a background location plugin for Capacitor and React Native that actually works in production. Not just a proof of concept or another "works on my simulator" demo. We have created a heavily tested plugin with native HTTP posting, offline buffering, and a licensing model that doesn't lock you into another monthly bill. Here's what we learned.

The Problem

Every team building a delivery app, fleet tracker, or fitness app hits the same wall: background location on mobile is brutally hard. The official plugins (@capacitor/geolocation, expo-location) work great in the foreground. But the moment your app goes to the background:

iOS aggressively suspends your app within seconds
Android OEMs (Xiaomi, Huawei, Samsung) have custom battery optimizations that kill background services
JavaScript timers stop working as there's no setInterval in the graveyard of suspended processes
Location updates become sporadic, delayed, or simply stop

You end up stitching together 3-4 packages, writing native code, and praying it survives a weekend in production.

Our Approach: Native-First, Framework-Agnostic Core

Instead of writing JavaScript that calls native APIs, we built the core logic entirely in native code (Swift for iOS, Kotlin for Android) and kept the JS layer as a thin bridge.

The architecture has three layers:

┌─────────────────────────────────┐
│  JS Bridge (Capacitor / RN)     │  ← Framework-specific, thin
├─────────────────────────────────┤
│  Native Managers & Services     │  ← CLLocationManager / FusedLocation
├─────────────────────────────────┤
│  Shared Native Core             │  ← Framework-agnostic business logic
└─────────────────────────────────┘

Both the Capacitor and React Native plugins share the same native core. A bug fix in the core propagates to both frameworks automatically. No drift.

Making iOS Actually Track in the Background

iOS is the stricter platform. Apple is very aggressive about killing background processes. Here's what we do:

1. Correct Background Configuration

The default CLLocationManager settings actively work against background tracking — iOS will "pause" your location updates when it thinks the user stopped moving. Spoiler: it guesses wrong. A lot. We ship a carefully tuned configuration that keeps updates flowing continuously, including treating your app with navigation-level background priority.

2. Automatic Recovery After App Termination

Even with the right config, iOS can still terminate your app under memory pressure. Our plugin automatically recovers and restarts fine-grained GPS tracking when the OS wakes the app. From the user's perspective, nothing changes — tracking just keeps working.

3. Heartbeat Timer

GPS events only fire when the device moves. But what if the user stops for 20 minutes at a delivery point? Your server has no idea if the app crashed or the driver is waiting.

We fire a heartbeat event at a configurable interval (default: 15 seconds) regardless of movement, optimized for minimal battery impact.

BackgroundLocation.addListener('onHeartbeat', (event) => {
  console.log('Still alive at:', event.timestamp);
  console.log('Last known position:', event.location);
});

Making Android Survive Battery Killers

Android's challenge is different: it's not just the OS, but the OEM customizations layered on top of it.

1. Persistent Foreground Service

Our plugin uses a foreground service that the system automatically restarts after an OOM kill. On Android 12+, the notification appears instantly — no 10-second delay that confuses users.

2. Battery Optimization Detection

We detect the device manufacturer and warn developers when battery optimization is likely to kill their app:

BackgroundLocation.addListener('onBatteryWarning', (event) => {
  // event.manufacturer: "Xiaomi"
  // event.helpUrl: "https://dontkillmyapp.com/xiaomi"
  // event.isIgnoringOptimizations: false
});

// Prompt user to disable optimization
await BackgroundLocation.requestBatteryOptimization();

This links directly to dontkillmyapp.com — a community-maintained database of OEM-specific workarounds. Instead of chasing phantom kills, your app can tell the user exactly what to fix.

3. Mock Location Detection

For fleet tracking, knowing if someone is faking their GPS is critical:

BackgroundLocation.addListener('onLocation', (location) => {
  if (location.isMock) {
    // Flag for review — location may be spoofed
  }
});

Native HTTP: Because JavaScript Can't POST From the Grave

This is perhaps the most underrated feature. Most plugins give you location updates in JavaScript and expect you to send them to your server. But when your app is in the background or has been killed, that JavaScript code isn't running. Our plugin handles HTTP natively:

await BackgroundLocation.configure({
  distanceFilter: 50,
  http: {
    url: 'https://api.example.com/locations',
    headers: {
      'Authorization': 'Bearer your-token'
    },
    buffer: {
      maxSize: 1000  // SQLite-backed offline queue
    }
  }
});

When the device is offline, locations are buffered in a SQLite database (up to 1,000 entries by default). When connectivity returns, they're sent automatically with retry logic. You get feedback via the onHttp event:

BackgroundLocation.addListener('onHttp', (response) => {
  console.log(`Status: ${response.statusCode}`);
  console.log(`Buffered: ${response.bufferedCount}`);
  if (!response.success) {
    console.log(`Error: ${response.error}`);
  }
});

No extra HTTP library. No separate background task scheduler. It just works.

Adaptive Distance Filter

Static distance filters are a trade-off: too small means battery drain, and too large means missed data points. We built an adaptive mode that automatically adjusts based on speed:

await BackgroundLocation.configure({
  distanceFilter: 'auto',
  autoDistanceFilter: {
    targetInterval: 10,   // seconds between updates
    minDistance: 10,       // meters
    maxDistance: 500       // meters
  }
});

The algorithm reacts faster to deceleration than acceleration — because when a driver slows down near a destination, you need precision now, not after three more GPS fixes. In practice: highway driving → large filter (saving battery) → approaching a destination → filter drops rapidly for precise tracking.

Geofencing: Built-In, Not Bolted On

You can monitor up to 20 geofence regions natively, even when the app is killed:

await BackgroundLocation.addGeofence({
  identifier: 'warehouse-a',
  latitude: 52.2297,
  longitude: 21.0122,
  radius: 200,
  notifyOnEntry: true,
  notifyOnExit: true,
  notifyOnDwell: true,
  dwellDelay: 30000 // 30 seconds
});

BackgroundLocation.addListener('onGeofence', (event) => {
  console.log(`${event.action} ${event.identifier}`);
  // "enter warehouse-a" / "dwell warehouse-a" / "exit warehouse-a"
});

On iOS this uses CLCircularRegion (persisted across app restarts by the OS). On Android, GeofencingClient with a BroadcastReceiver. Same API, same behavior.

Testing: 890+ Automated Tests

We do not treat "it works on my phone" as a test strategy. The plugin has 890+ automated tests across iOS, Android, web, and the test app:

Layer	Count	Framework
iOS native	267	XCTest (SPM)
Android native	343	JUnit 5 + MockK
Web fallback	164	Vitest
Test app	116	Vitest + Playwright

Plus 567 additional tests in the shared native core library (245 XCTest + 322 JUnit).

The three-layer architecture makes this possible: pure helper classes and models have zero platform dependencies — they're fully testable on JVM and SPM without simulators or devices.

The Licensing Model

We chose a perpetual license — you buy once, and you use it forever. No recurring invoice just to keep your fleet tracking app running.

$199 (Indie) — 1 app
$399 (Team) — up to 5 apps
$499 (Factory) — up to 20 apps

Each license includes 1 year of updates. After that, your version keeps working — you just don't get new releases unless you renew. No API key to validate against a server. No phone-home checks. The license is validated entirely offline — it works in airplane mode, in tunnels, everywhere.

There's a full trial mode — 30-minute sessions with all features, no credit card, no license key. Install and go:

npm install @bglocation/capacitor
# or
npm install @bglocation/react-native

Getting Started

Here's a minimal working example:

import { BackgroundLocation } from '@bglocation/capacitor';

// 1. Request permissions
await BackgroundLocation.requestPermissions({
  permissions: ['location']
});
await BackgroundLocation.requestPermissions({
  permissions: ['backgroundLocation']
});

// 2. Configure
await BackgroundLocation.configure({
  distanceFilter: 50,
  heartbeatInterval: 15,
  debug: true
});

// 3. Listen for events
BackgroundLocation.addListener('onLocation', (location) => {
  console.log(`${location.latitude}, ${location.longitude}`);
});

// 4. Start tracking
await BackgroundLocation.start();

That's it: background tracking, heartbeat, and debug logging in about 10 lines.

What's Next

The React Native port (@bglocation/react-native) uses TurboModules and supports both Expo and bare React Native. Same native core, same features, same API. One license covers both frameworks (tied to bundle ID, not framework). We're working on documentation, more tutorials, and — if there's demand — Flutter support.

If you're building something that needs reliable background GPS tracking, give the trial a spin. No key needed, all features included, 30 minutes per session.

Website & Docs: bglocation.dev
npm (Capacitor): @bglocation/capacitor
npm (React Native): @bglocation/react-native