Building a GPS scavenger hunt app: the unglamorous problems that decide whether it works

Sam Ellis — Sat, 14 Nov 2026 00:40:13 +0000

Most write-ups about location-based games stop at the fun part: you turn up somewhere, match what you see with your camera, and the next spot unlocks. I work on exactly that kind of app — Ping Hunt generates a hunt near you, walks you to real locations by GPS, and checks the scene against your camera.

Here are the problems that actually cost us time, and what we learned solving them.

1. GPS accuracy is a distribution, not a number

The most common bug report in a location game is "it says I'm at the right place but won't unlock".

Android's Location.getAccuracy() is a radius of confidence in metres, and it is rarely what people assume. On a phone sitting flat on a café table you will often see 5–20 m of horizontal accuracy. Indoors, behind a glass wall, it can be 50 m or worse, and in a dense city canyon it degrades further because the receiver is tracking reflections off buildings.

So never ask "is the user at this location?" Ask "is the user inside the radius of this location, expanded by the current accuracy?"

Tight spots (a specific bench, a specific shopfront): 20–30 m
General spots (a park, a square): 50–80 m
Always: also accept the fix if the distance is within radius + min(accuracy, 40)

That last term is the one that matters. If the phone says "I might be within 40 m of you", refusing a 35 m reading is simply wrong.

2. Do not trust a single fix

A single Location callback can be a cached fix from ten minutes ago. On a cold start Android happily hands back the last known location before a fresh one arrives, and a stale fix is worse than no fix because it can be kilometres away.

Always attach a timestamp and discard anything older than roughly 15 seconds. If you want more certainty, require two consecutive fixes that agree with each other before unlocking — a cheap hedge against the wandering positions a phone produces while it is moving.

3. The camera match needs to be forgiving

Camera matching sounds like the hard part. It isn't, if you design for tolerance rather than precision.

Two rules have done most of the work for us:

Never compare against a single reference photo. One photo of a location is one lighting condition, one camera, one season.
Score, don't gate. Compute how well the captured image matches and accept above a fairly low threshold. It is much better UX to let someone through with a slightly imperfect match than to lock them out in the rain.

The thing that is worth doing properly is the feedback. If a match is rejected, say why in a way that helps: not "wrong photo", but "that looks like the fountain, but we are looking for the red door on the north side". The difference between a frustrating wall and a fun retry is usually the quality of the error message.

4. Do the maths before you ask for permissions

People deny location permission when they cannot see why you want it, and they revoke it when it feels invasive. The request that works is specific and adjacent to the value:

Ping Hunt uses your location to guide you to the next spot. Your location stays on your phone.

Then actually mean it — do not ship a background location permission you never need. A location game only needs foreground location while the hunt is open, and only for as long as the hunt is open.

5. Design for a bad signal

A hunt will happen in a basement, a forest, and a basement in a forest. The interesting failure mode is not the missing fix — it is the stale one, where the app happily says "you are 3 metres from the target" based on a fix from before you walked into the tunnel.

A practical fallback is to let the player confirm manually when the GPS has been unhelpful for a while, with a clear prompt: "Looks like the signal is poor here — are you at the spot with the blue door?" That single escape hatch removes most of the support messages a location app ever receives.

6. The battery budget is a design constraint

Everything above is expensive if you leave GPS on. A useful pattern is to register for location updates only while a hunt is active, and to drop to a slow interval when the player is stationary and speed up when they are moving.

Two things worth measuring rather than guessing: how long a typical hunt session lasts on a mid-range phone, and how much of that is the GPS being left on while the screen is off.

Wrapping up

None of this is exotic, and that is the point. The parts of a location game that feel like game design — how the clues are written, how the camera step feels, whether the next unlock is satisfying — are the parts that are easy to iterate on.

The parts that decide whether people finish a hunt are the boring ones: whether you trust a 35-metre fix when the phone says 40, whether you throw away the stale location from before the tunnel, and whether the error message tells someone what to do next.

If you are building something like this, start with the tolerance of the distance check and the freshness of the fix. They are a few lines of code each, and they remove most of the failure you would otherwise spend weeks chasing.

DEV Community: Sam Ellis