[Bug]:iOS: getCurrentPosition returns stale Location older than maximumAge after upgrading to v5

[goblinss]

Required Reading

• Confirmed

Plugin Version

5.2.0

Flutter Doctor

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.35.1, on macOS 26.5.1 25F80 darwin-arm64, locale ja-JP)
[✓] Android toolchain - develop for Android devices (Android SDK version 36.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 26.5)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2026.1)
[✓] VS Code (version 1.124.0)
[✓] Connected device (3 available)
[✓] Network resources

• No issues found!

Mobile operating-system(s)

• iOS
• Android

Device Manufacturer(s) and Model(s)

iPhone 16

Device operating-systems(s)

iOS 26.5

What happened?

After upgrading from v4.x to v5.x, on iOS only, BackgroundGeolocation.getCurrentPosition() sometimes returns a very old cached Location.

Android does not exhibit this issue.

Configuration

final location = await BackgroundGeolocation.getCurrentPosition(
samples: 1,
timeout: 10,
persist: false,
maximumAge: 3000,
desiredAccuracy: 10,
);

Expected behavior

A Location older than 3000ms should not be returned when maximumAge: 3000 is specified.

I would expect either:

1. A newly acquired Location, or
2. A timeout/error if a fresh Location cannot be obtained.

Actual behavior

The returned Location contains:

{
"age": 1165.985,
"timestamp": "2026-06-12T04:55:46.516+00:00",
"accuracy": 5,
"latitude": 35.6136696922811,
"longitude": 139.7415213266829
}

getCurrentPosition() was called around:

2026-06-12T05:15:12Z

The returned Location is approximately 19 minutes old, despite maximumAge: 3000.

Additional observations

• This behavior started after migrating from v4.x to v5.x.
• iOS only.
• Android returns fresh Locations (age < 1 second) using the same code.
• The stale Location keeps the same timestamp, while only age increases over time.
• Repeated calls to getCurrentPosition() continue to return the same stale Location.

Is this expected behavior in v5, or could this be a regression related to maximumAge handling on iOS?

Plugin Code and/or Config

bg.Config(
      http: bg.HttpConfig(
        url: "https:www.example.com",
        method: 'POST',
        autoSync: true,
        batchSync: true,
        autoSyncThreshold: 3,
        maxBatchSize: 6,
        timeout: 60000,
      ),
      persistence: bg.PersistenceConfig(maxDaysToPersist: 14),
      geolocation: bg.GeoConfig(
        locationAuthorizationRequest: 'Always',
        desiredAccuracy: bg.DesiredAccuracy.high,
        distanceFilter: 200,
        pausesLocationUpdatesAutomatically: true,
        showsBackgroundLocationIndicator: true,
        activityType: bg.ActivityType.otherNavigation,
      ),

      app: bg.AppConfig(stopOnTerminate: false, startOnBoot: true),

      logger: bg.LoggerConfig(debug: false, logLevel: bg.LogLevel.warning),
    )

Relevant log output

[christocracy]

samples: 1,

Try samples: 2

[goblinss]

I tried samples: 2.

It improves the behavior, but maximumAge still does not seem to be strictly respected.

With maximumAge: 3000, I still received Locations with:

• age = 28.245 seconds
• age = 45.424 seconds

So samples: 2 avoids the very old 19-minute cached Location, but it can still return Locations older than 3000ms on iOS.

Could this still be related to maximumAge handling on iOS?

[christocracy]

Depending on the environment (indoor vs outdoor), it takes time for the device to connect to gps satellites in space. In the meantime, the SDK provides the last known location within the "samples" budget.

Go test outside.

[goblinss]

I tested outside with samples: 2.

The result looks good outdoors. All getCurrentPosition results returned fresh Locations:

• age = 0.427 seconds
• age = 0.179 seconds
• age = 0.630 seconds
• age = 0.071 seconds
• age = 0.828 seconds

So this seems to happen mainly indoors when GPS acquisition is poor.

I checked the iOS log during the indoor test.

The log contains:

• Failed to get motionState location: TSSingleLocationRequest Code=404 "No location available."
• Clock skew detected: current.timestamp < prev.timestamp

So it seems that indoors the SDK cannot acquire a new location and then falls back to the last known location.

Outdoors with samples: 2, all getCurrentPosition results were fresh (< 1 second).

[christocracy]

There is no GPS indoors.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.