Implementation of Geofences (Geofencing) in a Mobile Application
A geofence is not just "notify when user arrives." Behind this task lies a whole layer of platform limitations that manufacturers tighten with each major OS version. An app that works perfectly on iOS 15 may go silent on iOS 17 — and that's not a bug in your code.
Platform Limitations Worth Knowing Before Development
iOS. CLLocationManager supports up to 20 active geofences simultaneously — a system limit, not ours. Minimum radius is 100 meters — anything less is not monitored. On devices without A12+ chip, accuracy is even lower. CLCircularRegion delivers didEnterRegion / didExitRegion events, but delay can be 3-5 minutes depending on battery saver mode. In iOS 13+ you must request Always authorization through a two-step dialog: first whenInUse, then the user goes to Settings. Directly requesting Always is no longer possible — Apple will reject it on review.
Android. Geofencing API in com.google.android.gms:play-services-location requires Google Play Services. On Huawei without GMS — you need a separate path through HMS LocationKit. Android 10+ introduced ACCESS_BACKGROUND_LOCATION as a separate permission, which the user grants in Settings, not in the standard dialog. On Android 12 they added SCHEDULE_EXACT_ALARM for accurate alarms — without it, Geofencing on Doze devices may not trigger at the right time. Some manufacturers (Xiaomi MIUI, Samsung One UI with aggressive battery saver) kill background services faster than the API can deliver an event.
How We Implement
iOS: Basic Scenario
let region = CLCircularRegion(
center: CLLocationCoordinate2D(latitude: 55.7558, longitude: 37.6173),
radius: 200,
identifier: "office_zone"
)
region.notifyOnEntry = true
region.notifyOnExit = false
locationManager.startMonitoring(for: region)
When you exceed the 20-zone limit — prioritize by distance from current position and dynamically reload the set of active regions via stopMonitoring / startMonitoring. Rotation logic is in locationManager(_:didUpdateLocations:).
For projects that need 20+ zones or radius less than 100 meters — switch to Visit Monitoring (startMonitoringVisits()) or Significant Location Changes combined with server-side geofence validation by coordinates.
Android: Geofencing API + WorkManager
val geofence = Geofence.Builder()
.setRequestId("warehouse_exit")
.setCircularRegion(lat, lon, 150f)
.setExpirationDuration(Geofence.NEVER_EXPIRE)
.setTransitionTypes(Geofence.GEOFENCE_TRANSITION_ENTER or Geofence.GEOFENCE_TRANSITION_EXIT)
.setLoiteringDelay(30_000) // DWELL after 30 seconds
.build()
val request = GeofencingRequest.Builder()
.addGeofence(geofence)
.setInitialTrigger(GeofencingRequest.INITIAL_TRIGGER_ENTER)
.build()
geofencingClient.addGeofences(request, geofencePendingIntent)
PendingIntent leads to BroadcastReceiver, which starts a WorkManager task instead of direct execution. This is important: direct execution of a long task from Receiver on Android 8+ causes BackgroundExecutionLimits exception.
For Huawei HMS — com.huawei.hms:location with practically identical API, but separate PendingIntent registration via GeofenceService.
Server Validation as Insurance
Mobile geofencing is unreliable by itself. For critical business scenarios (vehicle exit control, gamification with prizes), build additional server-side validation: the device periodically sends coordinates, the server checks polygon intersection via PostGIS or geofences via Redis GEORADIUS. Mobile Geofencing — fast trigger, server — final arbiter.
Handling Permissions Correctly
The most common rejection reason on App Store — incorrect NSLocationAlwaysAndWhenInUseUsageDescription. Apple reads the strings in Info.plist and requires specific descriptions: "to send notification when entering a pickup zone" instead of "for app to work."
On Google Play since May 2023, background geolocation goes through manual review. Your submission must explain the specific use case and show a video demo. Plan 3-7 days for this.
Workflow
Requirements analysis: number of zones, minimum radius, platforms, GMS presence in target audience. Architecture design with platform limitations. Implementation with correct permission handling. Testing: Walk Test through Xcode Simulator Location, real-world drives for Android. Review description preparation.
Timeline: three to six days depending on number of platforms, complexity of trigger logic, and presence of server part.