Native iOS prototype
Steady
A native iPhone prototype for handling tight connections and flight disruptions with transparent, read-only guidance.
9T1 Labs / iOSSteady
- Categories
- iOS
- Year
- 2026
- Role
- Creator
Premise
Make disruption easier to reason about.
Steady is designed for the moment when a traveler needs one reliable next action, not another dense flight map.
It explains what changed, shows the arithmetic behind a connection assessment, compares fixture-backed recovery plans, and keeps source and freshness beside every actionable state.
Interaction
A disrupted journey becomes a sequence of inspectable choices.
Review
Start with the current journey, checked time, source, and demo disclosure.
Assess
See available minutes, personal buffer, and the reasons behind the connection state.
Compare
Inspect recovery options with arrival, walking burden, baggage, and assistance facts.
Confirm
Review a sample plan without booking, paying, or changing an airline record.
Keep evidence
Use the local timeline and staffed-desk summary when connectivity is limited.
System
Native SwiftUI with a deliberately narrow domain model.
The prototype has no third-party runtime dependencies and keeps live-provider concerns behind typed protocols.
Interface
- SwiftUI navigation
- Dynamic Type
- VoiceOver labels
- Reduce Motion
Domain
- Journey models
- Buffer arithmetic
- Typed assessment reasons
- Recovery constraints
Providers
- Fixture flight status
- Rights notices
- Airport references
- Evidence timeline
- Graceful uncertainty
- Missing, stale, contradictory, or unlicensed data becomes unknown instead of an estimate.
- Read-only posture
- The app does not book, rebook, file a claim, confirm assistance, or promise a connection.
Decisions
Trust comes from showing what the prototype cannot know.
| Question | Current choice | Consequence |
|---|---|---|
| Is the flight live? | Persistent fixture labeling | Sample data cannot be mistaken for an operational feed |
| Will the connection work? | Disclosed buffer arithmetic | The app explains inputs without giving a probability or guarantee |
| Do passenger rights apply? | Official-source matching with an unknown fallback | No eligibility or compensation verdict is produced |
| Is assistance confirmed? | Route compatibility and assistance state remain separate | A step-free route never implies a confirmed handoff |
Validation
Accessibility testing changed the information model.
Route and assistance
The final model separates physical route compatibility from whether assistance was requested, confirmed, and handed between organizations.
Low connectivity
Unsafe sample phone actions were replaced with a local, short-lived staffed-desk summary.
Readable stress states
The interface was tested with dark mode, large accessibility text, stale data, offline fixtures, and missed connections.
Accessibility evidence
Maximum text-size stress state.
Dynamic Type: accessibility sizes
VoiceOver: labelled state and actions
Reduce Motion: no essential movement
Contrast: semantic system surfacesAccessibility proof
The layout is expected to survive large text.
Fixed font sizes are avoided, navigation remains native, and the journey summary can change from a horizontal composition to a vertical timeline at accessibility sizes.
Still unresolved
A live product needs agreements, governance, and stronger data controls.
Flight data
A licensed provider and server-side credential boundary are required before any live status can appear.
Rights content
Jurisdiction rules need versioning, review dates, official sources, and ongoing governance.
Airport accessibility
Verified route and assistance data require airline and airport partnerships rather than inference.