Geofencing sounds simple until an app needs more locations than the device operating system allows. That single limit changes the entire architecture of a location-based feature, and almost no guide explains it.

What Is Geofencing in Mobile Apps?

Geofencing is a location-based technology that triggers an action when a device enters or exits a virtual boundary drawn around a physical location. The boundary itself, called a geofence, can be circular (defined by a center point and radius) or a custom polygon matching an irregular real-world area. A geofencing system does not track a device continuously. It monitors location in the background and fires an event only when a transition, entry, exit, or dwell, crosses the defined boundary.

How Geofencing Technically Works

A mobile operating system monitors the device’s location using GPS, Wi-Fi, and cellular signals, then compares that location against a set of registered geofence boundaries. When the device crosses a boundary, the OS generates a transition event (entry, exit, or dwell) and delivers it to the app through a system callback, on Android this is a PendingIntent handled by a BroadcastReceiver, on iOS it is a CLCircularRegion monitored through Core Location. The app then executes its own logic in response, sending a push notification, updating a UI, or syncing data to a backend. This event-driven model, rather than continuous polling, is what keeps geofencing battery-efficient compared to constant GPS tracking.

Technologies Behind Geofencing

Geofencing draws on four distinct positioning technologies, each with different accuracy and battery tradeoffs.

GPS-Based Geofencing

GPS provides the tightest outdoor accuracy of any geofencing technology, typically 5 to 20 meters under clear, open-sky conditions. GPS accuracy degrades in dense urban areas due to signal reflection off tall buildings, an effect commonly called the urban canyon problem, and it does not work reliably indoors since satellite signals cannot penetrate most building structures.

Wi-Fi and Cellular Positioning

Wi-Fi positioning determines location by referencing nearby wireless access points with known locations, offering strong accuracy indoors and in dense urban areas where GPS struggles. Cellular positioning uses triangulation between nearby cell towers and is the least precise of the three, commonly accurate only to within a few hundred meters to a kilometer. Mobile operating systems blend GPS, Wi-Fi, and cellular signals automatically to produce a single location estimate, rather than relying on any one technology alone.

Bluetooth Beacons and RFID

Bluetooth beacons transmit a short-range signal that a device detects when it comes within roughly 10 to 50 meters, making beacons useful for precise indoor proximity detection where GPS and Wi-Fi positioning are too coarse. RFID operates at much shorter range, often centimeters to a few meters, and requires a dedicated reader rather than relying on the device’s own radios, making it better suited to controlled environments like warehouses or retail checkout points than general mobile geofencing.

Real-World Use Cases for Geofencing

Retail and Proximity Marketing

Retailers use geofencing to trigger a push notification or in-app offer when a customer enters a store’s vicinity, converting foot traffic into a marketing touchpoint at the exact moment someone is nearby.

Logistics and Delivery Tracking

Delivery and logistics platforms use geofencing to automatically update order status when a driver enters a delivery zone or arrives at a customer’s address, removing the need for manual status updates and giving customers accurate arrival estimates.

Security and Parental Control Apps

Security and family-safety apps use geofencing to alert a user when a monitored device, a child’s phone, a company vehicle, enters or leaves a defined zone, turning location boundaries into an automated safety check rather than something someone has to manually verify.

Smart Home and IoT Automation

Smart home platforms use geofencing to trigger automation, unlocking a door, adjusting a thermostat, arming a security system, based on whether a resident’s phone is approaching or leaving the property, removing the need for manual control in routine situations.

How Accurate Is Geofencing?

Geofencing accuracy in dense urban areas commonly runs 100 to 200 meters, worse than open areas, due to GPS signal reflection off tall buildings degrading raw location accuracy even though cell towers and Wi-Fi access points are denser there. In clear, open-sky conditions, GPS alone typically achieves 5 to 20 meters of accuracy, tighter than the blended urban figure. Rural areas can also see accuracy drop to several hundred meters, but for a different reason than cities, sparse cellular and Wi-Fi infrastructure gives the device fewer reference points to triangulate against. Indoor environments reduce accuracy further still, since GPS satellite signals typically cannot penetrate building structures, which is why indoor-specific use cases usually add Wi-Fi or Bluetooth beacon positioning rather than relying on GPS alone.

On-Device vs Server-Side Geofencing

On-device geofencing runs entirely through the phone’s operating system, using the Android Geofencing API or iOS Core Location, and works well for apps with a small, fixed number of locations. Server-side geofencing calculates location transitions on a backend server instead, comparing device coordinates against a database of boundaries, and is required once an app’s location count or update frequency exceeds what the device API supports.

Why the Android 100-Geofence Limit Matters

Android limits an app to 100 active geofences per device user, confirmed directly in Android’s official developer documentation. A business with more than 100 relevant locations, a retail chain with hundreds of stores, a delivery network covering an entire metro area, a facilities operator managing multiple sites, cannot register every location as an on-device geofence and hit this ceiling immediately. iOS imposes a similar practical constraint through CLCircularRegion, with Apple’s documentation recommending well under 20 simultaneously monitored regions for reliable performance, even though the hard technical cap is higher. Any business operating at real geographic scale needs to plan around this limit from the start, not discover it after building the feature.

When You Need Server-Side Geofencing

Server-side geofencing becomes necessary once an app’s total location count exceeds the device API’s practical limit, or when geofences need to update dynamically based on business logic (new store openings, delivery zones that shift by time of day) rather than being fixed at app install time. The typical pattern combines both approaches in a hybrid model, the device monitors a small, dynamically-updated subset of the nearest relevant geofences on-device for battery efficiency, while a backend server tracks the device’s broader location and swaps which geofences are actively registered as the user moves.

Third-party geofencing platforms, Radar, HERE Technologies, and Mapbox Geofencing among them, provide server-side and hybrid geofencing as a managed service, removing the need to build this infrastructure from scratch.

Battery vs Accuracy: How to Tune Geofencing

Higher location accuracy requires more frequent GPS polling, and more frequent polling drains battery faster, this tradeoff cannot be eliminated, only tuned deliberately. A geofence radius under 100 meters demands tighter GPS accuracy and more frequent location checks, increasing battery draw, while Android’s own documentation recommends a minimum radius of 100 to 150 meters specifically to reduce both false-trigger noise and power consumption. Relying on network-based location, Wi-Fi and cellular, instead of continuous GPS polling reduces battery impact significantly and works indoors, at the cost of the wider accuracy range covered above. Dwell-time requirements, waiting for a device to remain within a boundary for a set duration before firing an event, reduce false triggers from someone briefly passing near a boundary, which also reduces the number of unnecessary wake-ups and associated battery cost. The practical approach: match geofence radius and update frequency to the actual use case, a store-arrival notification does not need the same precision as a fraud-detection trigger, rather than defaulting to maximum accuracy everywhere.

Privacy and Consent Requirements for Geofencing

GDPR and CCPA Compliance for Location Data

Location data collected through geofencing qualifies as personal data under both GDPR in the EU and CCPA in California, requiring explicit, informed consent before tracking begins in either jurisdiction. GDPR requires a clear statement of why location data is being collected and how long it will be retained, while CCPA requires giving California users the ability to opt out of the sale or sharing of their location data specifically. Neither regulation permits collecting location data passively before consent is obtained, the request must come before tracking starts, not after.

Designing a Compliant Permission Flow

A compliant permission flow explains why the app needs location access before the system permission prompt appears, since a bare OS-level prompt with no context leads to higher denial rates and does not satisfy GDPR’s informed-consent standard on its own. The flow should request “when in use” location access first and only request “always allow” background access, required for geofencing to function when the app is closed, once the user understands why background tracking specifically is needed. Our guide to mobile app security best practices covers the broader security and data-handling practices that apply alongside this consent flow.

Best Practices for Implementing Geofencing

• Set a geofence radius no smaller than 100 meters. Smaller radii increase false triggers from normal GPS drift and unnecessarily drain the battery.
• Use dwell time for non-urgent triggers. Without a minimum dwell duration, a device briefly passing near a boundary fires an event that does not reflect real user intent.
• Request location permission with context first. A bare system prompt with no explanation measurably increases denial rates, reducing the number of users your geofencing feature can actually reach.
• Plan for the device API limit before building, not after. Discovering the 100-geofence ceiling mid-project means reworking architecture under deadline pressure instead of designing for it from the start.
• Cache geofence data for offline reliability. A device with no network connection at the moment of a boundary crossing should not silently miss the event, related architecture is covered in our guide to offline-first app architecture.
• Test in real urban and rural conditions, not just a simulator. Simulated location testing does not reveal how urban canyon signal reflection or rural signal sparsity affects real-world trigger reliability.
• Limit background location requests to what the feature actually needs. Requesting “always allow” for a feature that only needs foreground access invites unnecessary user distrust and app store review scrutiny.
• Remove unused geofences proactively. Stale geofences count against the device API limit and continue consuming battery for locations that no longer matter to the user.

Cost and Timeline to Add Geofencing to a Mobile App

Cost and timeline depend heavily on whether the implementation is on-device only, which is faster and cheaper to build, or requires server-side infrastructure for a large or dynamic location set, which adds real backend development time on top of the mobile implementation itself. A project already using a third-party geofencing platform (Radar, HERE, Mapbox) typically launches faster than one building server-side geofence matching from scratch, since the platform handles the scaling infrastructure directly.

Adding Geofencing to Your Mobile App

Geofencing looks simple in a demo and gets complicated the moment a business has more locations than a device API supports, or needs accuracy tuned differently for different use cases within the same app. If you’re planning a location-based feature and want an honest read on whether on-device, server-side, or hybrid geofencing fits your specific scale, our mobile app development team can walk through the architecture with you. Get in touch to talk through your specific use case.

Frequently Asked Questions