To add geofencing to an app you hand the operating system a circle and let it wake you when somebody crosses it.

How a region fires, and how late

You hand over a latitude, a longitude, a radius in metres and whether you want the enter crossing, the exit crossing or both. After that the operating system watches, using whatever positioning is cheap at that moment, and it starts your app to deliver the event even if the app was closed. That is the whole appeal: you get a location trigger mobile app without running GPS all day.

The cheapness is paid for in time. Google's geofencing guide says to expect latency, usually less than 2 minutes and less again when the device has been moving. With background location limits in effect the average is about 2 to 3 minutes. If the device has been sitting still for a long stretch, it can reach about 6 minutes. You can also set a responsiveness value, which trades speed for battery in one line: a five minute setting means the check happens every five minutes, and Google notes that a low value does not guarantee an alert inside that window either.

Radius is the other half of it. Google recommends a minimum radius of 100 to 150 metres, which accounts for the accuracy of typical wifi positioning and cuts power use at the same time. A 30 metre circle around a shop door will fire late, fire twice or not fire at all. If your idea depends on knowing which side of a doorway somebody is standing on, geofencing is the wrong tool and no amount of tuning will rescue it.

Android developers, create and monitor geofences

Both platforms cap how many regions you get

This is the constraint that changes the design, and it is worth knowing before you draw a single circle. Apple is explicit about it: so that all apps can take part, Core Location prevents any single app from monitoring more than 20 conditions of any type at the same time. Regions are shared hardware, not something your app owns.

Android is more generous and still finite. Google's geofencing guide sets the limit at 100 geofences per app on a single user device, and 100 per app per device user on a shared one. So the number to design against is 20, because that is the one both platforms can honour. Registering 21 regions on iOS is not a warning you can ship past.

The design that survives is a moving window. Keep the full list on your server or on disk, register only the handful nearest the person, and swap the set whenever they move far enough that a different handful is nearest. That turns a list of any length into 20 live regions for the cost of one extra rule about when to re-register. Most geofencing features that work do this. Most that fail tried to register everything on first launch and quietly lost the rest.

Budget one region for the swap itself. A common pattern is to keep a large circle around the area the current set covers, and use its exit crossing as the signal to fetch the next set. That leaves you 19 real ones on iOS, which is another reason the practical ceiling is lower than the published one.

Apple, monitoring the user's proximity to geographic regions

What to do with a crossing once you have one

A crossing is an event, not an experience. Something has to happen next while the app is in the background or not running at all, and on both platforms that usually means a notification fired from the same background task. This is why geofencing and push notifications are nearly always built together: a geofence notification app is two features, and the second one has its own permission prompt the person can refuse.

Decide early whether the message is made on the device or asked for from your server. On the device is simpler and still works in a car park with no signal. Going through a server lets you change the wording without shipping a build and lets you see what was sent. If the phone may well be offline at the moment of the crossing, that decision belongs with the rest of your offline app functionality rather than with the geofence.

Then guard against the drive-by. Somebody who passes your circle at speed gets exactly the same enter event as somebody who parks and walks in, and an enter area alert app that cannot tell them apart becomes noise within a week. Google's own answer is a dwell transition with a loitering delay, so the alert fires only after the person has stayed inside for a set time. In a React Native and Expo project the geofencing task reports enter and exit only, so you build the equivalent yourself: hold the event, look again a few minutes later, and drop it if they have already gone.

Build it, buy it or leave it out

Geofencing is cheap to add and expensive to make trustworthy, so the decision comes down to how wrong it is allowed to be. If a late or missed alert is an annoyance, build it. If money, safety or a record somebody will rely on depends on the crossing, do not: no cap, no radius and no latency figure on this page can support that. Pair it with a manual confirmation instead, and treat the geofence as a prompt rather than a proof.

Count the permission cost too. A region that fires while the app is closed needs background or always-on location, the heaviest location permission either platform offers, and the person sees that prompt described in the system's words rather than yours. A share of them will say no. Design so the app still makes sense for those people, because a feature that only exists for the ones who granted always-on location is a feature most of your users never see working.

Finally, count what it replaces. For a lot of arrival ideas the honest competitor is a button. If the person opens the app when they get there anyway, a check in tap is free, instant, has no permission prompt, no cap and no radius floor. Geofencing earns its place only when the whole point is that nobody has to remember. That is a real category, and it is smaller than it looks at the start of a project.