The constraint
Transit information is only useful if it survives the moments when the network does not. Spotted Train was shaped around live departures, changing service data, and users who still need an answer when remote services are slow or unavailable.
Spotted Train was developed collaboratively in an academic context. I contributed to the initial product direction and focused on the iOS client: SwiftUI architecture, route search, offline-oriented data handling, maps, local persistence, and Firebase notification flows.
Instead of treating offline behaviour and failure states as edge cases, the app uses cached data, explicit retries, local persistence, and clear UI states as part of the product itself.
My part
I shaped the client around unreliable data.
Spotted Train was developed collaboratively. The areas below describe the product and client work I contributed, alongside the team’s service-side work.
Product & client
Initial product concept, product direction, SwiftUI application structure, navigation, route search, station search, and departure matching.
Data & resilience
Live data retrieval, cached and offline fallbacks, local persistence, cache invalidation, connectivity handling, retries, and error states.
Maps & interaction
Dynamic station and line configuration, interactive maps, route geometries, favourites, and user preferences.
Services & security
Realtime service alerts, push notification subscriptions, Firebase integration, and application security in collaboration with the team.
What stayed with me
A transit app is a reliability problem.
The project taught me that reliability is not a single feature. It comes from the interaction between the interface, the data layer, remote services, local state, and failure handling.
It also gave me a better understanding of how to structure a growing mobile application and how to make technical decisions that remain maintainable as the product evolves.