Skip to content
Selected work

Case study

A shared SDK adopted by 3+ partner apps

A modular iOS SDK platform for healthcare and fintech clients: versioned public APIs, reusable components and partner-specific adapters, distributed through CocoaPods and Swift Package Manager.

Role
Tech lead, SDK architecture
Platform
iOS SDK, consumed by partner apps
Stack
Swift · modular frameworks · OAuth 2.0 · CocoaPods · Swift Package Manager
Period
2019 – 2021

Context

Several partner applications needed the same capabilities: authentication, secure API access and a set of UI components. Each had been integrating them differently, with different bugs.

The goal was one SDK that partner teams could adopt on their own, without a support engineer in the room.

My role

  • Designed the module boundaries, the versioned public API and the distribution pipeline.
  • Wrote the integration documentation and the partner-specific adapters.

Constraints

  • Partners were on different release schedules and could not all upgrade at once.
  • Healthcare and fintech requirements for secure storage and transport.
  • Any breaking change in the SDK was a breaking change in several products.

Key decisions

  1. Decision 1

    Versioned public interfaces with semantic versioning

    Public protocols are versioned and old versions are deprecated rather than removed. It slows the SDK's own evolution, but partners could upgrade on their schedule, which is why they adopted it.

  2. Decision 2

    A core module plus thin partner adapters

    Shared behaviour lives in a core framework; partner-specific differences live in small adapter modules. More packages to maintain, and far less duplicated code when a partner needed something different.

  3. Decision 3

    Automated CocoaPods and Swift Package distribution

    Both package managers were supported from the pipeline so partners could use whichever they already had. Two distribution paths to test, one fewer reason for a partner to say no.

What I built

  • Core SDK: OAuth 2.0 authentication, secure RESTful networking, secure storage and shared UI components.
  • Partner adapters wrapping the core for each integration's specifics.
  • Integration docs with a quick start that a partner engineer could follow without assistance.
  • Automated CocoaPods and Swift Package Manager release pipeline.
Partner app APartner app BPartner app CAdapter AAdapter BAdapter CVersioned public APIsemver · deprecationsCore SDKauth · networking · UI
Partner apps depend on a versioned public API; adapters absorb partner-specific differences so the core stays shared.

Validation

  • Unit tests on the core modules and contract tests on the public API for each released version.
  • Sample apps for both package managers built in CI on every release.
  • First partner integrations done side by side to find gaps in the docs, then later partners integrated on their own.

Release and operation

  • Tagged releases published to CocoaPods and as Swift packages from the pipeline, with changelogs and deprecation notices.
  • Partner upgrades on their own schedule; deprecated interfaces kept until every partner had moved.

What changed, and what I'd do next

  • Adopted by 3+ partner applications.measured
  • Later partner teams integrated from the documentation without direct support.observed
  • Team release velocity improved by 20% through the shared architecture and automation.measured

Measured: a number from logs, analytics or a release pipeline. Observed: seen in production without a formal measurement. Design goal: what the system is built to guarantee.

What I'd do next

  • Add automated API-diff checks to the release pipeline so a breaking change cannot ship under a minor version.
  • Publish adapter templates so new partner integrations start from a working skeleton.