In January 2012, the App Store was less than four years old. Most software companies were still working out what it meant to build for mobile devices with the hardware constraints of the time: slow processors, limited memory, unstable networks, and SDKs that changed with every OS release. Few teams had experience shipping native applications with the availability, data volume, and security requirements comparable to critical infrastructure.
Ubbin Labs took on the project of developing native applications for Heathrow Airport in London, one of the busiest airports in the world. The requirement was clear: three platforms simultaneously. iPhone. BlackBerry. Nokia QT. Not three simplified versions, but three complete native implementations built from scratch.
What the application did
The application gave users real-time access to information on all flights in the airport, with focus on their specific flight. A personalised alert system notified gate changes, delays, and status updates. Each trip could be planned in advance, with information about the destination city and country and available transport options.
The airport map was available in detail, with the location and information for every commercial establishment inside the terminals. The parking module let users photograph their vehicle on arrival at the car park and recover its geo-location on return. For frequent travellers through Heathrow, losing a car in a park of tens of thousands of spaces is a real problem. The module solved it.
Three codebases, one product
There was no cross-platform development framework with sufficient maturity for this type of application in 2012. React Native did not exist. The only path was three separate native implementations: Objective-C for iPhone, Java for BlackBerry, C++ with Qt for Nokia. Three SDKs, three development environments, three release pipelines, one backend feeding all of them.
Any change to the data model propagated through all three implementations. A bug could be platform-specific or shared across all three. Testing meant covering three failure surfaces with different behaviour. Synchronising authentication state, managing sessions, and ensuring alerts arrived with the same reliability on BlackBerry OS and iOS were each a different problem depending on the platform.
The nature of the data added pressure: real-time flight information implies high volumes, high update frequency, and zero tolerance for display errors. A passenger who sees the wrong gate on their phone because a sync failed is a passenger who misses their flight. Reliability was not a quality requirement. It was the basic premise of the product.
What it cost
There were nights that did not end. Not for lack of organisation, but because the problems were genuinely hard and there were no shortcuts available. Debugging a synchronisation issue that only appeared on BlackBerry meant switching runtime, debugger, and mental model, multiple times a day. The team learned to work in parallel across three distinct technical contexts without losing coherence in the final product.
The applications shipped in January 2012. They worked. Heathrow Airport used them.
What the team came away with was not just three apps in production. It was direct experience with cross-platform mobile architecture at a moment when most engineers were still figuring out how to build for one platform. That experience compounded. The same team went on to build Gamefoundry and, later, GFoundry.