As my airport accessibility project moved from interface concepts towards an interactive prototype, I needed to decide how to develop the application. My design intended to bring navigation, flight changes, sensory information and optional assistance into one traveller-controlled experience. I had a graphic design background but limited coding experience, so the method itself became a design decision.

I considered a visual or AI-assisted approach, which appeared quicker to learn, alongside native iOS development. I did not want to choose a tool purely because it seemed easiest: I wanted to understand the system I was designing and challenge myself to learn how to build it.

Seeking professional guidance

I found an app developer through LinkedIn who had already published two applications. I contacted them to ask whether they would be willing to explain the development process. We arranged a Microsoft Teams call.

They introduced me to Xcode and SwiftUI, discussed how an iOS interface is built and recommended resources for learning. Their advice was to consider coding the app myself rather than relying on a visual platform, build functionality in manageable stages, test as I progressed and investigate the restrictions of external APIs early.

This was a useful turning point. Instead of treating coding as something separate from design, I began to see it as a way to test whether my interface decisions could become real interactions.

Comparing possible approaches

The exact “Firefly” platform discussed at the time still needs confirming. These are comparisons of development approaches, not verified feature claims about a specific product.

Advantages and trade-offs

A visual approach appealed because it could reduce the initial technical barrier and allow more time for interface refinement. However, I was concerned about how far I could customise complex interactions, especially progressive disclosure, optional support controls and changes to live travel information. These were questions to investigate rather than proof that a particular platform could not support them.

Coding with Xcode and SwiftUI was more demanding. It required learning unfamiliar terminology, structuring screens and understanding errors. In return, it offered a way to implement and inspect interactions directly, with more control over the behaviour of the prototype. Native development did not automatically solve the harder questions around live airport data, wearable connectivity or accessibility: those still required separate investigation and testing.

Decision and rationale

I chose to develop the iPhone prototype myself in Xcode on my Mac, using SwiftUI. My decision was based on three priorities:

• Control: I wanted to make specific choices about information hierarchy, navigation and optional assistance.
• Experimentation: I wanted to understand how an interface responds to changing information rather than produce static screens alone.
• Professional development: I wanted to stretch my graphic design practice towards interaction design and software development.

The decision meant accepting a steeper learning curve. I considered that worthwhile because the technical exploration could inform my design judgement, not just the final output.

Reflection and evidence to add

Seeking guidance from someone working in app development helped me assess the options more critically. The Teams conversation gave me an initial route into Xcode and SwiftUI, while the comparison made the trade-off between speed and control explicit.

Evidence to insert: redacted LinkedIn message or Teams note; names of recommended tutorials once recovered; screenshot of the Xcode project; a dated example of an early SwiftUI experiment. These should be added only when located, rather than reconstructed as if they were recorded at the time.

Taking forward: document how I learnt SwiftUI, built the first screens and dealt with technical obstacles. API access and testing will be discussed separately, distinguishing planned functionality from verified implementation.