Why this app exists
The question is not what the number is, but where it comes from.
Most flight computers either dropped weight and balance or never had it. Yet burning fuel moves the centre of gravity along a curve, not a straight line: checking only the start and the end of the flight can miss an excursion in the middle, which is precisely what the standards ask about, during all phases of flight.
Second decision: every result unfolds into a full derivation. Mental rules of thumb are useful and officially encouraged, but no app shows how far the shortcut actually lands from the exact answer. Isogonic shows the gap.
Third decision, the expensive one: correctness is the product. Every case in the regression suite encodes a calculation error that a real competing app shipped and that a real pilot wrote a review about. A pilot who finds an error on the ground stops trusting the app in the air.
The engineering challenges
An absurd result, printed as a fact.
Atmospheric constants, derived and never transcribed. The decimal forms published everywhere are rounded to different numbers of digits depending on the source, which makes them mutually inconsistent from about the fifth decimal onwards. One of the most widely repeated values on the web is simply wrong. The constants are therefore derived in code rather than copied, and a test checks that standard conditions at sea level return exactly zero under three different formulations. That is precisely what a competing app gets wrong, with reviews reporting a non-zero result in that case.
The bug that displayed a density altitude of minus one hundred and seventy-six thousand feet. The selector was on one pressure unit, the value entered was in the other. The arithmetic was correct, the input was absurd, and the result was printed in very large type as an established fact. Every field now declares its range, deliberately wide so nothing legitimate is refused, with a message that names the likely mistake instead of saying "invalid value".
Two App Review rejections for crashing. In a release build, any unhandled JavaScript error is fatal and the process aborts: that asymmetry with development mode is exactly why an app can pass every test on the developer's machine and still be rejected for crashing. An error boundary was added per screen and one at the root. The drawing code also had to be hardened, because a non-numeric value in plot data throws nothing at all: it reaches the vector layer and brings down the native side, where no boundary can catch anything.
The root cause of the second rejection, and what it taught about tests. A memoised calculation depended only on the entered values. But changing aircraft changes the list of fields, not just their contents: one model has two baggage compartments, another has one, and rendering died on a missing key. The test written afterwards records every render rather than only the settled state, because a first version that checked only the final state passed happily against the broken code.
Balance computed in moment space. As fuel burns, the centre of gravity traces a straight segment in weight-moment space but a hyperbola in weight-CG space. The whole engine therefore works in moments, where the burn is a simple segment and the containment test against the envelope becomes exact rather than approximate.
Holds simulated step by step rather than solved. The model is deliberately literal: fly the aircraft through the pattern in small time steps, adding the wind vector at each step. That reproduces the real distortion, including the drift accumulated during the turns, with no special cases and nothing that can be subtly wrong.
Capmedia Digital