My background was in graphic design and animation, and I was learning to code as I built Grounded. A developer I contacted through LinkedIn introduced me to Xcode and SwiftUI and suggested building in stages. I took that approach and worked directly on Grounded, beginning with a home screen and navigation before adding flight lookup and the other interactions. I installed development builds on iPhones so people could try them while the app was still changing. GDE751: Week 20: Choosing an App Development Approach · Studio Practice draft, pp. 43–44.

What one platform gave me

SwiftUI gave me native controls and a way to work with iOS accessibility features as I learned. I could use Xcode’s Accessibility Inspector to look at labels and reading order, and try larger text on the interface itself. That mattered for a gate-change alert where the destination and next action need to stay clear as the layout changes. Working with one platform also kept the development and testing scope manageable while I learnt how the app behaved. SwiftUI accessibility · Xcode Accessibility Inspector

Starting on iPhone made the build manageable. It also limited who could try it, because an Android traveller could not take part on their own phone.

What an Android build would involve

Flutter was one cross-platform option I encountered while seeking advice. It can target iOS and Android from a shared project, which could help with reach. The two platforms would still need device checks for messaging, location permission, wearable connections, text scaling and screen-reader behaviour. A native Android build would have its own interface and accessibility tools, including testing with TalkBack. Flutter platform integration · Android accessibility testing

Comparing the options I had at the time

I was choosing a development route for a project I was still defining. A cross-platform approach was attractive because the potential audience uses different phones. I also needed to learn how to build and debug a sequence involving flight data, directions and optional support. Working in one environment let me find out whether I could connect those features and get a build onto a device. My developer conversations helped me see that the choice was partly about what I would be able to check during the time I had.

The platform decision also shaped the feedback I could collect. Installing a development build on an iPhone meant I could introduce the app in person and observe how someone moved through it. It left a gap for people who use Android, including anyone who might rely on different screen-reader behaviour or text settings. I would need to invite them into the next round to understand what carries across.

What I would carry across

I would start with the gate-change journey and the return after ‘Not now’. Then I would check that the text to family, audio controls and accessibility behaviours make sense on that platform. The aim is for someone on Android to be able to make the same choices in the journey, using controls that feel familiar on their device.