[Help Wanted]: Fully disable motion detection when using Significant Location Changes on iOS

[fractalbeauty]

Required Reading

• Confirmed

Plugin Version

5.1.1

Mobile operating-system(s)

• iOS
• Android

Device Manufacturer(s) and Model(s)

iPhone, unsure of model

Device operating-systems(s)

iOS 18.6

React Native / Expo version

0.81

What do you require assistance about?

Hello, we're investigating some issues with battery usage in our app that uses react-native-background-geolocation.

To save battery, we are using the Significant Location Changes API on iOS. We have also configured disableMotionActivityUpdates: false and disableStopDetection: false since we are using SLC and it doesn't seem like stop detection is needed. I think disableMotionActivityUpdates: false might be wrong (according to the docs), since it uses the expensive fallback instead of CMMotionActivityManager. I'm pretty sure changing it back to true will save some battery, but we would like to completely disable activity detection if possible, assuming that monitoring CMMotionActivityManager also costs some battery compared to only use SLC.

Is it possible to configure the SDK to never use TSMotionDetector/CMMotionActivityManager? Is motion detection needed at all when SLC is used?

I can provide more complete logs if needed.

[Optional] Plugin Code and/or Config

{
  geolocation: {
    useSignificantChangesOnly: true,
    desiredAccuracy: BackgroundGeolocation.DesiredAccuracy.Low,
    deferTime: Platform.OS === 'android' ? 10 * 60 * 1000 : undefined,
    disableLocationAuthorizationAlert: true,
    showsBackgroundLocationIndicator: false,
  },
  activity: {
    disableMotionActivityUpdates: Platform.OS === 'ios',
    disableStopDetection: Platform.OS === 'ios',
  },
  app: {
    stopOnTerminate: false,
    startOnBoot: true,
  },
  persistence: {
    persistMode: BackgroundGeolocation.PersistMode.Location,
    maxDaysToPersist: 30,
    locationTemplate:
      '{"location":{"latitude":<%= latitude %>,"longitude":<%= longitude %>},"dateTime":"<%= timestamp %>","accuracy":<%= accuracy %>,"version":1}',
  },
  http: {
    batchSync: true,
    url: `redacted`,
    method: 'POST',
    autoSync: true,
    autoSyncThreshold: 10,
    rootProperty: 'locations',
    maxBatchSize: 10_000,
  },
  logger: {
    logMaxDays: 7,
    logLevel: LogLevel.Verbose,
  },
}

[Optional] Relevant log output

Config at launch (trimmed):

2026-08-14 13:52:36.575  TSLocationManager (build 4109)
{
    activity = {
        activityRecognitionInterval = 10000;
        disableMotionActivityUpdates = 1;
        disableStopDetection = 1;
        minimumActivityRecognitionConfidence = 70;
        stopDetectionDelay = 0;
        stopOnStationary = 0;
        triggerActivities = "";
    };
    geolocation = {
        desiredAccuracy = 100;
        pausesLocationUpdatesAutomatically = 1;
        showsBackgroundLocationIndicator = 0;
        stationaryRadius = 25;
        stopTimeout = 5;
        useSignificantChangesOnly = 1;
    };
    preventSuspend = 0;
    enabled = 1;
}

start still starts the detector (SLC starts on the next lines):

2026-08-14 13:52:36.580  App launched with background=true, location=true
2026-08-14 13:52:37.147  -[TSTrackingService start:] trackingMode: 1
2026-08-14 13:52:37.148  -[TSMotionDetector start]
2026-08-14 13:52:37.148  -[TSMotionDetector startSensorDetection]
2026-08-14 13:52:37.148  -[TSTrackingService changePace:] isMoving: 0
2026-08-14 13:52:37.148  -[TSLocationRequestService requestLocation:] [motionchange] maximumAge: 5000
2026-08-14 13:52:37.148  Adaptive sampling -> dt=0.100s (10 Hz)
2026-08-14 13:52:37.149  -[TSScheduler startMonitoringSignificantLocationChanges]

Classifier keeps running and flip-flops at speed=0.20 (still → moving → still → running/100 → still):

2026-08-14 13:52:47.285  classifyWithSpeed: walkP=2.137 runP=2.574 speed=0.20
2026-08-14 13:52:47.287  Adaptive sampling -> dt=0.200s (5 Hz)
2026-08-14 13:52:47.287  onMotionActivityChange: | still/80 | isMoving: 0
2026-08-14 13:53:07.236  classifyWithSpeed: walkP=93.070 runP=101.557 speed=0.20
2026-08-14 13:53:07.237  Adaptive sampling -> dt=0.100s (10 Hz)
2026-08-14 13:53:07.238  onMotionActivityChange: | moving/50 | isMoving: 1
2026-08-14 13:53:17.278  onMotionActivityChange: | still/80 | isMoving: 0
2026-08-14 13:53:27.201  Adaptive sampling -> dt=0.040s (25 Hz)
2026-08-14 13:53:27.201  onMotionActivityChange: | running/100 | isMoving: 1
2026-08-14 13:53:47.188  onMotionActivityChange: | still/80 | isMoving: 0

Those flips request standard location updates ([motionchange] 20 m), which defeats SLC:

2026-08-14 18:25:33.193  Classifier suggests still/80 at speed=-1.00
2026-08-14 18:25:33.195  -[TSTrackingService changePace:] isMoving: 0
2026-08-14 18:25:33.196  requestLocation: [motionchange] maximumAge: 5000
2026-08-14 18:25:33.209  trySatisfy [motionchange] desiredAccuracy: 20.0 m

Session counts (13:48–21:37): 1642 classifier ticks, 188 activity changes, 119 isMoving flips

[christocracy]

Investigating.

[christocracy]

can you send me a log file from .emailLog?

[fractalbeauty]

I've emailed it to you for privacy.

[christocracy]

got it, thanks.

[fractalbeauty]

We also have some additional native code to request high-accuracy locations when we get a location from SLC, which you might see in the log:

// In AppDelegate.swift
//
// override func application(
//    _ application: UIApplication,
//    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil
//  ) -> Bool
// ...

let bgGeo = BackgroundGeolocation.sharedInstance()
bgGeo.onLocation({ [weak self] event in
  let accuracy = event.location.horizontalAccuracy

  let secondsSinceLastRequest = Date().timeIntervalSince(self?.lastGetCurrentPositionTime ?? .distantPast)
  bgGeo.log("debug", message: "Received onLocation with accuracy=\(accuracy)m secondsSinceLastRequest=\(Int(secondsSinceLastRequest))s")

  // If this location is a significant location change (not from an active
  // `getCurrentPosition` request), and the accuracy is low, request a
  // high-accuracy location using `getCurrentPosition`.
  //
  // Throttle to once per 60s in case we get frequent locations. This also
  // ensures that the locations from a `getCurrentPosition` request don't
  // trigger more requests for high-accuracy locations.
  guard let self, accuracy < 0 || accuracy > 100, secondsSinceLastRequest >= 60 else { return }

  bgGeo.log("debug", message: "Requesting getCurrentPosition")

  lastGetCurrentPositionTime = Date()
  let request = TSCurrentPositionRequest.make(
    success: { highAccEvent in
      bgGeo.log("debug", message: "getCurrentPosition success with accuracy=\(highAccEvent.location.horizontalAccuracy)m")
    },
    failure: { error in
      bgGeo.log("error", message: "getCurrentPosition failed: \(error)")
    }
  )

  // `getCurrentPosition` always requests a high-accuracy location and
  // samples until the accuracy is below `desiredAccuracy`. Requesting 10m
  // here shouldn't be much more expensive than 100m because the GPS radio
  // is already on.
  //
  // https://docs.transistorsoft.com/react-native/CurrentPositionRequest:
  // > The SDK always requests location from the native API at maximum
  // > accuracy (DesiredAccuracy.High), regardless of the desiredAccuracy
  // > threshold set here. [...] The SDK stops sampling as soon as it
  // > receives a location with accuracy ≤ desiredAccuracy and returns it
  // > immediately.
  request.desiredAccuracy = 10
  // Allow stale locations for up to a minute in case the OS has a recent
  // high-accuracy location (e.g. requested by another app) to possibly
  // save battery. Significant location changes are throttled to every ~5
  // minutes so this is fresh enough.
  request.maximumAge = 60 * 1000

  bgGeo.getCurrentPosition(request)
}, failure: { _ in })

let isBackgroundLaunch = application.applicationState == .background
let isLocationLaunch = launchOptions?[.location] != nil
bgGeo.log("debug", message: "App launched with background=\(isBackgroundLaunch), location=\(isLocationLaunch)")

[christocracy]

why are you using the Swift API directly in your React Native app?

[christocracy]

5.1.1

Also, the latest version is 5.4.0

[fractalbeauty]

To avoid running JS on every event. We're aware it's not officially supported but it works well for us.

Has anything related to this issue changed since 5.1.1? We can upgrade but there's nothing in the changelog that seemed relevant.

[christocracy]

To avoid running JS on every event.

It's perfectly ok to use the Swift API. Well done for doing that.

But if you're hoping to save battery by trying to avoid the JS api, it's likely not going to do anything significant.

What consumes battery is an app staying awake in the background for long periods of time (and doing HTTP requests). Requesting a location every 15 minutes won't be a significant drag on the battery.

[fractalbeauty]

Comparing with our previous logs that didn't set disableMotionActivityUpdates:

• With SLC + disableMotionActivityUpdates: true, the app sometimes stays awake in the background, wasting battery
• With SLC but without disableMotionActivityUpdates, the app is not kept awake, but it is still woken up for activity events. Some activity events result in requesting GPS locations

So, we should definitely revert our config to set disableMotionActivityUpdates: false.

But is it possible to completely disable activity detection, so the app is not woken up at all for activity events? Since we're using the SLC events for locations, does the SDK need the activity events for anything?

[christocracy]

Do you have any more of the SDK's Swift API implemented beyond what's shown? It's impossible to constantly run the accelerometer in the background unless some other iOS Background Capability is activated (eg: background location). with useSignificantLocationChangeOnly: true, the SDK does not hold location-services ON.

When you're gathering those logs, you're not running with the XCode debugger running, right?

I'm testing my demo app with your Config and the with my app in the background, I get no background activity at all.

2026-08-24 13:43:10.586 🔵 -[TSAppState onEnterBackground] 

2026-08-24 13:43:10.587 🔴 -[TSTrackingService stopUpdatingLocation] 
.
. APP IS IN BACKGROUND FOR ~17min
.
. THEN BROUGHT TO FOREGROUND
.
2026-08-24 14:00:41.447 🔵 -[TSHttpService init]_block_invoke Network: WiFi | Flags: -R -t-----

2026-08-24 14:00:41.449 
╔═══════════════════════════════════════════════════════════
║ -[TSHttpService beginFlushWithCallback:overrideSyncThreshold:error:] 
╚═══════════════════════════════════════════════════════════

2026-08-24 14:00:41.449 🔵 -[TSHttpService armFlushWatchdog] flush=25C9CCF5-DEEC-48F5-8CF7-E72FC1F1603D watchdog_armed timeout=60.000 watchdog=65.000

2026-08-24 14:00:41.450 
╔═══════════════════════════════════════════════════════════
║ -[TSHttpService finish:error:] success=1 queued_before=0 synced=0 pages=0 duration_ms=1
╚═══════════════════════════════════════════════════════════

2026-08-24 14:00:41.454 🔵 -[TSMotionActivityClassifier classifyWithSpeed:] walkP=2488.893 runP=844.567 var=0.001 jerk=0.030 gyroRMS=0.086 speed=-1.00 wins(w=1 r=0)

2026-08-24 14:00:41.515 🔵 -[TSAppState onEnterForeground] 

[fractalbeauty]

That's the only usage of the Swift API we have. On the JS side, in addition to the .ready(config) in the issue body, we use setConfig({ http: { headers: ... }, app: { notification: ... }, logger: ... }), sync(), getState(), getCount(), and we use the scheduler:

// schedule is built from app data and this code runs when it changes
await BackgroundGeolocation.setConfig({ app: { schedule } });

if (schedule.length > 0) {
  await BackgroundGeolocation.startSchedule();
} else {
  await BackgroundGeolocation.stopSchedule();

  // `stopSchedule` doesn't stop tracking locations, so if we no longer have
  // any schedule, we need to also manually stop tracking if enabled. See
  // https://docs.transistorsoft.com/react-native/BackgroundGeolocation/#stopschedule
  const state = await BackgroundGeolocation.getState();
  if (state.enabled) {
    await BackgroundGeolocation.stop();
  }
}

Our schedules look like ['2026-06-01-00:00 2026-06-15-23:59', '2026-07-10-00:00 2026-07-20-23:59'].

The log I sent is from a production build, no debugger attached.

We also use BackgroundFetch for some periodic network requests, but that shouldn't matter. We use foreground location via other libraries for some maps to show the user's location. We do have location in UIBackgroundModes, but that shouldn't matter either.

In your test, were you moving to trigger motion/activity events during the time it was sleeping? When using SLC with disableMotionActivityUpdates=false (not the config and logs I sent; other logs we have), we do see the device sleeping while still, but we still see activity events too:

// logs with SLC=true, disableMotionActivityUpdates=false

2026-06-27 11:13:40.555 ✅ -[TSSchedule trigger:] ON
2026-06-27 11:13:40.555 ║ -[TSTrackingService start:] 🟢 trackingMode: 1
2026-06-27 11:13:40.555 🟢 -[TSMotionDetector start]
2026-06-27 11:13:40.561 🟢 -[TSTrackingService startMonitoringSignificantLocationChanges]
2026-06-27 11:13:40.565 🔴 -[TSTrackingService stopUpdatingLocation]
2026-06-27 11:13:40.568
╔═══════════════════════════════════════════════════════════
║ -[TSTrackingService onMotionActivityChange:] | still/100 | isMoving: 0
╚═══════════════════════════════════════════════════════════
2026-06-27 11:14:41.184
║ -[TSTrackingService onMotionActivityChange:] | unknown/100 | isMoving: 0
2026-06-27 11:14:41.824
║ -[TSTrackingService onMotionActivityChange:] | still/33 | isMoving: 0

We would like to completely disable motion/activity detection events when SLC is used, if they aren't needed. Could it be related to the scheduler? From the logs, it seems like motion detection is always started, even with SLC enabled.

For now, we will set disableMotionActivityUpdates: false and try updating the SDK, but it does seem like we could save even more battery if SLC is the only thing that wakes up the app.

[christocracy]

The scheduler enables its own SLC location updates (for periodically evaluating the schedule). with useSignificantChangesOnly: true, there should be active location updates. The accelerometer cannot keep an app alive in the background. I wish it could, that'd be awesome.

Can you please enable disableMotionActivityUpdates: true and go outside for field-test of >2km then send me logs.

In your test, were you moving to trigger motion/activity events during the time it was sleeping?

Yes, I took a bike ride. Motion-updates alone cannot keep an iOS app alive in the background.

[fractalbeauty]

I understand that the accelerometer can't keep the app alive. Are you saying that something else must have been keeping the app open in the background during that time?

The logs I emailed already have that configuration: 2026-08-14 13:52:36.575 TSLocationManager init with disableMotionActivityUpdates = 1 (line 1102) and useSignificantChangesOnly = 1 (line 1192). Then there are continuous TSMotionActivityClassifier logs for a few hours (for example, up to 2026-08-14 21:16:53.806).

Is there something different to test that isn't shown in those logs? I don't have an iOS device to test on, so it'll take some time to test again.

I've changed our config to use useSignificantChangesOnly: true, disableMotionActivityUpdates: false, and disableStopDetection: false, and will try to get new logs. I am pretty sure this config will still get activity events though, based on the previous logs. Does monitoring these events cost any battery? It seems like they aren't needed with SLC, so ideally we could not monitor them at all.

[christocracy]

Does monitoring these events cost any battery?

The problem is not the monitoring of the accelerometer, it's that those logs you provided show an app not being suspended. That alone is responsible for the battery drain.

What is the story from that user who provided those logs?