starLOG

Every pilot who flies with an iPad ends up in the same position: charts on the screen, and the nav log on a folded sheet of paper wedged beside the thrust levers. The chart app owns the display. The navlog is what gets sacrificed.

starLOG is built for the space that is left.

Designed for the other half of the screen

Most cockpit apps assume they are the only thing you are looking at. starLOG assumes the opposite. It carries three width tiers, not one responsive compromise — a wide layout when it has the screen, a medium one, and a genuinely different compact layout that takes over below 500 points: the size of a Slide Over panel or the narrow side of a Split View.

The compact layout is not the wide one squeezed. It uses its own table schema with its own columns, widths and stacking; the route header collapses to a single line carrying date, flight number, route and position source; aircraft type and registration step out of the way; and each navlog row still packs planned and actual values into 32 to 36 points of height. Every column and every field carries a declared priority, so what drops out as the window narrows is a decision, not an accident.

You keep your charts full size. The navlog stays a working table, not a preview.

Native, on the metal, no compromises

starLOG is written entirely in Swift and SwiftUI across nineteen local Swift packages — no cross-platform runtime, no embedded web view, no JavaScript bridge. That is not a purity argument, it is what makes the rest possible:

• The route map draws itself. Coastlines, graticule, great-circle arcs, ETOPS diversion rings and waypoint labels are rendered directly in a SwiftUI Canvas from a 76 KB bundled vector coastline and an 885-airport gazetteer. No tile server, no download, no cache to warm — it works at FL390 over the Pacific exactly as it works on the ground, and it crosses the antimeridian without a seam.
• A real 3D globe, offline. NASA Blue Marble by day and Black Marble by night, bundled on the device, with a true day/night terminator recomputed every minute — hardware-accelerated on iPad and on the Mac, with no tiles to fetch.
• Position uses the hardware properly. Multi-constellation GNSS through CoreLocation, with a watchdog that recovers the chip when it stalls, geofences around the coming waypoints so tracking survives a force-quit, and a deliberate 1 Hz cadence so neither the tracking engine nor the interface is drowned.
• The link between devices is the hardware link. Encrypted MultipeerConnectivity — peer-to-peer Wi-Fi and Bluetooth — not a cloud round-trip pretending to be a cockpit tool.
• The flight lives on the Lock Screen. A Live Activity carries the next waypoint with its distance and ETA, route progress, current level, the fuel delta against plan and the destination ETA to the Lock Screen and Dynamic Island. A glance costs nothing.
• The interface uses what the OS offers, including liquid glass on the versions that have it, with a clean material fallback on the ones that do not.

Everything happens on the device. There is no backend, no telemetry hop, no analytics SDK, no request that has to succeed for the app to be useful — and nothing about your flight leaves your hands.

Adaptive to whatever your flight planning system emits

The canonical format is ARINC 633 — the industry flight-plan interchange standard — and starLOG reads it natively, in both the current namespaced version 4 and the older dialect, transcoding one into the other field-exactly, ETOPS, re-clearance and step climbs included.

But airlines do not all emit clean 633, so starLOG meets the ones that do not:

• PFRShared and EFF containers import directly — the archive is opened, its manifest checksums verified, the flight-plan document located in the catalogue and decoded, all inside the app.
• Operator formats arrive as transcoding packages — a self-contained, installable description of one airline’s OFP layout: how to find its tables, how to map them, which figures to compute, which limits to check, and even its own form layouts, so the fuel and weight pages match that operator’s paper form.
• A package contains no executable code. Data and declarations only — the installer refuses scripts, binaries, nested archives and symlinks outright. A third-party package can transform your flight plan; it can never run on your device.
• OFP PDFs go through the companion open-source skill, prep-633, which turns a printed flight plan into validated 633 XML.
• Files are identified by their content, not their extension, and a genuinely ambiguous file simply asks you which format it is.

No ground infrastructure. No airline integration project. No dispatcher-side deployment. If your operator can hand you a flight plan file, starLOG can fly it — and if it cannot yet, a package makes it so without touching the app.

Colour tells you where every number came from

This is the detail line pilots notice first. Every value on screen is coloured by its origin, and the convention never bends:

• Cyan — you typed it
• Green — the app computed it from something else on the form
• Magenta — GPS, the aircraft or the onboard feed set it automatically
• Yellow — the other device pushed it over the peer link

Glance at a cell and you know whether to trust it, check it, or own it. No badges, no legends, no tapping to find out.

Built around how the flight actually goes

• Waypoints tick themselves. The engine tracks progress along the route, not distance to a point — so a departure that climbs away from the routing before turning on course does not cascade the pointer down the flight plan. The time it writes is the closest-pass instant, interpolated, the same moment an FMS would log. In magenta, so you can see it was not you.
• ETOPS and re-clearance are first-class. EEP, EXP and equal-time points on the map and in the table, diversion rings around the suitable airports, alternates as amber diamonds — and for a reduced-contingency flight, the decision point is resolved from the plan, the required fuel computed there, and the continue-or-divert margin shown against what you actually have.
• Two devices, one navlog. Load the same flight plan on an iPhone and an iPad and they pair on the flight’s identity with no action at all — then stay in step, and a device that joins late is brought up to date without ever overwriting fresher data.
• A new flight plan mid-flight does not ambush you. Importing a newer revision while airborne archives it and raises a badge; adopting it is a deliberate act, never a silent swap under your fingers.
• The flight record is part of the same file. Block times, take-off, landing, night time and crew — plus the tech log: de-icing, oil, fueling events, tank distribution and fuel reconciliation — live alongside the navlog for the same flight, filled from what you already entered rather than typed twice.
• Fuel and weight planning reconcile planned against actual, with every derived figure computed and coloured as such.

Yours to rearrange

Every page layout and every table in starLOG is described in XML, and on first launch those templates are seeded into a folder you can open in the Files app on the iPad or in Finder on a Mac. Reorder the navlog columns. Retitle a card. Hide a section you never use. Change the crew-code length to match your company’s format. Edit a formula. The app picks up your version — no update, no recompilation, no support ticket, no developer involved.

Most cockpit software decides for you what matters. This one lets you say so.

Designed by a pilot, for pilots

starLOG is built by a working Airbus captain, in the cockpit it is meant for. That shows up in choices that would never survive a spec review:

Near-black surfaces instead of pure black, and off-white text instead of pure white, because the pure pair vibrates under night cockpit lighting. Cyan as the primary accent because it holds up in sunlight on a ramp where pink and purple do not. Every number in monospace and right-aligned, because a column of times you can scan is worth more than a column that looks nice. Information density over whitespace, because a pilot scanning a navlog at FL390 wants more rows visible, not more padding. No animation on critical data — ETA, fuel and ETOPS status snap to value rather than easing into it. Amber for “worse than planned” and red kept for the genuinely critical only, because pilots stop seeing a red that is used decoratively. Tank distribution laid out as the six positions on the paper form, because that is the form you are copying from.

And the multi-source position model exists because of a real flight: on a Bangkok–Paris sector, GPS jamming took the certified aircraft position out entirely. An iPad’s multi-constellation receiver held it through the cockpit windows, and the cabin’s own position feed held it the whole way. That is not a feature idea from a roadmap workshop — and neither was the departure-tracking rewrite, which came out of watching the pointer misbehave on a real take-off.

Who it is for

The large EFB suites are sold to airlines as fleet contracts. That model structurally cannot serve the pilot who wants their own copy. starLOG is built for:

• Freelance and contract pilots who change operators and cannot rely on a company deployment
• Small operators — business aviation, cargo, regional, ACMI, charter — with no EFB integration budget
• Line pilots who want a personal backup to the company EFB, independent of it
• Ferry, instructor and complex-GA pilots working from an OFP without a fleet system behind them

What starLOG is not

It is a supplementary, personal tool. It is not a certified EFB application, not a primary means of navigation, not a flight planning system, and not an airline-grade regulatory journey log — it keeps a personal flight record. It consumes flight plans; it never makes them. The pilot in command confirms everything. Its use in an operational context is subject to your airline’s EFB policy and regulatory approval.

---

starLOG is in active development. If you fly with a paper navlog beside your charts and would rather not, get in touch about the beta.