--- title: "How we built direction finding in Rogr: UWB, GPS, and a frozen arrow" description: "Building Rogr's Find feature meant debugging UWB readings that froze at 1.3 metres, then discovering that iOS suspends ranging the moment the other app goes to the background." date: "2026-10-28" app: rogr kind: build readingTime: "6 min read" image: "/img/build/rogr/location-permission.jpg" imageAlt: "Rogr's location permission prompt explaining why the app needs location access for GPS finding" --- Rogr's Find feature points an arrow at a crew member at close range and switches to a GPS compass at longer distances. Both run directly between the phones — no server, no internet, no account. Building it took two rounds of debugging, the first involving UWB readings that froze and then snapped, and the second discovering an iOS constraint that the documentation doesn't prominently advertise. ## The chip discovery The question that started the Find feature came in on the first day of the build: > is there any chip on the phone to identify where the phones are like how we find airtags with direction The answer was yes. iPhones have an Ultra Wideband chip. iPhone 11 and later — excluding SE models — can run Precision Finding the way you find an AirTag. A plan followed: Walk-E (the app's name at that point) would get a Find screen with a directional arrow. The first implementation came together quickly. The basics — requesting a session, getting distance and direction from the framework, drawing an arrow — are not complicated. What turned out to be complicated was making the arrow behave correctly. ## The freeze The first version of Find worked in the sense that numbers appeared and the arrow moved. But the numbers were wrong. The first debugging prompt came in while we were still on day one: > check logs its getting stuck , i think something we are doing wrong . On-device logs showed where it was freezing. The second prompt made the failure mode specific: > it stuck at 1.3 meters away then suddenly says right here etc. The symptom was characteristic: a frozen reading at one distance, then a jump straight to "right here." The direction was also off: > the arrow is also not working correctly These three prompts came in close together. The fix involved switching to the native direction the framework provides, adding a smoothing pass so readings don't snap between values, and removing the frozen-reading behaviour. After those three changes, the arrow tracked correctly. The debugging required running on real hardware. The UWB ranging chip doesn't exist in Xcode's simulator, so every iteration needed a device build and two iPhones in the same room. This is one of the places where AI-assisted development runs into the same wall as any other: if the hardware isn't there, neither is the test. ## Research After the specific failure prompts, a broader one came in: > do some research on how to exactly make this work correctly This produced more context than the narrower prompts had. iOS documentation for UWB ranging covers the framework's API, but the practical guidance for direction accuracy is scattered: which direction reference to use, how much smoothing is appropriate at different distances, how to handle the frames where the chip loses line of sight. The research pass produced a more robust implementation that held up across distances and device orientations. ![Find, an Ultra Wideband compass pointing toward a crewmate](/img/build/rogr/find-uwb-compass.jpg) *Find, with the UWB arrow pointing toward a crewmate.* ## The iOS background constraint The arrow was working. Then the next question came in: > It's not possible to find if other phone app is not open ? This is the iOS constraint that isn't obvious until you hit it. iOS suspends UWB ranging when the other device's app moves to the background. The session is paused, not terminated — if the other person reopens the app, ranging resumes — but the practical effect while their screen is locked is the same: the arrow stops updating. The response explained the constraint and proposed two workarounds: a nudge notification to bring the other app to the foreground, and a locator sound so the phone could make noise while it's in someone's pocket. > Yes let's add both these features Both were built. The nudge notification prompts the other person to reopen Rogr. The locator sound — a repeating tone — means you can find a phone by ear if it's within audio range. The locator sound has a practical use beyond the background constraint: if a phone is buried at the bottom of a bag, you can trigger the sound and follow your ears. ## GPS, and why it needs location UWB works at close range. At greater distances, Rogr switches to GPS: you get a compass heading and distance from the other person's coordinates. The cover image of this post is the location permission prompt that GPS requires. Asking for location permission is a step where the reason matters more than usual. The system prompt is generic, so Rogr's permission screen explains what the location data is used for: navigating to a crew member when UWB range runs out. Location data goes directly to the crew phones and nowhere else. iPhones with a UWB chip don't need GPS until the crew member is further away. On SE models, which don't have the UWB chip, GPS-based finding — the compass heading and distance — is the only mode available. Any iPhone on iOS 17 or later can run Rogr. The directional arrow at close range requires iPhone 11 or later, excluding SE. ## What the feature does now Find is available to any phone in a crew. Talking, crews, finding and SOS are all free. Rogr Pro adds three radio shells and two sound packs for $4.99 once. Rogr is coming soon to the App Store. More at [rogr.xeve.io](https://rogr.xeve.io).