Why one map is not enough
Pathfinder started with one map. Apple Maps was Dad's first choice: no key, no cost, native CarPlay, and his own driving had found Apple's routing in Korea about as good as the domestic maps. Apple is still the canonical child, the shape every other provider is measured against.
Then the world got bigger. Korea has its own map stack, and Dad wanted it at home. A trip to Spain was coming, and abroad the strongest stack is Google's. So the app now carries three, each a whole provider: its own map, its own search, its own routes, moving together.
| Region | Its own stack | Beside it |
|---|---|---|
| Korea | Kakao: Kakao's map drawn on the phone with its native key; search, routes and travel times through cwkPippa's maps door, where the REST key lives; guided by Pathfinder's own engine | Apple, guided by Pathfinder's engine |
| Abroad | Google: Maps SDK and Navigation SDK on the phone; Google finds, draws and guides its own routes, and Pathfinder follows its turn feed | Apple, guided by Pathfinder's engine |
What a stack rendered stays with it: a search's result list and a route's line and words are never drawn or guided by another provider. A destination is different. A place Dad saved, one Pippa handed over, a pin he dropped is just a name and a coordinate, and every stack routes to it. (Until that rule existed, Kakao refused Dad's own saved Home because Apple had found it.) Track 2 takes the adapter apart; this lesson is about choosing between them and the search problems that forced the choice.
Choosing a stack per region
The region comes first. MapRegion.near asks SouthKorea.contains, which is a hint, never a border: a plain box around the peninsula would swallow Tsushima and northern Kyushu, and a trip to Fukuoka would open on Kakao's empty map. So the box is cut south of Busan where the strait narrows, and small boxes add Ulleungdo and Dokdo. Dad can also set the region by hand: automatic, Korea or overseas.
Then the stack. Until Dad picks one, a region opens on its own map only when that map's key is actually on the phone, and on Apple otherwise. So the default never opens on a map the phone has no key for. Once he picks, the pick is kept as it is, whatever keys come and go: his choice outranks the app's guess.
When every Hangul search said "not found"
The first TestFlight test found a hole in the canonical child. On Dad's phone, on-device MapKit answered every Hangul query with MKErrorDomain 4 (GEOError -8), while English queries worked. The data was there: Apple's Maps Server API found the same places. So since build 3, a search on Apple's stack asks Pippa's Apple Maps door first, whenever Dad's PIN is on the phone and nothing is being simulated. An empty or failed answer falls through to MapKit on the device. 백석역 came back on the first try. Abbreviations are still a gap ("한국외대" found nothing), which is part of why Korea also got its own stack.
There is a quieter fix inside the Apple child: MapKit's placemarkNotFound is now an answer, an empty list, not a failure. "Nothing here" and "the search broke" deserve different words on the screen.
Search near Dad
Then the results came back from the wrong continent. Sending Dad's position as a lone search location barely steers the answer: "호수공원" asked in Ilsan, home of the city's famous Lake Park, answered a park in Laos. "Hospital" near Ilsan answered one 9,614 km away; "병원", a village 154 km away; "편의점" by Kyoto Station, a shop in Laos (todo #300).
The fix asks twice. First with Dad's region as a hint, which keeps a far name far: ask for 부산역 and you want Busan, not something nearby with a similar name. If nothing comes back within 100 km, the generic word was read as a far place, so the same region is asked again as a fence (MapKit's regionPriority = .required, iOS 18 and later). The two answers merge: a far place in Dad's own country first, then the nearby places nearest first, then far places abroad. cwkPippa's search_near applies the same rule on the server's side of the door, so both paths answer alike.
CarPlay: written, not driven
Be precise about this one. The CarPlay scene exists in source: a scene delegate with a map template, Search and My Places buttons, an End button, and the same app model the phone uses, so the phone and the car would show one trip. It is not a working feature. The app's default signing carries no entitlements at all (the build setting is empty, with a comment calling CarPlay future scaffolding); the signing profile on hand lacks Apple's CarPlay maps entitlement; and Dad's present car does not support CarPlay anyway. No connection to a car, real or simulated, has been verified. Dad called it future readiness, and that is the honest name for it.