Wildgoose

Wildgoose runs interactive team-building events for businesses across the UK and internationally. Participants use a native mobile app to complete GPS-based treasure hunts, augmented reality challenges, live scoreboards, and real-time messaging. The app works in two modes: one for players, one for Game Managers overseeing live events from the field.

When Foresight Mobile came on board in mid-2025, both the iOS and Android apps were functional but fragile. The iOS app relied on a deprecated AR framework, had no active crash error reporting despite Firebase Crashlytics being installed, and ran on a brittle build configuration requiring frequent manual intervention. The Android app was targeting an API version that would soon fail Google Play compliance checks, had no unified logging system, and contained a backlog of crashes that were difficult to diagnose because they arrived with no context.

We ran a retainer-based app support and maintenance engagement across both platforms, with priorities set by technical risk. The first task was understanding the depth of the problem. What we found warranted treating both apps as app rescue cases: working products with significant hidden instability.

What We Addressed

• Crash observability - Both apps were effectively blind to production errors. We changed that.

• Android 35 compliance - Required for continued Google Play distribution, involving build system upgrades, permission model changes, and a complete edge-to-edge UI implementation across every screen

• AR framework migration - The legacy AR SDK deprecated and removed on both platforms; Vuforia Engine integrated as the replacement

• CI/CD automation - Codemagic configured for automated staging and production builds on both iOS and Android, with Slack notifications on build status

• Stability fixes - A catalogue of race conditions and lifecycle crashes identified and resolved once proper observability was in place

• Dependency modernisation - Deprecated libraries removed and replaced with current, supported alternatives

The Observability Problem

The most striking discovery from the initial audit was on the iOS side. Crashlytics was installed and initialised. The app appeared to have crash reporting. But a code-level audit found that errors throughout the app were being silently swallowed or discarded with no record sent to any monitoring system. In a live event where hundreds of participants are mid-game, silent failures are the worst kind: nobody knows something is wrong until a player can't complete a challenge, a photo won't upload, or a push notification disappears into the void.

The audit covered every layer of the app where errors could occur undetected: photo handling, push notification delivery, asset downloads, and local data storage. We documented the full findings and delivered a phased implementation plan for proper Crashlytics coverage, prioritised by the areas most likely to affect live events.

On Android, we addressed the same problem by designing and building WGLog: a unified logging system wired directly to Crashlytics. Every meaningful event in the app, from network requests to game state changes, now creates a timestamped breadcrumb in the crash report. When a crash does occur, the Crashlytics report contains a full timeline of what the user was doing, which game they were in, which screen they were on, and what preceded the failure. Diagnosing a crash that would previously have taken hours of guesswork now takes minutes.

Stability Improvements That Followed

Observability doesn't fix crashes by itself. What it does is make them findable. Once both apps were reporting correctly, we worked through the backlog of issues that became visible.

On Android, these included: intermittent failures when players joined a game with a selfie, a camera preview that would blank under certain device conditions, crashes in the leaderboard when loading team profile images, and a race condition affecting profile image uploads. Several of these had almost certainly been present for some time. Players had been hitting them silently.

The AR scanning flow (used for augmented reality challenges in live events) was also hardened. It had been susceptible to crashes when launched from different points in the game. We identified the root cause and made the launch path safe regardless of how a player arrived at the AR screen.

AR Framework Migration

Both apps relied on Wikitude for augmented reality features: scan-to-unlock challenges, AR hotspots, and IR scanning. Wikitude's licensing model had become problematic, and its timing behaviour was causing instability on modern iOS devices. The decision to migrate to Vuforia Engine was straightforward; the implementation was not.

On iOS, we configured Vuforia to avoid unnecessary GPU initialisation when AR features were not in use, which had a measurable effect on battery draw during standard gameplay. The removal cleaned up a significant volume of legacy code across both platforms.

On Android, the Vuforia update was tackled alongside the broader Android 35 upgrade, including updates to the build toolchain and the app's networking library.

Android Edge-to-Edge UI

Android 35 introduced edge-to-edge display as a hard requirement. Apps that don't handle this correctly show visual artefacts: clipped content, buttons hidden behind navigation bars, slivers of uncovered background. The Wildgoose app had not been built with edge-to-edge in mind.

We performed a screen-by-screen audit and implementation across every screen in the app: entry and join flows, all game task types, the AR scanner, the leaderboard, the map, the navigation drawer, and more. Timed challenge screens required particular care: when a player opens the keyboard to type an answer, the on-screen timer must stay visible. Getting this wrong means players lose track of time mid-challenge.

We tested across Android 34 and Android 36 to verify correct behaviour across the supported device range, including specific fixes for display truncation issues on newer Pixel hardware. We also documented the full set of patterns discovered during the implementation, so any new screen added to the app can be brought into compliance without repeating the audit from scratch.

iOS Networking and Dependency Modernisation

The iOS app's networking layer was built on a legacy library that predated the current Swift codebase, and the mismatch was showing. Network errors were being silently discarded rather than surfaced, and thread safety around callbacks was inconsistent. We replaced it with Alamofire, the standard Swift networking library, introducing structured error handling and consistent behaviour across all HTTP communication in the app.

Beyond the networking migration, we conducted a broader dependency audit: several deprecated libraries were removed and replaced with modern equivalents, Bugsnag was removed in favour of the already-present Crashlytics, and Firebase and Crashlytics were updated to current SDK versions.

CI/CD Automation

Both apps now build automatically on every merge to the development branch. On iOS, Codemagic produces staging and production App Store builds with build numbers that are simple to correlate back to the exact code that produced them. The old configuration, which required manual intervention to produce builds, was removed entirely.

On Android, Codemagic produces beta builds distributed via Firebase App Distribution, with release candidates published directly to the Google Play Internal Test Track. Both platforms send Slack notifications on build success or failure, so the Wildgoose team knows immediately when something needs attention.

Documentation

A recurring theme across the engagement was that the codebases were difficult to work in for anyone unfamiliar with them. We produced comprehensive documentation that lives alongside the code: build and release guides, a full reference for the WGLog logging system, technical documentation of the Vuforia AR integration, and configuration files that allow AI coding assistants to work accurately in the project without needing to rediscover context from scratch.

The most direct measure of the work's impact is what the crash dashboard now shows: not a higher crash rate, but a visible one. Before, failures were silent. After the observability changes on both platforms, the team could see exactly what was happening in production and act on it. In the weeks following the initial rollout, we identified and resolved a significant backlog of crash classes that had previously gone undetected: players were hitting them, but without reporting infrastructure in place, the team had no way of knowing.

The Android app shipped on schedule to Android 35, maintaining Google Play distribution without interruption. The AR migration on both platforms removed a dependency that had been causing intermittent instability and whose long-term viability had been uncertain. The CI/CD automation means staging builds are now available to the Wildgoose team within minutes of a merge, without any manual steps.

The engagement is ongoing under a monthly retainer, covering support and maintenance alongside continued feature development on both platforms. The codebase is now in a state where new work is straightforward to estimate and deliver: dependencies are current, builds are automated, and crashes arrive with context.

If your app has been running for several years and you're not sure what's failing in production, or you're carrying technical debt from deprecated frameworks, the App Gameplan is a practical starting point. It's a fixed-price, four-week process that gives you a clear picture of what needs addressing and in what order.