Omise Payment iOS SDK

01 Problem

A payment platform ecosystem needed reusable iOS packages shared across multiple apps. The SDK had to provide networking with SSL pinning, Keychain-backed storage, analytics logging, WebView-based authentication with PKCE flow, and a reference architecture for onboarding new apps.

02 Approach

Chose a layered SPM architecture over a monolithic framework because consuming apps needed different subsets of functionality. Evaluated CocoaPods and Carthage — selected SPM for zero-config integration and Apple-native dependency resolution. Designed four layers (Core → Common Services → Data → UI) with strict upward-only dependencies, so networking and storage could be used independently of auth or analytics. Insisted on zero third-party dependencies in core packages to minimize integration risk for consuming teams.

03 Solution

Designed and built 6 reusable Swift Package Manager packages forming a layered SDK architecture. The network layer provides HTTP with SSL pinning and retry logic. The storage layer offers Keychain property wrappers and FileCache. GCPUserKit SDK handles WebView-based authentication with PKCE flow and token management. WebViewBridge enables native-web communication with topic-based pub-sub. Published reference architecture sample for new app onboarding.

04 Outcomes

05 Trade-offs

Zero third-party dependencies meant writing custom SSL pinning and retry logic instead of using Alamofire — more code to maintain but eliminated version conflicts across consuming apps. SPM at the time (Swift 5.5) had limited binary distribution support, which complicated distribution to teams using older Xcode versions. The strict layering occasionally forced awkward API boundaries where a cross-cutting concern like logging had to be injected rather than imported directly.

06 Constraints

• Must support iOS 11+ for broad compatibility
• Zero third-party dependencies in core packages
• SSL pinning mandatory for network layer
• SDK must be independently testable

07 Innovation

Layered SDK: UI Layer → Data Layer → Common Services → Core (Network/Storage). Each layer is a separate SPM package with explicit dependencies. Published reference architecture sample for onboarding new apps to the ecosystem. Custom property wrappers for Keychain and UserDefaults access.

08 Reflection

The layered SDK pattern proved its value when the platform expanded to new apps — each could cherry-pick exactly the packages they needed without pulling in unrelated code. The zero-dependency constraint, initially seen as overly strict, prevented multiple integration issues that other teams experienced with transitive dependency conflicts. This project crystallized my approach to SDK design: explicit layers, minimal dependencies, and reference architectures for onboarding.

09 Links