Two mobile SDKs for an e-commerce SaaS vendor

The context

An e-commerce personalisation SaaS vendor offered its solution on the web and wanted to bring it into its customers’ mobile applications — large retail brands. So the deliverable was not an application, but a component other teams embed into theirs.

The challenge

An SDK does not play by application rules. Nobody sees the code, and that is exactly the problem: what client developers do see is the API surface, the error message at 6pm on a Friday, and how long it takes them to work out how to wire the thing up.

Three constraints followed:

1. A public API is a commitment. Once a retailer has embedded the SDK in their app, every signature change becomes a cost for them. You have to get it right early.
2. You don’t control the host application. The SDK has to coexist with architectures and versions you didn’t choose, without forcing its own dependencies on them.
3. Two platforms, one coherence. An iOS developer and an Android developer must find the same concepts, even though the languages differ.

What we did

• An Android SDK, distributed as a standalone library, with explicit handling of transitive dependencies — the thing an integration almost always trips over first.
• An iOS SDK, distributed via Swift Package Manager, with an API deliberately mirroring the Android one: same concepts, same names, symmetric initialisation.
• Several initialisers, from the simplest (one API key) to the most complete (server URL, environment, logging). Simple case immediate, advanced case possible.
• Multi-tenant configuration and production / pre-production switching, so client teams can test without touching real data.
• Demo applications in UIKit on iOS, and in both classic views and Jetpack Compose on Android. An integrator finds an example resembling their own code, whatever architectural generation they are on.
• Integration documentation shipped with each SDK.

The outcome

Two native SDKs delivered in parallel, ready to be embedded by the engineering teams of the vendor’s retail customers.

On this kind of engagement, quality comes down to one measure: how many questions the integrator has to ask before it works. All the effort on API design, symmetric naming and multiple examples exists to drive that number towards zero.