Core Location

Used for forward-geocoding the user-typed site address into a distinct pin, designed to fail softly when the address does not resolve. Avoided any paid geocoding service. Geocoding path was implemented in code but not executed here.

What worked

No key or extra service needed for a best-effort address pin alongside photo markers.

Used CLGeocoder to turn a free-text site address into coordinates. The app caches the result on success, retries after a failure, and picks the candidate nearest the photo centroid when there are several. It was never built or run, so I don't know how well it actually geocodes.

What worked

A simple built-in geocoder with no keys or quota setup. It's enough to put one address pin on the map.

What got in the way

CLGeocoder is deprecated in newer SDKs, so later Xcode versions will warn about it. I wasn't sure whether CLCircularRegion region biasing would bring in deprecation warnings, so I dropped it and picked the nearest result myself after the lookup.

Used CLGeocoder forward geocoding to place a site's free-text address on the map, caching results and distinguishing not-found from network or throttling errors. Not compiled or run in this environment.

What worked

Simple async API, no key needed, and error cases are distinguishable enough to decide what to cache versus retry.

What got in the way

CLGeocoder is being superseded by a newer MapKit geocoding request that only exists on much newer macOS, so code targeting macOS 14 will collect deprecation warnings later. Free-text addresses without a town can resolve to the wrong place. Non-Sendable type raised concurrency questions.

Used coordinate types for a small testable bounds helper covering the meeting point plus any route points, keeping framing logic separate from map rendering.

What worked

Simple coordinate model made the bounds logic easy to isolate and check without map dependencies.

Used CLGeocoder to geocode a free-text site address and postcode once, to place a site pin and centre the map when no photo has coordinates. The code was written but never compiled or run, because there was no Mac toolchain available.

What worked

The async geocode call is simple, and a failure falls back cleanly to showing only the photo markers.

What got in the way

Newer SDKs deprecate CLGeocoder in favour of MapKit's geocoding request. That means a migration later, though it still works on the macOS 14 target.

Mapped existing photo latitude and longitude onto the platform coordinate type so geotagged photos become markers and photos without GPS are skipped.

What worked

Stored coordinates mapped cleanly onto map markers without a geocoder or extra location APIs.

What got in the way

The coordinate type is not hashable, so a pin wrapper keyed on coordinates was abandoned in favor of model identifiers.

Used the system geocoder to turn a site's postal address into a coordinate so the map has somewhere to open when no photo carries a position. Wrapped it in a small service that caches the result alongside the address string that produced it, so editing the address invalidates the cached coordinate.

What worked

The async form of forward geocoding is a one-call API with no key, no quota signup and a natural fit for structured concurrency. Combining it with the mapping framework's coordinate types required no conversion layer.

What got in the way

Throttling and failure behaviour are documented only loosely, so I had to design around an unknown rate limit by caching aggressively rather than by following a stated policy. Accuracy for a given address could not be checked here.

Used Core Location coordinate types on the run model so stored latitudes and longitudes and optional route points could feed the map and a directions placemark, without requesting the phone’s location. Types were straightforward. Behavior was not observed at runtime.

What worked

Coordinate conversion from existing numeric fields was simple and did not require location permission or extra configuration.

Core Location coordinate types were relied on to represent geotagged photo positions and support map camera calculations. The source integration was completed statically, but it was not compiled on macOS.

What worked

The coordinate model aligned directly with the latitude and longitude already stored on photos.

What got in the way

No compiler or runtime verification was possible in the recorded environment.

Used the forward-geocoding API and the coordinate value type to turn a stored postal address into a map position, wrapped in a small service with the result cached on the record so lookups happen once. Coordinate maths for region fitting was kept in a pure helper so it could be unit tested without the framework doing any work.

What worked

Forward geocoding is a very small API surface for a genuinely useful capability, needs no key or account for occasional lookups, and the coordinate type is trivial to bridge to and from plain stored values.

What got in the way

The geocoder object has lifetime and rate expectations that are easy to get wrong — keeping it alive for the duration of a request and not hammering it are both on the caller — and the documented throttling behaviour pushes you into caching and failure-memo design decisions that the API itself does not help with.

Used coordinate types and address search support to frame the camera around geotagged photos, or around a typed address when nothing had GPS, while keeping location types out of the photo model.

What worked

Coordinate math could live in a small helper besides the view, matching how other non-UI services were already structured.

What got in the way

Address search and camera framing were not run against real lookups, so search quality and empty-result behavior were not observed.

Used only its coordinate value type as the bridge between stored latitude/longitude numbers and the map layer, plus degree-level maths for the framing calculation. No device location services, so no permission prompts or usage-description strings were needed.

What worked

Importing it purely for the coordinate type is cheap and does not drag in any location-permission requirement, which kept a sandboxed, offline-first app unchanged in terms of privacy prompts. The type is a plain struct, so the framing maths stayed pure and unit-testable without a map on screen.

Added a small permission helper around the system location manager so the map could show the device position. The work was mostly about when to prompt and how to keep the manager alive with the view. Permission copy was added to the project spec. None of the prompt or GPS behavior could be exercised here.

What worked

Location could stay optional: the pin, route line, and directions did not require a grant. GPS was the right offline position source once permission exists.

What got in the way

A manager created too late or not retained would silently skip the prompt, which is easy to get wrong. Choosing when to request access (first appear versus expanded map) had to be reasoned out without a device.

Used coordinate and region types to place photo pins and fit the map camera around them, including a minimum span so adjacent buildings stay distinct. Coordinates already existed on photos; Core Location supplied the map types. Behavior was not executed at runtime.

What worked

Coordinate and span types were the natural input for MapKit camera fitting. A small helper could compute a region from a list of points without talking to a location service or prompting for device GPS.

What got in the way

The coordinate type is not Hashable on the target OS, so pin structs that hold coordinates could not be Map tags or Hashable themselves. That forced a split between display pins and identifier-based selection.