Geocode destinations on-device with MapKit and record the result as an effect

Decision

Geocode on the device with MapKit. The server stores a destination's location as the raw name it was given, with coordinates, timezone, country code and locality left empty. When the app shows a trip, it geocodes every destination that has no coordinates yet and sends the result to the server through a mutation. The server records the result as a system modification carrying one enrichment effect, so geocoded data replays and syncs like every other change to the trip.

Why

Destinations need coordinates for maps and distances and a timezone for scheduling across zones. The effect that adds a destination carries only its name, so something has to resolve that name to a place.

Backend geocoding means a third-party API with per-call cost, rate limits and a vendor to evaluate. MapKit on the device costs us nothing and returns the timezone and locality alongside the coordinates. The only client is Apple-platform, so the device was already the cheapest place with a geocoder.

Rejected alternatives

• A third-party geocoding API called from the server, such as Google or Mapbox. It adds cost, rate limits and a vendor for data the device produces for free.
• Apple's Maps Server API called from the server. It is free within a daily quota but needs server-side credentials and plumbing we otherwise don't have. It is the first option to evaluate if a web client makes server-side geocoding necessary.

Consequences

We pay nothing per geocode. A destination stays ungeocoded until an Apple client opens its trip, so any server-side consumer that needs coordinates has to tolerate their absence. A web client would need its own geocoding path, most likely the Maps Server API.