Skip to content
BGeo SDK

BGeo SDK

BGeo is a background-geolocation SDK for Flutter. It keeps tracking across app backgrounding, kill, and reboot, uploads locations natively (no Dart in the hot path), and adapts GPS use to motion to save battery.

  • iOS & Android — implemented as a Flutter plugin with a native Android/iOS engine behind a Dart MethodChannel bridge.
  • Native offline upload — a durable queue drains to your server with batching, backoff, and optional JWT refresh; survives process death.
  • Motion-based tracking — Kalman smoothing, activity recognition, a stationary geofence/region wake, elastic distance filter.
  • Closed engine, open bridge — the engine ships as a prebuilt BGeoCore.xcframework (iOS) + bgeo-android AAR (Android) behind an open Dart bridge you can read end to end. Requires a license key in release builds.

The SDK’s own source repo ships a full example app under example/ — a single-screen Flutter dev tool that registers a headless task, subscribes to onLocation/onMotionChange/onHeartbeat/ onHttp/onProviderChange/onConnectivityChange, calls ready(), and reflects tracking state in a switch. Buttons cover requesting permission, a one-shot current position, changePace(), a manual sync(), and dumping the native log to the console.

The example app's map screen on iOS and Android, each showing a tracked route recorded during a walk, the status chip, and the collected-coordinates count.

Philosophy

BGeo is designed around one idea: configure once, then get out of the way.

  • Call ready(config) once, at every app launch. It’s not a one-time setup call — it’s meant to run on every cold start, every time. The config you pass merges over whatever was persisted natively from the previous session (or the SDK’s defaults, on first run), so a launch that doesn’t call ready() at all still keeps tracking with its last known configuration.
  • The API is event-driven, not poll-driven. Subscribe to onLocation and onMotionChange once and let the engine push updates to you — there’s no location loop to manage in Dart.
  • Tracking and upload run natively and survive Dart isolate death. Once start() has been called, the native engine keeps filtering, persisting, and uploading locations whether your app is backgrounded, killed by the OS, or not yet relaunched since a reboot. Dart is a subscriber to what’s happening, not the thing making it happen.

Architecture

BGeo is an open Dart bridge around a closed, prebuilt engine: the Dart API, event plumbing, and MethodChannel bridge code are readable source (lib/src/*.dart); the location-filtering, motion-classification, persistence, and HTTP upload logic ship as compiled binaries (BGeoCore.xcframework on iOS, a bgeo-android AAR on Android). You get full visibility into how your app talks to the SDK, without needing to vendor or rebuild the tracking engine itself.

Platform support

BGeo targets iOS and Android only — there is no Flutter web or desktop support, since the tracking engine is mobile-only. See Compatibility for the full version matrix.

Where to go next

Getting Started

How it works

  • Tracking lifecycle — how the SDK tracks across foreground, background, kill, and reboot.
  • Data pipeline — how a location moves from fix to filter to queue to your server.

Guides

API Reference