Geofence-Based Automatic Clock-In for Security Workforce Apps

DEVSFLOW Guarding · 2026

Manual clock-in is one of the most friction-heavy steps in a security guard's shift. The guard arrives at the site, opens the app, navigates to the time tracking screen, and taps a button. If they forget, the operations center sees a late start. If the app is slow to load, the guard stands in a parking lot waiting for a spinner. Geofence-based automatic clock-in eliminates this friction: the guard walks onto the site, and the app records their arrival automatically.

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.

Additionally, 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.

Practical battery impact numbers from field testing: on a Pixel 7 running Android 14, monitoring a single geofence with dwell time consumes approximately 1-2% battery over a 12-hour period. On iPhone 14 with a single monitored region, the impact is under 1%. These numbers increase if you monitor multiple regions or combine geofencing with continuous GPS tracking during the shift.

The key decision is geofence radius. A smaller radius (50m) gives more precise clock-in timing but increases false negatives: GPS drift might place the guard outside the boundary when they are physically on-site. A larger radius (200m) eliminates false negatives but means the guard could be clocked in while still in the parking lot across the street. For most commercial security sites, 150m is a reasonable default, adjusted per site based on physical layout.

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

The most reliable pattern is to use the geofence as a trigger for a clock-in prompt rather than an automatic clock-in. When the dwell transition fires, the app sends a local notification: "You've arrived at [Site Name]. Scan the entry checkpoint to clock in." The guard scans an NFC tag at the site entrance, and the combination of geofence entry plus NFC scan confirms physical presence. This two-factor approach prevents all three false clock-in scenarios.

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 labor law implications that vary by jurisdiction. In most Canadian provinces and US states, time tracking must accurately reflect when the employee begins compensable work, not when they arrive on the property. A guard who arrives 20 minutes early and sits in their car is not working, but a geofence-based system might clock them in.

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.