DEV Community: Rene Larsen

Build map guidance that follows the user without blocking pinch-to-zoom

Rene Larsen — Sat, 08 Aug 2026 18:23:17 +0000

A navigation map should help the user move through the world, not fight every gesture they make.

I recently hit a deceptively simple bug while building field guidance in a React Native / Expo app: the route rendered correctly and the camera followed the current position, but users could not meaningfully zoom or pan while walking. They could pinch the map, but the next location update snapped the camera back to a fixed zoom.

The map looked active. The experience felt broken.

The cause: two camera owners

The implementation combined two useful features:

followsUserLocation={true} on the native map.
animateCamera(...) after every location update, using a fixed walking zoom and pitch.

Each feature was reasonable on its own. Together, they gave the camera two automatic owners and the user none.

A pinch gesture changed the zoom for a fraction of a second. Then a GPS update arrived and our effect applied the navigation camera again. On iOS, native user-follow behavior added another layer of camera control.

A better model: follow mode and explore mode

The fix was not to stop navigation. Route progress, distance, bearing, breadcrumb recording and off-route detection should all continue regardless of what the user does with the map.

Only the camera behavior should change.

We now keep a small piece of local UI state:

const [cameraFollowing, setCameraFollowing] = useState(navigationActive);

useEffect(() => {
  if (!navigationActive || !cameraFollowing || bearing == null) return;

  mapRef.current?.animateCamera(
    walkingCamera(currentCoordinate, bearing),
    { duration: 480 },
  );
}, [currentCoordinate, bearing, navigationActive, cameraFollowing]);

The native follow prop uses the same state:

<MapView
  showsUserLocation
  followsUserLocation={navigationActive && cameraFollowing}
  onTouchStart={() => {
    if (navigationActive) setCameraFollowing(false);
  }}
/>

As soon as the user touches the map, the camera enters explore mode. Pinch, pan and rotation work normally. The active route and navigation calculations continue in the background.

A large location button restores follow mode:

function recenterAndFollow() {
  setCameraFollowing(true);
  mapRef.current?.animateCamera(
    walkingCamera(currentCoordinate, bearing),
    { duration: 420 },
  );
}

This creates a familiar contract:

start guidance: follow automatically;
touch the map: inspect freely;
tap the location arrow: resume following;
stop guidance: return to the ordinary overview map.

Why onTouchStart?

react-native-maps exposes gesture details on region-change events, but isGesture is not equally available across providers. Relying only on that detail can produce different behavior between Google Maps and Apple Maps.

For this field use case, a touch is a good expression of intent: the user wants control of the map. The action is reversible with one obvious button.

Keep navigation state separate from presentation state

The most important architectural lesson is that camera state is not navigation state.

These should continue while the camera is detached:

current-position updates;
remaining route distance;
bearing and direction;
off-route detection;
route recalculation;
local breadcrumb recording.

Only camera animations are suspended. That separation prevents a UI gesture from accidentally stopping the trip or discarding route progress.

Outdoor UX details that matter

Field navigation is used with cold fingers, sunlight, rain and intermittent attention. A few details made the interaction clearer:

a 52-point recenter button with a generous hit area;
high-contrast route colors;
route status outside the map, so it is still readable while zooming;
no hidden gesture required to resume following;
tests that assert both map surfaces use the same follow/explore contract.

We applied this pattern to both live trip guidance and navigation back to a privately saved place. Consistency matters: users should not have to learn two camera behaviors inside the same app.

The product context

I found this issue while developing Mycoverse, an iPhone app for planning mushroom trips with weather, habitat and seasonal signals, plus a private field journal. Exact saved places are private by default. The app does not identify mushrooms, guarantee a find or provide food-safety advice.

The bug came from real field feedback, which is exactly the kind of feedback a simulator rarely produces. If your app guides people outdoors, test it while walking, locking the phone, putting it in a pocket, resuming it and trying to inspect the map mid-route. That is where the real interface begins.

What I learned building a privacy-first mushroom trip planner with open data

Rene Larsen — Thu, 06 Aug 2026 15:42:16 +0000

Most mushroom apps focus on the moment after someone has found a specimen. I wanted to build for the harder part before that moment: planning a useful field trip without turning private mushroom locations into a public heat map.

The result is Mycoverse, an Expo/React Native iPhone app that combines weather, habitat, terrain, season and a private field journal. Building it exposed a few product and engineering lessons that apply to many location-aware apps.

1. A model score is not the product

It is easy to calculate a number from rain, temperature, soil signals and forest data. It is much harder to explain what that number actually means.

An early version showed scores such as 99/100. Testers correctly asked: 99 for what? The precision implied certainty that the underlying data did not support.

The current UI leads with qualitative conditions and keeps technical scores in the details. It also exposes missing signals instead of silently treating them as zero. This makes the app less flashy, but much more honest.

The principle I now use is:

A model should help a person make a decision, not perform confidence theater.

2. Exact locations need a different privacy model

A mushroom patch is not an ordinary social check-in. A productive place can matter for years, and publishing precise coordinates can damage both trust and the place itself.

Mycoverse therefore stores findings and exact positions as private by default. Community activity never requires exposing the coordinate behind a photo. Sharing must be deliberate, and public discovery views should not accidentally reveal location metadata.

That decision affects architecture as much as copy. Location data, photos, sharing state and moderation need separate boundaries so a future social feature cannot casually inherit access to private coordinates.

3. Graceful degradation matters outdoors

Field apps run where connectivity is unreliable. A successful request on a desk is not enough.

The app now supports saved field briefs, local trip state and private finding data that can survive poor connectivity. Weather and habitat information shows freshness and data quality, rather than pretending a stale response is live.

A useful offline state is not just a loading spinner with nicer wording. It must preserve the next action the user needs in the field.

4. Map routing is a safety feature

A generic walking route can be technically valid and still be a bad field route. During physical testing, a route crossed private gardens because the underlying map data described a path.

We added stricter routing logic, public-access checks and clear fallback behavior. The app distinguishes between a calculated trail route and a direct compass bearing, and it explains which one is being shown.

This is still an imperfect global-data problem, but the product should never disguise that uncertainty.

5. Global taxonomy and local language are separate problems

Scientific names provide a stable backbone, but foragers search in their own language. Mycoverse uses global taxonomy for classification while prioritizing regional common names where they are available.

The catalogue can show licensed images, synonyms and sources, but it deliberately avoids presenting a search result or manual observation key as a confirmed identification. Planning a trip and approving food safety are different jobs.

6. Physical field testing beats a perfect simulator

Some of the most valuable feedback has been simple:

the trip disappeared when the phone was locked
the route existed, but the map did not behave like navigation
a saved finding needed a direct link back to the map
a marker needed the mushroom name or illustration, not just a pin
map logic that worked in Norway had to degrade correctly in Poland, Sweden and the US

None of these issues looked dramatic in unit tests. Together they determined whether the product felt trustworthy outdoors.

What Mycoverse does now

The current iPhone app includes seven-day trip planning, qualitative SoppRadar conditions, map-based candidate areas with several relevant species, seasonal watchlists, private findings with photos, offline field briefs, routes back to saved places and a global field handbook.

It is a planning and documentation tool. It does not guarantee a find, identify a mushroom with certainty or approve anything as safe to eat.

If you build location-aware or outdoor software, I would love to hear how you test unreliable data, offline state and privacy in real-world use.

Mycoverse on the App Store: https://apps.apple.com/app/mycoverse/id6793912021