Platform setup
Beekon declares the permissions it needs in its own manifest/Info.plist and merges them into your app at build time — but you still request the dangerous permissions at runtime and provide the OS-level declarations. Pick your platform; the tabs stay synced.
The install + first-fix flow is on the Quickstart; this page is the OS plumbing.
The .aar declares its permissions in its own manifest; they merge into your app at build. You request them at runtime and provide a NotificationConfig for the foreground service.
Dependency
Section titled “Dependency”android { defaultConfig { minSdk = 26 // Beekon's minimum }}
dependencies { implementation("io.github.beekonlabs:beekon:0.1.1")}JDK 17 to build. explicitApi() is enforced — Kotlin 2.x is recommended but your app’s version needn’t match.
Permissions
Section titled “Permissions”Add these to app/src/main/AndroidManifest.xml if you want to see them in your merged manifest:
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /><uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /><uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /><uses-permission android:name="android.permission.FOREGROUND_SERVICE" /><uses-permission android:name="android.permission.FOREGROUND_SERVICE_LOCATION" /><uses-permission android:name="android.permission.POST_NOTIFICATIONS" />FOREGROUND_SERVICE_LOCATION is required from Android 14 (API 34). POST_NOTIFICATIONS is required from Android 13 (API 33) for the foreground-service notification to be visible.
Runtime permission flow
Section titled “Runtime permission flow”Android forces a three-step sequence — you can’t ask for background location without first having foreground location, and notifications need their own grant on Android 13+.
- Request
ACCESS_FINE_LOCATION+ACCESS_COARSE_LOCATIONtogether (single dialog). - On API 29+, request
ACCESS_BACKGROUND_LOCATIONseparately. This always opens Settings on API 30+. - On API 33+, request
POST_NOTIFICATIONS.
The Compose sample at beekon-android/sample ships a LocationPermissions composable that walks through this exact sequence — copy from there if you don’t have a permissions helper.
Foreground-service notification
Section titled “Foreground-service notification”BeekonConfig.notification is required — Android shows a notification while location is captured in the background. Its three fields are documented on Configuration. The channel id and notification id are SDK-internal constants.
BeekonKit is a Swift package distributed as a signed binary .xcframework. iOS 17 is the minimum — the SDK is built on CLLocationUpdate.liveUpdates plus CLBackgroundActivitySession, with CLServiceSession(authorization: .always) on iOS 18+.
Add the package
Section titled “Add the package”In Xcode: File → Add Package Dependencies… then paste:
https://github.com/beekonlabs/beekon-ios-binary.gitSelect version 0.1.1 and add BeekonKit to your app target.
Info.plist
Section titled “Info.plist”Add usage descriptions and the location background mode. The strings appear in the system permission dialog — write them in your app’s voice.
<key>NSLocationWhenInUseUsageDescription</key><string>Used to show your live position in the app.</string>
<key>NSLocationAlwaysAndWhenInUseUsageDescription</key><string>Used to keep tracking your trips when the app is in the background.</string>
<key>UIBackgroundModes</key><array> <string>location</string></array>fetch and processing are not required for v1 — only location.
Authorization flow
Section titled “Authorization flow”Beekon does not request location permission for you — the host app drives the prompt. You must reach Always authorization before background tracking will work.
- Request
whenInUsefirst — required before you can ever ask foralways. - After the user grants
whenInUseand uses the feature once, requestalways. iOS denies silently if you ask too aggressively. - Call
Beekon.shared.start()once authorization isalways.
The sample at beekon-ios/Sample/LocationPermissionManager.swift shows the canonical two-step prompt:
private let manager = CLLocationManager()
func requestWhenInUse() { manager.requestWhenInUseAuthorization() }func requestAlways() { manager.requestAlwaysAuthorization() }Wire these to two buttons in onboarding rather than firing both at once.
beekon_flutter bridges straight to the Android .aar and BeekonKit on iOS, so background behaviour, gating, and persistence are exactly what the native tabs describe.
Install
Section titled “Install”dependencies: beekon_flutter: ^0.1.1flutter pub getDart SDK ^3.9.0, Flutter >=3.32.0. Android minSdk 26, iOS 17 — the same floors as the native SDKs.
OS configuration
Section titled “OS configuration”Request ACCESS_FINE_LOCATION (and POST_NOTIFICATIONS on Android 13+) at runtime before start(). Background tracking additionally needs ACCESS_BACKGROUND_LOCATION, requested separately after foreground location is granted. Add the iOS Info.plist keys and the location background mode — see the Android and iOS tabs above for the exact declarations.
The iOS side is SwiftPM-only — there is no podspec. On Flutter older than 3.44, enable Swift Package Manager once:
flutter config --enable-swift-package-manager@wayq/beekon-rn is a New Architecture TurboModule that bridges JS to the native SDKs. It owns no location logic.
Install
Section titled “Install”npm install @wayq/beekon-rncd ios && pod installOS configuration
Section titled “OS configuration”Declare permissions and request them at runtime — the mechanics match the native SDKs. See the Android tab for the manifest block and the iOS tab for the Info.plist keys and background mode.
- Configuration — every field and enum.
- Background execution — what’s actually keeping your app alive.
- Lifecycle & states — the state machine driving
state.