What technical structure would let the app demonstrate an honest, accessible airport journey now, while leaving live data, routes and optional devices conditional on real access and testing?
This page is technical research before a claim of implementation. As of 20 October 2026 the project contains Week 18 sketches, static SVG/HTML app studies, an eight-screen board and a written prototype build brief. It does not contain a buildable Swift/iOS project or evidence that a participant has used the current app. The proposed first coded scenario is a fictional BA256 gate change, B12→A04, within a navigable wider journey. The whole phone journey must work if there is no account, airport feed, wearable, headphones or accepted support.
SwiftUI is a reasonable first route because it provides native layout, text, controls and appearance behaviour. NavigationStack can represent a journey view and subordinate steps. Xcode previews can accelerate visual checks, but a preview is not evidence that an interaction works on a device. A native build also gives direct access to notification, accessibility and optional Core Bluetooth APIs. These are feasibility reasons, not proof that SwiftUI is the only possible stack.
The static design artboards should become requirements, not pixel-perfect screenshots. Fixed phone frames, artificial status bars, tiny footnotes and positioned characters may break with Dynamic Type or a different iPhone. I would start with semantic components—gate fact panel, stage card, next-action button, support choice, status label—and let the layout reflow. The mascot is a separate decorative layer and must never own a gate fact or critical control.
Sketch 1 — System ecosystem
The early ecosystem sketch shows which parts of the concept might communicate. It is a research diagram, not an implemented architecture.
A prototype should distinguish the traveller’s journey state from a visual screen. Suggested model groups are:
sample, live, stale and unavailable states. A missing field must display “Not available” rather than an invented gate.Apple’s SwiftUI model-data guidance supports keeping one source of truth for mutable app state. This matters because dismissing support must not reset the gate or lose a route step. It also allows A04 and the old B12 label to update together when an event arrives. I would keep content and source labels in the model rather than scattering them as hard-coded strings across multiple views.
The key state transition is new event → update journey facts → offer optional support. Support never interrupts before the gate fact is available. “Not now” records dismissal for that event and returns to a useful journey view. “Pause,” “change support” and “stop” are explicit states, not a cosmetic button. I would test these transitions with automated logic checks later, but none has been run yet.
The project does not have a verified free UK-wide passenger gate-change API. The Heathrow Developer Portal advertises near-real-time airport information, but public material does not establish the access, cost, coverage or permissible prototype use this project needs. OpenSky supplies aircraft-state data; it is not a passenger gate feed, and its live-product terms need attention. Neither source justifies labelling the fictional B12→A04 change “live.”
I would create a FlightDataProvider interface with a sample adapter first. It returns BA256, a sample update and a timestamp/source value. A later authorised provider adapter can map real data into the same model, but only after checking: gate fields, update frequency, UK airport coverage, price, permission to redistribute the data, outage behaviour and latency. Provider keys should not be embedded in an iPhone app; a small secured backend/proxy would be needed if an approved API requires a secret. The prototype should never scrape an airport site or quietly substitute aircraft-position data for a gate.