Help us ship these features out of Experimental

Three AltosUI features carry an Experimental badge: the AR Recovery HUD, the Recovery Map, and the Flight Report. They are fully built, shipped in the App Store, and in use in the field. The label is not a confession that something is half-finished. It is a promise that the feature is not done changing until people who actually use it in the field say the behavior feels right.

What “Experimental” means here

Every experimental feature in AltosUI went through the same gates as any other feature: spec, build, internal testing, and release. The difference is what happens after the release. A feature stays labeled Experimental until we hear from people using it at real launches that the behavior is right. Feedback is the mechanism. Without it, a feature sits in limbo — technically working, but without the real-world validation that earns it a spot in the main list.

This page exists because silent satisfied users never move a feature to Current. We need to hear from you, even when nothing is broken.

The three features waiting on validation

AR Recovery HUD

Hold up your phone and the AR Recovery HUD overlays your rocket’s bearing, distance, and a world-locked targeting reticle on the camera view. What we want to know: does the reticle stay pinned to the right spot as you pan, tilt, and roll the phone? Is the compass ribbon readable at a glance? Does one of the four color themes work better than the others at your launch site’s lighting?

Recovery Map

The Recovery Map is the walking-map mode on the Recover tab — your position, your rocket’s last reported location, and a colored route line that shortens as you close in. What we want to know: does the auto-zoom feel right as you approach? Is the direction badge in the lower-right (“ahead,” “right 47 degrees,” “nearby”) useful, or is it in the way?

Flight Report

The Flight Report is an on-device post-flight summary generated from a .telem file — performance headlines, phase timeline, motor and aerodynamic metrics, recovery, advisories, altitude chart. Exportable as a paginated PDF. What we want to know: which numbers do you actually look at first? Is the advisory wording right — useful warnings, or noise? Are any fields showing up as “unavailable” when you expected a value?

The three kinds of feedback that move a feature

Pick whichever one fits what you saw:

1. “This works well as-is — don’t change it.” This is a first-class response, not a lesser one. If the feature fits into your launch-day workflow and does what you expected, that is exactly what we need to hear. Silence reads as “no one’s using it yet.”
2. “This mostly works, but here’s what I’d improve.” Concrete suggestions tied to what you were trying to do. Even a single sentence is useful — you don’t have to write a design doc.
3. “This didn’t do what I expected, and here’s what happened.” A plain description of the mismatch between what you thought the feature would do and what it actually did. A screenshot and the flight’s .telem file, when they’re relevant, make it much easier to reproduce.

How to send it

Email altosui@ironsheep.biz. Please name the feature at the top of your message so we can route it to the right follow-up queue. If a specific flight is relevant, attach the .telem file — AltosUI exposes those through the Files app and iTunes Document Sharing.

See the FAQ for more on how experimental features graduate and the rest of the feedback workflow.

Why this matters

Field validation is how AltosUI stays honest about what works. The alternative — promoting a feature out of Experimental because it shipped and nobody complained — would let broken behavior hide behind user silence. A feature that graduates to Current should have earned that badge from people who flew with it, not from a calendar.