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.

1. Why a native iPhone prototype?

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.

2. The first data model

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:

• Trip and stage: selected flight, current airport stage, completed steps, next step and whether the trip has ended.
• Flight update: flight number, date, origin/destination, status, terminal, current gate, previous gate, source, last-updated time and whether a value is missing.
• Data quality: explicit sample, live, stale and unavailable states. A missing field must display “Not available” rather than an invented gate.
• Support: prompt unseen/shown/dismissed, chosen branch, active/paused/stopped mode and the journey position to return to.
• Preferences: text/audio, motion, notification and appearance choices; optional device consent and connection state.

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.

3. Data-source research: the largest feasibility boundary

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.

The UI should display the status plainly: “Sample journey,” “Updated at…,” “Information unavailable,” or “Check airport displays/airline if this differs.” In an actual service, a stale gate could be more harmful than no gate, so freshness and fallback are not minor metadata. The design study’s note is too small and will need a stronger component.

4. Maps, routes and shared airport services

Apple’s indoor-map documentation describes the need for indoor mapping data such as IMDF. MapKit does not supply a verified route through every airport by itself. A route model would need known places, paths, accessible connections, closures and update ownership. A claim that a route is “quieter” needs evidence about the environment and how current that evidence is. Until then, a sample step-by-step route can demonstrate the interaction, provided every location and property is marked illustrative. The user must still be able to read the destination without a map.

Assistance messaging is a separate service integration. The prototype can show how a person composes a request, but “request prepared” is not “sent,” and “sent” is not “confirmed.” Confirmation requires a responsible receiving system. Likewise, the Week 18 coordinated phone/airport-display idea is a system concept, not an integration that exists. These status distinctions belong in both code and copy so the interface cannot overpromise.

5. Notifications and permission

UserNotifications supports local and remote notifications; Apple’s permission guidance describes requesting authorisation. A sample build could trigger a local example of a gate change, but it must label that event as a demonstration. A genuine gate update would require an approved data feed, event processing and delivery. Permission should be asked when the traveller opts into updates, with an explanation of the benefit. Declining notifications must not block manual journey access.

I would design separate foreground and background cases. In the foreground, update the gate fact first and avoid stacking modal prompts. In the background, a notification may say that a gate changed, but opening it should land on the current event with source/freshness. If a newer event supersedes A04, the app must not keep a stale alert as though it were current. This is a research and design requirement; delivery timing has not been measured.

6. Optional Bluetooth heart-rate research

Core Bluetooth enables iOS to act as a central device; CBCentralManager controls scanning and connection. The Bluetooth SIG Heart Rate Service defines compatible measurement data. This offers a provider-neutral experiment with devices that actually expose that BLE service; it does not mean “any Bluetooth sensor” will work.

The first technical study would list searching, discovered, connected, receiving, no reading and disconnected states. The traveller would choose a compatible device and be able to disconnect. iOS Bluetooth permission and the required purpose description must be honest. Readings should remain in active-session memory only for this concept, with no analytics or biometric upload. A successful device-path check previously reported by Maia (Fitbit Air to Strava) is encouraging but does not establish generic compatibility or simultaneous connections.

Most important: a heart rate is not a diagnosis of stress or overload. The app should not set an automatic BPM threshold or infer what support someone needs. A sensor can remain an optional exploratory feature; the gate update, route and manual support must function without it. This boundary follows both the service specification’s limited meaning and the project’s audience-led commitment to choice.

7. Sound, motion and accessibility in code

The first build should be text-complete and static. Optional speech can read a chosen instruction, with play/pause/stop, while the same words stay on screen. Haptics or alert tones require a preference and should never be the sole way to notice an update. Apple’s motion guidance supports respecting reduced-motion settings. Animation should not hide the new gate while it plays.

For Dynamic Type, I would allow panels to grow vertically and preserve the whole gate code and action label. For VoiceOver, the intended order is change → current A04 → previous B12 → source/freshness → actions; decorative art is hidden from the accessibility tree. Controls must have clear labels and a reachable exit. Apple’s accessibility guidance, WCAG contrast and Use of Colour are checkable baselines. They do not replace task-based review with autistic adults.

Light and dark styles should use semantic tokens for canvas, text, route, ticket and action. The lilac/lime palette is replaceable, because exact values and visual comfort have not been approved. The app icon also needs light/dark/tinted export checks under Apple’s asset guidance.

8. Privacy and build scope

A prototype does not need an account or analytics to demonstrate the journey. Store only the preferences needed to restore the chosen experience. Do not retain heart-rate readings after the active session. Keep sample flight data visibly fictional. If a later live provider, assistance service or wearable changes the data flow, update consent, retention and failure handling before integrating it.

The sensible implementation order is: native navigation and sample journey → detailed gate-change state and support branching → status/freshness and settings → optional audio → optional BLE experiment → approved live-data investigation. This order tests the central value of the app before spending effort on uncertain integrations. It also gives Maia a working phone path even if every external service remains unavailable.

Technical decision at this stage

Proposed architecture: a modular SwiftUI iPhone prototype with one journey state, reusable information components, provider interfaces, an explicitly labelled sample BA256 B12→A04 event, optional support, and no required wearable or backend. This is a research-backed build proposal from the current brief, not implemented code. The next page explains how the prototype will be built, reviewed and documented, including where assistive AI fits and what Maia must evaluate herself.