Following the professional guidance documented in Professional Outreach and Expert Feedback, I began developing my airport accessibility app directly in Xcode using SwiftUI, rather than completing a separate practice application first. My initial aim was to build an interactive demonstration of a communication system for autistic adults travelling independently. As I learned to implement screens and interactions, the project developed beyond a hypothetical journey. This page focuses on what I built, the decisions I made while coding, the technical difficulties I encountered and the limits of my own testing. The LinkedIn outreach, Teams discussion and advice that informed my choice of tools are documented on the preceding page.

Starting directly with my app

I created the iOS project in Xcode and began with a basic home screen, introducing text, colours and buttons before building navigation between screens. Once I could move through the interface, I developed the individual features and connected them into a more complete user journey. This approach meant I was learning SwiftUI while applying it to a specific design problem. I could judge each technical decision against the intended experience rather than treating coding as a separate exercise.

My original prototype used example flight and gate information to communicate what the interface might look like. Although this helped demonstrate the visual hierarchy and proposed interactions, it did not allow someone to enter their own journey and use real flight information. As my confidence with development increased, I wanted to test whether the concept could operate beyond a fixed demonstration.

A flight-data limitation that changed the approach

One of my first significant difficulties came from selecting a flight-data API. I initially assumed that access to live flight information would also allow users to look up flights scheduled for the following day. After implementing the service, I realised that the data available to me covered current flights rather than the future flight planning I had envisaged. This was a consequential distinction: preparation before travel is relevant to the independence and predictability my research identified as important, yet the implementation could not support that use in the way I had first imagined.

Rather than switching immediately to a different API, I restructured how the app worked around the live information available. Instead of simply showing an example gate or suggested journey, I implemented a way for users to enter their own flight details and retrieve live flight information. This changed the outcome from a static demonstration into an application with a functioning flight-lookup feature. It also introduced a limitation that needs to remain explicit: working live flight lookup is not the same as reliable planning for a flight a day in advance.

This experience showed me that an apparently small technical assumption can affect the purpose of a design. It also taught me to distinguish between the information an API provides, the interactions I can build around it, and the needs those interactions actually meet.

Adding wearable heart-rate information

I next explored connecting wrist-worn devices so that heart-rate information could become part of the experience. I implemented wearable-data functionality and tested the connection using my own Fitbit. Initially, I succeeded in receiving heart-rate information, but the data had no meaningful function in the interface. Simply displaying a physiological measurement did not explain how it would support a traveller.

I therefore developed a response based on a heart-rate threshold. I used 100 beats per minute as the default trigger, with an option for users to adjust the threshold in relation to their own resting heart rate. When the threshold is crossed, the app presents optional support, including a grounding exercise or help finding a quiet place. Importantly, the prompt can be dismissed without selecting support. This was consistent with my wider design principle that assistance should be offered rather than imposed.

Testing, debugging and onboarding

Wearable integration was one of the most time-consuming parts of the development. I tested the feature physically with my Fitbit, running around to raise my heart rate above the default threshold and checking whether the interface responded. Although the heart-rate readings were reaching the app, I had difficulty getting the support prompt to appear as intended. Resolving the prompt behaviour required repeated debugging and testing, and took longer than most of the other features I developed.

I also discovered a setup issue through my own attempts to test it. I had not initially understood that the wearable connection and resting-heart-rate setup needed to be completed before the feature would behave as expected. After working through the device settings and allowing time for setup, I added guidance within the app to prompt users through this preparation. A problem I experienced as the developer therefore revealed a potential usability barrier for someone using the app for the first time.

This process helped me see onboarding as part of the interaction design, not an instruction to be left outside it. A feature may be technically present yet remain inaccessible if users do not know how to prepare or activate it.

Interpreting physiological information cautiously

I do not consider a heart rate above 100 beats per minute to be evidence that a user is distressed. Physical activity, excitement and other factors can raise heart rate, as my own testing demonstrated. The threshold is therefore an interaction trigger rather than a medical assessment. Allowing the user to change the setting and dismiss support is important, although further testing would be needed to assess how useful, reliable or intrusive these prompts feel in real travel contexts.

Introducing location and directions

After the wearable feature, I developed location tracking so the app could identify a user's current position and provide directions. This extended the prototype beyond communicating flight information into supporting movement through a journey. It also made the relationship between information and action more tangible: knowing that a gate has changed is only part of the problem if a traveller still needs to understand where to go.

At this stage, I have described the location and directions functionality I implemented, but I am not treating it as proof of reliable indoor airport wayfinding. That would require further testing in the relevant environment, particularly where positioning accuracy and airport-specific routes could affect instructions.

Reflection and taking forward

Coding the app myself changed the scope of my Studio Practice. I began with a proposed visual and interaction system, then progressively implemented flight lookup, wearable-triggered support and location-based directions. Each addition introduced practical questions that could not be answered through screen mock-ups alone. The flight-data limitation forced me to rethink the planning interaction; wearable testing revealed that receiving data and making it actionable are different challenges; and difficulty with setup led me to add clearer onboarding.

The strongest learning has not simply been that I can make more features work. It has been recognising where a functioning technical feature still needs a careful interaction design, and where successful self-testing does not establish broader accessibility or reliability. My next stage is to document the technical limitations and test the journeys and prompts more systematically, retaining independence, choice and clear information as the basis for further refinement.