Every flight in a small aircraft starts with a weight and balance calculation, usually done on paper or in a spreadsheet. FeatherWeight is our own iOS app for that job: thirteen aircraft types built in, the CG envelope drawn the way the handbook draws it, and a trim sheet to sign at the end. It runs entirely on the device, with no account and nothing sent anywhere.
Load a small aircraft badly and it will not climb the way the book says, or it will not trim the way the pilot expects. So before every flight someone works out what the aircraft weighs and where its centre of gravity sits: the weight at each station, the moment each one contributes, and the totals checked against the envelope printed in the aircraft’s handbook. Most people do that on paper, or in a spreadsheet they built once and now trust. An instructor and a student do it again for every lesson.
FeatherWeight is our own product rather than client work. The aviation side of it came from a developer on the team who was flying before he was writing software, so the app is built around the way the job is done rather than around the numbers it holds.
What it does:
The CG chart is drawn by hand with SwiftUI’s Canvas rather than by a charting library, so the category zones nest inside one another the way a real chart’s do and the shape of each zone is the limit itself. It holds the 0.75 portrait aspect ratio pilots are used to reading, and it plots take-off and landing as two separate points, because the aircraft has to sit inside the envelope at both.
The calculation engine is a pure, stateless namespace of functions. Weights and arms go in, moments, totals and warnings come out, and nothing is held between calls, so the same load always produces the same sheet. CG limits are interpolated by weight between the points of the envelope rather than treated as constant, which is what the printed chart does and what a fixed forward limit gets wrong at the light end. Every result carries its margins, so the answer is not only whether the load is legal but by how much.
The chain runs ramp weight through the taxi allowance to take-off weight, then take-off weight through the planned burn to landing weight. Four operating categories are modelled, each with its own envelope to be checked against, and thirteen types ship with the app. Ten warnings sit over the result, among them the per-compartment baggage limits and one that fires when a margin falls inside an inch: still inside the envelope, but not by enough to plan around.
Fuel goes in the way the pilot has it, as a quantity in gallons or as an endurance in hours. Burn works the same way, gallons or hours, whichever the flight was planned in. A consumption rate entered for this flight overrides the one stored with the aircraft, so the figure in play is always the most specific one given. Reserves are VFR day, VFR night, or a custom IFR figure. Endurance is recalculated as the tanks move, so pulling fuel back out shows what it costs in time.
The export is a US-Letter PDF laid out as a load control form. The table opens at basic empty weight and runs down through every station, the seats, the baggage areas and the usable fuel, to ramp weight, take-off weight, the burn and the landing weight, each total printed against its placarded limit. Below it the same envelope, re-drawn for paper with both points on it. At the top, a line for the pilot in command to sign. It leaves through the system share sheet, so it goes wherever the phone already sends things.
No account, no sign-up, no network calls, no analytics. Aircraft, loads and settings are kept in UserDefaults on the device, and the privacy manifest declares no collected data because there is none to collect. The whole loading state comes back on the next launch, so a calculation interrupted by a phone call is still there afterwards.
It is free on the App Store, iOS 18 and up, and runs on iPhone and iPad with a layout that spreads out on the larger screen.