Shipping one feature in lockstep across Unity, iOS & Android

When a developer calls one method in the Unity SDK, that call has to travel through a C# wrapper, cross into native Objective-C/Swift on iOS and Java/Kotlin on Android, invoke a network adapter, and return a result — with identical semantics on both platforms. Owning the Unity layer of a production ad-mediation platform means every feature is really three implementations that must stay in perfect lockstep, plus an ecosystem of 20+ ad-network adapters that all depend on that contract.

The seam

The C# API is the single source of truth for the public surface. Below it, thin, generated-where-possible bridges cross the managed↔native boundary — P/Invoke and callbacks to the iOS framework, JNI/`AndroidJavaObject` to the Android library. The trick is that consumers never see the seam: sync and async calls, callbacks, and error models look the same regardless of platform.

flowchart TD
  DEV[Game / Unity developer] --> API[Unity C# API
single public surface]
  API --> BR{Native bridge
FFI layer}
  BR -->|P/Invoke + callbacks| IOS[iOS SDK
Obj-C / Swift]
  BR -->|JNI / AndroidJavaObject| AND[Android SDK
Java / Kotlin]
  IOS --> ADI[Ad-network adapters]
  AND --> ADA[Ad-network adapters]
  API -. UPM / NuGet .-> DIST[(Distributed to studios)]
    

What "lockstep" actually requires

• One API surface, three backings. A feature isn't done until the C#, iOS, and Android sides agree on names, signatures, threading, and error behavior — reviewed together, shipped together.
• Versioning & backward compatibility. Studios upgrade on their own schedule, so the public contract evolves additively; breaking changes are deliberate and coordinated across the SDK and every adapter.
• Distribution parity. The SDK and adapters publish to both Unity UPM and NuGet with their native dependencies resolved — the same version means the same behavior everywhere.
• Editor tooling. Cloud-updatable adapter management (via AWS S3) and Unity Editor integration so integrating studios don't hand-wire native dependencies.

Why the boundary is a flat contract

Keeping the managed↔native boundary a narrow, well-specified seam is what makes three codebases behave like one. It's the same principle I'm exploring at a lower level in PlanetExplorer — a C++ core behind a flat C ABI, designed to be embedded anywhere without coupling.