App Store & Google Play review

Both stores look closely at apps that use location in the background. Long Ping takes care of the technical side (permission flow, privacy manifest, foreground service); the declarations, disclosures and policy answers are yours. Use this as a checklist before you submit.

Apple App Store

Purpose strings that say who sees the location and why. NSLocationWhenInUseUsageDescription and NSLocationAlwaysAndWhenInUseUsageDescription in Info.plist (see Installation). Vague strings like “We need your location” are a common reason for rejection.
Ask for “When In Use” first, then “Always”. requestPermission('always') already does this in two steps. Show your own rationale screen before calling it. See Permissions.
Background location has to be core to the app. The App Store Review Guidelines allow background modes only for their intended purpose (guideline 2.5.4) and location only where it is directly relevant to the app’s features (5.1.5). A driver or field-service app qualifies; tracking as a side feature does not. Say what it is for in the review notes, and include a demo account if the feature sits behind a login.
App Privacy label. In App Store Connect, declare Precise Location, linked to the user, with the purposes you actually use it for. The LongPing pod’s privacy manifest declares the plugin’s own use; your label must cover your app.
A privacy policy that covers location data, linked in App Store Connect.
Sensible intervals. Reviewers and users notice battery drain. Use a parked interval, and stop tracking at the end of a shift; see Choosing intervals & battery.
Optional: ios.showsBackgroundLocationIndicator: true shows the blue status-bar indicator, which makes background use obvious to the user.

Read Apple’s App Store Review Guidelines (sections 2.5.4 and 5.1, Privacy) and Apple’s documentation on App privacy details.

Google Play

Background location declaration. Because the plugin declares ACCESS_BACKGROUND_LOCATION, Play Console asks you to declare background location access under App content: which core feature needs it, and a short video showing the prominent disclosure and the feature in use. Plan for review time before release.
Foreground service declaration. Play Console asks apps targeting Android 14 and newer to declare their foreground service types. Long Ping uses one foreground service of type location: describe the user-visible tracking it performs (the notification) and when it runs.
A prominent disclosure in the app, before the “Allow all the time” request. Google requires an in-app screen, shown during normal use (not only in the privacy policy), that tells the user what is collected and why, and asks them to accept. For background location it must follow this pattern:

This app collects location data to enable ___, ___ and ___ even when the app is closed or not in use.

Show it before requestPermission('always'), and only continue when the user taps an explicit “accept” or “continue” button.
Data safety form. Declare precise location as collected (and shared, if you share it), the purposes, that it is encrypted in transit (use an https:// http.url), and whether users can request deletion.
A privacy policy that covers location data, linked in Play Console and inside the app.
REQUEST_IGNORE_BATTERY_OPTIMIZATIONS only if your app qualifies. Google Play restricts it to certain kinds of apps, so Long Ping does not declare it. See Android battery managers.

A disclosure screen can be as simple as this (shown on Android before asking for “Allow all the time”):

function LocationDisclosure({ onAccept, onDecline }: { onAccept: () => void; onDecline: () => void }) {
  return (
    <View style={styles.screen}>
      <Text style={styles.title}>Location while you are on duty</Text>
      <Text style={styles.body}>
        This app collects location data to enable live delivery tracking and arrival times for dispatch even
        when the app is closed or not in use.
      </Text>
      <Button title="Continue" onPress={onAccept} />
      <Button title="Not now" onPress={onDecline} />
    </View>
  );
}

Read Google Play’s User Data policy (prominent disclosure and consent), its policy on permissions that access sensitive information (location permissions), and the Play Console Help articles on background location access, foreground service types and the Data safety section.

Only need foreground location?

If your app only tracks while it is open, you can avoid the background-location declaration on Google Play by removing the permission the plugin’s manifest brings. In your app’s manifest:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <uses-permission
        android:name="android.permission.ACCESS_BACKGROUND_LOCATION"
        tools:node="remove" />

    <!-- … the rest of your manifest … -->
</manifest>

Then ask with requestPermission('whenInUse').

What changes on Android 10 and newer, where background location is a separate permission:

There is no “Allow all the time”; the best status you get is WHEN_IN_USE.
Tracking started while the app is open runs in the foreground service, but it cannot be restarted from the background. After the app’s process ends, after a reboot, or when the watchdog would restart it, tracking waits until the user opens the app again. The log and the error event (PERMISSION_DENIED) say so.

If tracking after the app is closed matters to you, keep the permission and go through the declaration.