Where the map looks
After the first drives Dad said what he wanted from the map in one line, written into FollowCamera's doc comment: "무조건 차 또는 걷는 사람이 정면을 바라보는 식으로", always as if the car or the walker is looking straight ahead, with Kakao Navi as the reference. Invariant 10 turns that into rules. The map is flat by default and 3D is one button. It is heading-up. Dad sits low on the screen so the way ahead fills it. And it is never north by default: the old code fell back to north whenever the GPS course went quiet, so the map spun at every red light.
FollowCamera is a pure value in PathfinderKit, so all of this is tested on a Mac. It answers two questions: which way should the map face, and where should the camera sit.
Course or compass
A GPS course is derived from movement. It means something only while you are moving, and at a crawl it is mostly noise. A car stopped at a light has no course; a walker strolling has a poor one. So FollowCamera.heading first asks whether you are moving: at least 2.5 m/s when driving, 1.8 m/s when walking. If you are, and there is a course, the map faces the course.
If not, the two modes part ways. Driving asks the route first (the direction of the road at your progress), then the previous heading, and only then the compass. Walking asks the compass first, then the route, then the previous heading. The doc comment gives the reason in eight words: a person turns on the spot, and the phone knows. A car cannot face sideways on a road. A person at a corner turns ninety degrees without moving a metre, and only the magnetometer sees it.
One number deserves a second look. Wikipedia's figure for preferred walking speed is 1.10 to 1.65 m/s, and the threshold is 1.8. That means an ordinary stroll stays on the compass, and only a brisk pace hands the map to the course. That is the intent: the kit's test is literally named walkingTurnsWithTheCompassUntilThePaceIsBrisk, and its first assertion is a walker at 1.0 m/s with a course of 200° and a compass of 30°, who gets 30°.
Google reached the same conclusion on its own. In the Navigation SDK's GMSNavigationTravelMode, driving bases the user's course on the direction of movement, while walking bases it on the device's compass heading. When Google's map guides a walk, Pathfinder sets session.travelMode to .walking in route(to:), so by Google's own documentation the course it shows comes from the compass too.
Where the compass comes from
The app's LocationFeed starts startUpdatingHeading whenever heading is available, with headingFilter = 3, so a twitch under three degrees is not an update. It drops readings whose headingAccuracy is negative (iOS's way of saying invalid), and takes trueHeading when it is valid, magneticHeading otherwise. Every compass reading calls compassTurned(), which re-places the map only when the last fix is under thirty seconds old and slower than 2.5 m/s. Moving faster than that, the course turns the map and the compass is ignored.
Dad's arrow is the app's own drawing, not the system's blue dot: it rotates by the puck heading minus the map heading, so on a heading-up map it always points up. On a walk it is green and smaller (30 points against 38), and while the trip is on route it sits on the route's matched point.
Where the camera sits
FollowCamera.make sets the distance. Driving zooms out with speed, from 600 m to 1,800 m. Walking stays at 350 m whatever the pace, because a walker needs the next corner and the one after it, not the next interchange. The camera's centre is pushed ahead of Dad along the heading by 0.12 of the distance on a flat map (0.05 in 3D), which puts him about 22% below the centre, a value measured in the simulator to land near Kakao Navi's spot. Pitch is 0 flat and 55° in 3D.
Kakao's map needed one more rule for walking. Its follow camera is animated, and the first version queued each animation behind the last. A walk's compass turns several times a second, so a queue of 0.7-second moves fell further and further behind Dad. Now each move replaces the one in flight. On a walk Kakao also keeps the street-level zoom; only a fast car steps out a level.
The walking map's controls
The walking map shows no traffic and no camera pins. While a walk is guided, the round buttons on the right are the same set a drive gets: Turns ahead (the list of remaining maneuvers), Show the whole route (toggles the overview and back to following), the 3D toggle, and Recenter, which appears only after you pan away. On Apple's map the compass and the scale sit under Pathfinder's top bar: the map runs under the status bar, and on a heading-up map MapKit had put its compass over the battery. The 3D button reads "3D" in every language now, because "Tilt" in Korean, "기울기", did not fit the circle and showed as "기…" (#401).
A walk stays a walk
The heading rules depend on the trip knowing it is a walk, and the one place that knowledge used to leak was the reroute. A walk that left its path once came back as a driving route, and the session went on guiding a pedestrian with car distances and cameras. The reroute now asks the provider with the route's own mode, never the settings default, and refuses an answer from another provider or in another mode. If no route comes, Pippa says "길을 못 찾았어" once, and the session asks again every fifteen seconds while you are still off the route. A Google walk is rerouted by Google's engine inside its walking session.