Geofence-Based Automatic Clock-In for Security Workforce Apps

A geofence can tell the app that a device may have entered an area. It cannot prove that the assigned guard began compensable work. Treat it as a prompt or corroborating signal unless the employment, privacy, and operational rules for a specific deployment support automation.

The concept is simple. The implementation has real tradeoffs around accuracy, battery consumption, false triggers, and labor law compliance. This post covers the platform APIs, the engineering decisions, and the operational considerations.

Android Geofencing API

Android's geofencing support is part of Google Play Services, accessed through the GeofencingClient class. You define a geofence by specifying a center point (latitude and longitude), a radius in meters, and the transition types you want to monitor: GEOFENCE_TRANSITION_ENTER, GEOFENCE_TRANSITION_EXIT, and GEOFENCE_TRANSITION_DWELL.

For clock-in, the typical configuration is:

• Center point: the site's main entrance or central coordinate.
• Radius: 100 to 200 meters, depending on the site's physical footprint. A single building might use 100m. A sprawling industrial complex with multiple entrances needs 300m or more.
• Transition type: GEOFENCE_TRANSITION_DWELL with a loiteringDelay of 60 to 120 seconds. This is critical. Using ENTER alone will trigger clock-in if the guard drives past the site on the highway, or if GPS jitter momentarily places them inside the radius. Dwell time requires the device to remain inside the geofence for the specified duration before firing.
• Expiration: set to the expected shift duration plus a buffer. A 12-hour shift might use an expiration of 14 hours. This prevents stale geofences from accumulating.

When the dwell transition fires, the system delivers a PendingIntent to your BroadcastReceiver or IntentService. Your handler creates the clock-in record, stores it locally, and queues it for sync. The geofence monitoring runs in the background without the app being in the foreground, which is essential because guards do not keep the app open while commuting.

Android background restrictions

Android 10+ introduced background location access as a separate permission (ACCESS_BACKGROUND_LOCATION). The user must explicitly grant this permission, and on Android 11+, the system directs users to the settings page rather than showing an in-app dialog. Your onboarding flow must clearly explain why background location is needed and guide the guard through the settings flow. Without this permission, geofence transitions will not fire when the app is in the background.

some manufacturers (Xiaomi, Huawei, Samsung) apply aggressive battery optimization that kills background services. On these devices, geofence callbacks may be delayed by minutes or suppressed entirely. The app should detect the device manufacturer and prompt the guard to disable battery optimization for the app during onboarding. The PowerManager.isIgnoringBatteryOptimizations() API lets you check this programmatically.

iOS CLCircularRegion and Core Location

On iOS, geofencing is implemented through CLLocationManager using CLCircularRegion objects. You call startMonitoring(for:) with a region defined by a center coordinate and radius. iOS limits you to 20 monitored regions per app, which is sufficient for most guard deployments since a guard typically works at one or two sites per shift.

iOS provides didEnterRegion and didExitRegion delegate callbacks. Unlike Android, iOS does not have a built-in dwell time parameter. To implement dwell-based clock-in on iOS, you handle the didEnterRegion callback by starting a timer (using DispatchQueue.main.asyncAfter or a BGTaskScheduler task) and only recording the clock-in if the guard has not exited the region within the dwell window. If didExitRegion fires before the timer completes, cancel the timer and discard the event.

iOS geofencing is battery-efficient because it uses cell tower and Wi-Fi positioning rather than continuous GPS. The tradeoff is lower accuracy: region boundary detection can be off by 100 meters or more. For clock-in purposes, this is acceptable because the geofence radius should be large enough to absorb this variance.

iOS location permission flow

iOS requires "Always" location permission for geofence monitoring to work in the background. The recommended flow is to first request "When In Use" permission, demonstrate value (show the guard their location on a site map), and then request the upgrade to "Always" with a clear explanation. Apple rejects apps that request "Always" permission without a compelling justification, so the App Store review submission should document the clock-in use case.

Accuracy vs. battery: the core tradeoff

Geofence monitoring consumes battery. The more precise you want the boundary detection, the more frequently the system polls for location, and the more battery it drains.

Both platforms use a tiered approach internally. When the device is far from any registered geofence, the system checks location infrequently using low-power sources (cell towers, Wi-Fi). As the device approaches a geofence boundary, the system increases polling frequency and may activate GPS for a precise fix. This means battery impact is minimal during commute and increases only near the site.

Do not publish a universal battery percentage. Impact varies with device, OS, motion, Wi-Fi scanning, other location consumers, and the rest of the app. Measure a complete representative shift and compare against a build with the feature disabled.

The radius is a site-specific tradeoff. Start from the physical boundary, surrounding roads and buildings, observed location accuracy, and the consequence of a late or false event. Android notes that background geofence events can arrive minutes late and that accuracy can degrade substantially when network location is weak. Test at the actual site before enabling any attendance decision.

Preventing false clock-ins

A geofence alone is not sufficient to verify that a guard is on-site and ready to work. Several scenarios can produce false clock-ins:

• The guard lives near the site and triggers the geofence while at home.
• GPS drift or signal reflection from tall buildings briefly places the device inside the geofence.
• The guard passes through the geofence during a commute without stopping.

Dwell time addresses the third scenario. For the others, combine geofence entry with a secondary verification step.

Geofence plus NFC verification

A safer pattern is to use the geofence as a trigger for a clock-in prompt. The guard can confirm in the app or scan a site checkpoint. This combines independent context, but it still does not prevent every false event because phones and basic NFC tags can be shared, moved, or cloned.

For sites that want fully automatic clock-in without NFC, apply schedule-aware filtering. The app checks whether the geofence entry occurs within a configurable window of the guard's scheduled shift start time (typically 30 minutes before to 15 minutes after). Geofence events outside this window are logged but do not trigger a clock-in.

Exit-based clock-out

Automatic clock-out on geofence exit is riskier than automatic clock-in. GPS drift could briefly place the guard outside the boundary, triggering a false clock-out mid-shift. For clock-out, use a longer dwell time on the exit event (5 to 10 minutes outside the geofence before triggering) and send a confirmation notification rather than clocking out immediately. The guard can dismiss the notification if they stepped outside briefly, or confirm the clock-out if their shift is ending.

Labor compliance considerations

Automatic clock-in creates employment, privacy, collective-agreement, and record-accuracy questions that vary by jurisdiction and workplace. Obtain qualified advice and worker-facing policy before treating location as time worked.

Several approaches address this:

• Use the geofence event as a "site arrival" record distinct from the official clock-in. The clock-in time is set to the scheduled shift start or the NFC scan time, whichever is later. The geofence event provides an attendance confirmation but does not start the billable clock.
• Allow guards to review and adjust their clock-in time at the end of the shift. The system records the geofence trigger time, the guard's confirmed start time, and any discrepancy is flagged for supervisor review.
• Implement a rounding policy consistent with the Fair Labor Standards Act (FLSA) 7-minute rule or the applicable provincial standard. Arrivals within 7 minutes of the scheduled start are rounded to the schedule time.

Regardless of the approach, the system must maintain an immutable audit log of the raw geofence events, separate from the adjusted clock-in records. If a dispute arises, the raw data is available for review.

Implementation checklist

Deploying geofence-based clock-in involves more operational work than most teams anticipate. Beyond the code, you need:

• Accurate site coordinates for every location. These must be verified on-site, not pulled from Google Maps. A building entrance can be 50 meters from the address pin.
• Per-site radius configuration in the backend, adjustable by operations managers without a code deploy.
• Device onboarding flows that handle background location permission on both platforms, including manufacturer-specific battery optimization prompts.
• A fallback manual clock-in for edge cases where geofencing fails (device without GPS, underground sites, shared devices).
• Clear communication to guards about what data is being collected and why. Transparency about location tracking is not just good practice; in many jurisdictions it is a legal requirement.