Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: iOS polygon geofence ENTER frequently missed since 5.x (stationary device / app terminated) — single polygon vs split polygons?

Open
  • Is something wrong?
#1,719 8 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
8/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Tech stack
dart, flutter, ios
Domain
mobile

Research direction

The payload names no source files, tests or entry points, so there is no obvious starting file. It is a production support question asking five things, including whether the 5.6.0 stationarity change stops the polygon hit-tester before ENTER is confirmed. Checking that would require maintainer knowledge of the iOS native geofence code, and done would mean a maintainer answer, not a code change.

Written by the indexing model from the issue text.

Description

Required Reading
  • Confirmed
Plugin Version

5.7.0

Flutter Doctor
$ flutter doctor
[✓] Flutter (Channel stable, 3.47.2, on macOS 26.5.2 25F84 darwin-arm64, locale en)
[✓] Xcode - develop for iOS and macOS (Xcode 26.1.1)
Mobile operating system(s)
  • iOS
Device Manufacturer(s) and Model(s)

Many iPhone models in production (iPhone 11 through iPhone 17; most common: iPhone 16, 15, 14, 17 Pro, 17, 13)

Device operating system(s)

iOS 18.6 – iOS 27.2 (mostly iOS 26.x)

What happened?

We urgently need guidance — polygon geofence ENTER is no longer firing reliably on iOS, and it's affecting our users in production.

Current behaviour: we use a single polygon geofence per area in geofences-only mode (startGeofences()).

  • Since upgrading from 4.18.2 to 5.7.0, polygon ENTER is missed on about 30% of days, compared with about 10% before the upgrade (same devices).
  • On those days our app logs show no onGeofence callback at all while the device is inside the polygon. The same devices do receive ENTER on other days.
  • Misses are most common when the device arrives and then stays stationary, and when the app was terminated or suspended before arrival.

Expected behaviour: a polygon ENTER fires once the device is inside the polygon — including when the app was terminated/suspended, and when the device is stationary after arriving.

Image

Attached image: two example areas (in metres) comparing our current single polygon (Option 1) with the same area split into smaller polygons (Option 2):

  • Area A (~12.9 ha): Option 1 containing circle 286 m; Option 2 = 8 polygons, containing circles 53–125 m.
  • Area B (~9.7 ha, long/narrow): Option 1 containing circle 395 m; Option 2 = 6 polygons, containing circles 86–165 m.

Questions:

  1. Would splitting into smaller polygons (Option 2) give more reliable polygon ENTER on iOS than a single polygon — when the app is terminated, suspended, or the device is stationary after arriving?
  2. Is there a minimum containing-circle size for a polygon below which polygon ENTER becomes unreliable on iOS?
  3. After a relaunch from terminated via the containing-circle event, does the polygon hit-tester keep running until ENTER is confirmed, even if the device becomes stationary before enough fixes are collected? Could the 5.6.0 change ("detects stationarity itself and releases location updates while the device is parked") stop it before ENTER is confirmed? That would match what we see.
  4. With smaller polygons, does each polygon use one of the 20 iOS regions, and can moving between adjacent polygons cause extra EXIT/ENTER events?
  5. Is there a configuration you recommend to make polygon ENTER more robust on iOS in these cases?

We're happy to try any test build or configuration you suggest.

Plugin Code and/or Config
await BackgroundGeolocation.ready(Config(
  geolocation: const GeoConfig(
    locationAuthorizationRequest: 'Always',
    geofenceModeHighAccuracy: true,
    geofenceProximityRadius: 2000,
    geofenceInitialTriggerEntry: true,
    showsBackgroundLocationIndicator: false,
    useSignificantChangesOnly: true, // per your guidance, only applies to start()
    filter: LocationFilter(
      policy: LocationFilterPolicy.passThrough,
      useKalman: false,
      trackingAccuracyThreshold: 0,
      odometerAccuracyThreshold: 0,
    ),
  ),
  app: AppConfig(
    startOnBoot: true,
    stopOnTerminate: false,
    enableHeadless: true,
  ),
  http: HttpConfig(autoSync: false),
  persistence: const PersistenceConfig(
    persistMode: PersistMode.none,
    maxRecordsToPersist: 0,
  ),
  logger: LoggerConfig(logLevel: LogLevel.off),
  reset: true,
  isMoving: true,
));

// Geofences-only mode; start() (full tracking) is only used after an ENTER.
await BackgroundGeolocation.startGeofences();

// One polygon geofence per area:
await BackgroundGeolocation.addGeofence(Geofence(
  identifier: '<zone-id>',
  vertices: [/* polygon vertices */],
  notifyOnEntry: true,
  notifyOnExit: true,
  extras: {/* app metadata */},
));
Relevant log output
Native plugin logging is disabled in production (logLevel: off) for privacy reasons,
so we don't have TSLocationManager logs from affected devices.
App-side logs confirm no onGeofence callback is received on the affected days.
Dominant language
Dart
Stars
732
Forks
287
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from transistorsoft/flutter_background_geolocation

All issues in transistorsoft/flutter_background_geolocation

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.