eSIM Management SDKs for Telecom Self-Service Apps

Summary

We build eSIM management SDKs that let telecom self-service applications provision and manage subscription profiles on the device. Work of this kind covers native integration with the platform eSIM APIs on Android and iOS, a common cross-platform contract for the host application, profile lifecycle operations, secure handling of activation credentials, and validation across the real device and operating system matrix rather than the one it is assumed to be.

The Challenge

Consumer eSIM provisioning follows the GSMA remote SIM provisioning architecture. The subscription profile is prepared by a network-side subscription manager and downloaded onto the eUICC through a Local Profile Assistant supplied by the operating system. The application never handles the profile itself; it supplies an activation credential, typically an activation code carrying the subscription manager address and a matching identifier, and asks the platform to perform the download.

The two platforms then diverge sharply. Android exposes eSIM operations through the platform telephony subscription APIs, gated by the carrier privileges model: an application receives those privileges only when its signing certificate hash is registered in the access rules stored on the eUICC or provisioned by the network, so the same code signed with a different certificate silently loses permission. Apple exposes a narrower surface through its cellular plan provisioning API, requires a specific entitlement granted to the application, restricts availability by device and operating system version, and hands part of the user journey to system interface screens the app cannot script. A single cross-platform abstraction therefore cannot be a thin wrapper. Capability also varies by manufacturer within one Android version, and a profile download is effectively one-shot, so optimistic state handling produces unrecoverable failures.

The Solution

Native layers under a common contract

We build the platform layers natively, in Kotlin on Android and Swift on iOS, and expose them to a cross-platform host application through a defined channel interface. The public API is deliberately small and asynchronous:

• Capability discovery, including whether the device supports eSIM at all
• Activation from a code or from a resolved entitlement
• Profile enumeration, enable, disable and delete
• Reading the eUICC identifier for entitlement checks
• An event stream for state transitions

Errors are modelled as a typed enumeration mapped from each platform, separating user-recoverable conditions such as a rejected confirmation code or insufficient storage on the eUICC from terminal conditions such as an unsupported device or missing privileges. Carrier privileges are checked at runtime before any operation, so the failure surfaces as an actionable state rather than a generic error. The SDK carries no interface of its own, so host applications keep their own design language, and it holds no long-lived credentials.

Security and integrity

Access to profile operations is authorized end to end. Activation credentials are fetched over authenticated transport from the network backend against an already-authenticated subscriber session, are single-use, and are never cached on disk. Certificate pinning protects the credential exchange. Logging excludes activation codes, eUICC identifiers and subscriber identifiers, since these otherwise end up in crash reports. Because a download cannot be repeated, credential issuance is idempotent and reconciled: if the app stops after a successful download but before acknowledgement, the system determines the true state instead of issuing a second profile.

Validation across the device matrix

Development starts with a feasibility assessment across the device and operating system matrix actually supported. Testing requires real profiles on physical hardware, because emulators cannot exercise the eUICC path. We build a dedicated test harness that drives each SDK operation, captures platform-level telephony logs, and records outcomes per device and per operating system build, which turns a slow manual matrix into a repeatable run. Integration is kept lightweight so the host app gains the capability without changes to its existing architecture or startup cost.

What This Delivers

Subscribers activate and switch profiles inside the self-service app instead of being sent to a physical channel or a web detour, and unsupported devices are handled by hiding the capability rather than by failing in front of the user. Support teams get precise state and typed errors instead of ambiguous reports. Because the SDK is versioned and interface-free, other applications can adopt the same capability without re-implementing platform behaviour.

Technologies and Tools

Kotlin with the Android telephony subscription and carrier privileges APIs, Swift with the iOS cellular plan provisioning API and its required entitlement, a channel interface for cross-platform host integration, authenticated network backend services for activation credentials, certificate pinning, and an instrumented device test harness with platform telephony log capture.