SDK Development for Mobile Applications

SDK that doesn't annoy

You spent a month developing a great API, yet integrating your SDK into a mobile app keeps getting postponed. Developers complain about a 50-megabyte binary, lack of documentation, and unpredictable crashes after updates. Each such failure means lost clients and reputation. Over 5 years we've released 20+ SDKs for iOS, Android, and Kotlin Multiplatform — and we know how to make integration fast and painless.

What problems do we solve?

Inconvenient public API

The API surface must be minimal. Everything else should be internal/private. The principle of least exposure is not optional. Every method you expose is a commitment for years. If you're wondering whether to publish it — don't.

Backward compatibility

Backward compatibility is the main contract with clients. We use semantic versioning (Wikipedia): major version only for breaking changes. Adding new methods to an interface is a breaking change for implementers, so instead of extending an interface we add a new one or use default implementations (Swift protocol extensions, Kotlin interface defaults). We mark unstable APIs: @Experimental in Kotlin, @available(*, deprecated) in Swift.

Binary size

Nobody wants to add an SDK and get +5 MB to their app. Strict dependency control: minimize transitive dependencies. If the SDK needs a network layer — we don't pull OkHttp or Alamofire, we write using standard libraries (HttpURLConnection, URLSession). Exception: if the SDK is for a specific ecosystem (e.g., Firebase SDK — Kotlin coroutines are expected there).

How we do it?

Kotlin SDK

We publish via Maven Central or GitHub Packages. build.gradle.kts with MavenPublication, signing via GPG (signing plugin), javadoc.jar mandatory for Maven Central. Artifact coordinates: com.example:sdk-name:1.0.0. For cross-platform SDK — KMP with publication of *-android, *-ios-arm64, *-ios-simulator-arm64 artifacts.

Swift/iOS SDK

Distribution via Swift Package Manager (preferred) or Cocoapods. SPM: Package.swift with explicit .supportedPlatforms, export via XCFramework if native C/Objective-C code. Cocoapods: .podspec with spec.vendored_frameworks or spec.source_files. Binary framework — via binaryTarget in SPM or spec.vendored_frameworks in podspec.

Why thread safety is mandatory for an SDK?

The SDK is called from someone else's code — call order cannot be guaranteed. All public API must be thread-safe or explicitly documented as "call only from main thread". In Kotlin — @WorkerThread/@MainThread annotations + Lint rules. In Swift — @MainActor for UI components of SDK, actor for mutable state.

Lifecycle awareness

Android SDK that holds an Activity context is a memory leak. We use WeakReference<Context> or ApplicationContext. On iOS — similarly, weak references to delegate. If the SDK registers system observers (NotificationCenter, BroadcastReceiver) — explicit deinit/close() with documentation is mandatory.

Configuration and initialization

Builder pattern instead of constructor with 10 parameters. On Android — MySDK.Builder(context).apiKey("...").timeout(30).build(). Initialize in Application.onCreate(), not in Activity. If the SDK requires async init — provide a callback and coroutine-compatible API (suspend fun initialize()).

Error handling

Sealed classes for results (Result<T, SDKError>), not raw exceptions. Document all possible SDKError. On Swift — enum SDKError: Error with LocalizedError. Crashlytics and third-party crash reporters must not be included in the SDK — that's the integrating app's responsibility.

How to minimize SDK size?

Binary size is one of the main quality criteria. We ensure the SDK doesn't bloat the client's app. For this:

• Use minimal third-party dependencies.
• On iOS, avoid including unnecessary architectures in XCFramework, use thin binaries.
• On Android, apply ProGuard/R8 shrink to remove unused code.
• In KMP, choose expect/actual for platform-specific code rather than duplication.

Case: Payment SDK in 4 months

For a partner application (our client is a fintech startup) we developed a payment SDK for iOS and Android. Public API: PaymentSDK.present(from: UIViewController, amount: Decimal, completion: @escaping (PaymentResult) -> Void) on iOS and PaymentSDK.launch(activity, amount, callback) on Android. Inside — native UI (bottom sheet with card fields), encryption via AES-256-GCM, token sent to the client's backend. SDK size: 340 KB (iOS xcframework) and 280 KB (Android aar). Testing — unit tests with mock network layer, integration test project in the same repository. This reduced integration time for the client by 2–3 weeks and decreased bugs by 30%. Compared to analogs, our SDK on Kotlin Multiplatform was 40% faster to develop and 25% smaller in size.

What is included in SDK development?

We provide a full package to make it easy for your clients to integrate the SDK:

• Documentation — API Reference (Dokka for Kotlin, DocC for Swift), README with quickstart, changelog in Keep a Changelog format.
• Test application — a repository with integration examples covering main scenarios.
• Lint rules and custom annotations — for Android via lint-api, warning about errors at compile time.
• Integration support — consultations on compatibility and optimization issues.

val sdk = MySDK.Builder(applicationContext) .apiKey("") .timeout(30) .build() sdk.initialize() 

Timelines and cost

The cost is calculated individually. When developing an SDK, it's important to define upfront: target platforms and OS versions, size requirements, versioning policy, and distribution format. Contact us to evaluate your project — we develop turnkey SDKs from 4 weeks. Get a consultation for your project – we'll help you choose the optimal architecture and estimate the budget.