Iterable Mobile SDK.

Staff engineer and technical owner of a cross‑platform SDK that a hundred‑odd enterprises integrate against — push, in‑app messaging and real‑time analytics at billion‑event scale.

FIG. II.A · Frontispiece SDK reach + API surface
· iOS · Android · React Native · Flutter ·

Fig. II.A The four runtimes that integrate against the same versioned interface contract. Schematic — to be replaced with the public reference diagram.

§ 01The problem

An SDK that can’t break.

Iterable’s mobile SDK is the integration layer for push, in‑app messaging and real‑time analytics for some of the largest consumer brands in the world — NBC, DoorDash, Priceline among them. A hundred‑plus enterprise customers, billion events handled per day.

When a public SDK has that surface area, every release is a load‑bearing structural change for someone. A regression that ships in a 1.4.2 patch can be the reason a Black Friday push doesn’t fire for forty million users. Versioning, backward compatibility and the test infrastructure underneath aren’t engineering hygiene — they’re the product.

An enterprise SDK is two products bolted together: the runtime, and the integration experience. Skip the second and the first one barely matters.

§ 02My role

Staff, technical owner.

TitleStaff Software Engineer

Tenure2024 — present

TeamMobile SDK Platform

Reports toEngineering Manager

I own the technical direction across iOS, Android, React Native and Flutter. In practice that means three overlapping responsibilities.

Architecture. Versioned public interfaces and backward‑compatibility contracts across four runtimes; comprehensive automated test infrastructure covering the matrix of OS, framework version and customer integration shape.

Reliability. CI, release tooling and the developer‑facing build‑and‑publish surface — the system that has to stay calm when a customer files a P0 against a release‑candidate at 23:00 local.

Escalation & dev‑rel. Specific high‑touch customers (Priceline, DoorDash and others) where the job is to be the engineer who shows up, reads their integration, finds the threading deadlock or the ANR pattern, and ships the fix in the next patch.

§ 03The stack

What it’s built on.

iOS / SwiftNative SDK and the Swift concurrency surface. Swift · SwiftUI · Combine · XCTest

AndroidNative SDK and the Kotlin coroutines surface. Kotlin · AndroidX · Espresso

React NativeTypeScript bridge layer with parity guarantees across both natives. TypeScript · TurboModules

FlutterDart plugin and the platform‑channel layer. Dart · Flutter

CI / releaseMulti‑runtime CI, signed builds, public release surface. GitHub Actions · Bitrise · CocoaPods · Maven · npm · pub.dev

FIG. II.B API surface across
four runtimes
· contract diagram ·

FIG. II.C Release pipeline
· four package ecosystems ·

Fig. II.B–C API surface across the four runtimes; the release pipeline that publishes to four package ecosystems in lockstep.

§ 04Outcomes

What shipped.

01Stability. Materially fewer regressions reaching customer integrations release‑over‑release.
02Integration time. New customers integrating in days, not weeks. The dev‑rel work compounds.
03Surface coverage. Feature parity across four runtimes — the same contract, not four divergent SDKs drifting in private.
04Customer escalation. Several P0 customer issues resolved within a release cycle.

Specific customer counts, event volume figures and regression rates available under NDA to qualified employers.

Endnote

Backward compatibility isn’t a constraint. It’s the only honest unit of trust between a platform and the teams that build on top of it.

— an internal memo, paraphrased.