Keeping a live game shippable

Not all engineering is building the new thing. TerraGenesis was already a popular, shipped game with a large live player base when I came on as a contractor — so the job wasn't features, it was keeping a moving target shippable: fast to install, reliable to launch, and continuously buildable as iOS, Android, and a dozen third-party SDKs shifted underneath it. Over roughly two years — this work ran from 2019 to 2021 — that meant work on three fronts: the build, the launch, and the treadmill.

Halving the build

Install conversion falls off with app size — hardest on cellular and in emerging markets, which is exactly where a game like this grows. The Android build was ~300 MB; I got it to 160 MB. The wins were unglamorous and measured:

• Texture import discipline. Correct per-platform compression across the board, with the planet height-map textures handled separately — the result looked ~95% identical while shedding most of the weight.
• LZ4HC build compression, which does most of the remaining work once the assets themselves are sane.
• Resources/ hygiene. Unity force-includes everything under Resources/ in the build, whether it's referenced or not. Moving the icon set out of Resources/ alone cut a meaningful chunk. A parallel pass optimized iOS assets.

A launch that actually finishes

"Load success" — the share of app opens that actually reach gameplay — is a real KPI, and on a large device matrix it's where players quietly churn. Several pieces here worked together:

• On-demand asset delivery. Rather than bundle every planet's imagery into the binary, the app streams it at launch through a downloader that reports live progress (finished / total) behind a loading popup — smaller install, assets fetched when needed.
• Android OBB expansion handling. The launch path waits for the expansion file to be present before proceeding, so the game doesn't race ahead of its own assets.
• A remote-config watchdog on the loading screen. Its detection timeout and toggles are read from remote config (ssod_detection_time, defaulting to 60s, and companion flags) — so if launches started stalling in the field, we could tune the timeout and mitigation server-side without shipping a build.
• Main-thread init discipline & crash fixes. Pushing SDK init and conversion-value writes onto the main thread, and chasing dependency-update crashes (e.g. Firebase Messaging) — the boring bugs that show up as a launch-time crash spike.

The SDK & compliance treadmill

A live game inherits every platform change whether or not it wants to. Keeping this one compliant and buildable meant a steady cadence of: iOS 14 App Tracking Transparency and IDFA handling, SKAdNetwork configuration, a COPPA flag, minimum-deployment-target bumps — and version-managing a dozen third-party SDKs (Firebase, Facebook, IronSource and its ad adapters, and more), including migrating dependency resolution from PlayServicesResolver to the External Dependency Manager. None of it is glamorous; all of it is the difference between "ships this week" and "blocked."

Making the fragile parts repeatable

The most brittle step in a Unity mobile build is the post-export mutation of the generated Xcode project. I authored and maintained a suite of build post-processors so that step is deterministic instead of a manual ritual: App Tracking Transparency and SKAdNetwork entries, entitlements wired by relative path, changes targeting the correct main target GUID, the move to an Xcode workspace, and proper escaping/quoting in the generated scripts. Sitting above that, a headless CI build runner (Builder.cs) parses command-line arguments — project path, build target, version, and keystore secrets — so a clean build comes out of CI the same way every time, not off one engineer's machine.

The launch path

flowchart TB
  START[App start] --> RC[Remote config
load-flow timeouts & toggles]
  RC --> OBB{Android OBB present?}
  OBB -->|wait| OBB
  OBB -->|ready| DL[On-demand asset download
progress: finished / total]
  DL --> WD[Loading-screen watchdog
ssod_detection_time]
  WD -->|stalled| MIT[Mitigate / recover]
  WD -->|ok| GAME[Gameplay]
  MIT --> GAME
    

Why it's built this way

• Size and launch are conversion. A smaller install and a launch that reliably finishes aren't polish — they're the top of the retention funnel.
• Tune in the field, not in the store. Putting launch-flow timeouts behind remote config means a live incident is a config change, not a multi-day store submission.
• Automate the brittle step. Scripting the Xcode post-processing and the CI build turns the flakiest part of mobile shipping into something reproducible.