I sought professional advice while deciding how to translate Grounded, my airport accessibility concept for autistic adults travelling independently, into a functioning iOS prototype. This was an important stage of my Studio Practice because it challenged me to consider technical feasibility alongside the visual and interaction design. I wanted to understand the process rather than assume that a polished screen mock-up was equivalent to a working application.

Initiating contact through LinkedIn

I identified an app developer on LinkedIn who had already published two applications. I contacted them to ask about their experience and whether they would be willing to explain the development process. We subsequently arranged a Microsoft Teams conversation.

What I learned from the conversation

During the call, the developer introduced me to Xcode and SwiftUI as a route to building a native iPhone app. They discussed the stages of development and pointed me towards learning resources. Their guidance encouraged me to consider building the prototype myself rather than depending entirely on a visual platform. They also advised approaching functionality in manageable stages, testing while developing, and investigating external API restrictions early.

The conversation helped me understand that the choice of development method would influence what I could test. In particular, my proposed app involved changing flight information, optional support and wearable input; these were not simply questions of how a screen should look, but of how the interface should respond.

How the advice influenced my decisions

Before seeking advice, I was weighing a visual or AI-assisted approach against learning native development. Following the conversation, I chose Xcode and SwiftUI. This was a deliberate trade-off: coding involved a steeper learning curve, but offered greater direct control over navigation, changing information and support prompts.

The advice to investigate API limitations also became relevant during development. When I discovered that the flight-data service available to me supported current flights but not the next-day planning I initially imagined, I adapted the app around live flight lookup. That later technical challenge reinforced the importance of checking what a data service actually provides rather than assuming it supports the intended experience.

This page records the professional guidance and its influence on my approach. The detailed coding, Fitbit testing, debugging and location work are documented separately in GDE751: Week 20: Learning SwiftUI and Building the Prototype.

Critical reflection

Reaching out to someone with experience of publishing applications gave me a more informed starting point and the confidence to attempt an unfamiliar technical process. It did not remove the need to evaluate the advice independently. Native development gave me flexibility, but did not guarantee access to live airport data, wearable compatibility or accessibility. These remained separate design and technical questions.

The value of this professional exchange was therefore not simply receiving a recommendation for a particular tool. It was learning to connect design ambition with implementation constraints, and recognising that external guidance can inform—but should not replace—my own experimentation, testing and judgement.