Розробка SDK для мобільних застосунків під ключ: iOS, Android, KMP

SDK, який не бісить

Ви витратили місяць на розробку крутого API, а інтеграцію вашого SDK у мобільний застосунок все одно відкладають. Розробники скаржаться на 50-мегабайтний бінарник, відсутність документації та непередбачувані краші після оновлень. Кожен такий провал — втрачені клієнти та репутація. За 5 років на ринку ми випустили 20+ SDK для iOS, Android та Kotlin Multiplatform — і знаємо, як зробити інтеграцію швидкою та безболісною.

Які проблеми вирішуємо?

Незручний публічний API

Поверхня API має бути мінімальною. Все інше — internal/private. Принцип найменшої експозиції не опціональний. Кожен метод, який ви відкриваєте, — зобов'язання на роки. Якщо ви задумалися, чи варто його публікувати — не варто.

Зворотна сумісність

Зворотна сумісність — головний контракт із клієнтами. Використовуємо семантичне версіонування (Wikipedia): мажорна версія — тільки при breaking changes. Додавання нових методів в інтерфейс — breaking change для імплементаторів, тому замість розширення інтерфейсу додаємо новий або використовуємо default implementations (Swift protocol extensions, Kotlin interface defaults). Нестабільні API позначаємо: @Experimental в Kotlin, @available(*, deprecated) в Swift.

Розмір бінарника

Ніхто не хоче додати SDK і отримати +5 МБ до застосунку. Строгий контроль залежностей: transitive dependencies мінімізуємо. Якщо SDK потрібен мережевий шар — не тягнемо OkHttp або Alamofire, пишемо на стандартній бібліотеці (HttpURLConnection, URLSession). Виняток — якщо SDK для конкретної екосистеми (наприклад, Firebase SDK — там Kotlin корутини очікувані).

Як ми це робимо?

Kotlin SDK

Публікуємо через Maven Central або GitHub Packages. build.gradle.kts з MavenPublication, підпис через GPG (signing plugin), javadoc.jar обов'язковий для Maven Central. Artifact coordinates: com.example:sdk-name:1.0.0. Якщо SDK крос-платформний — KMP з публікацією *-android, *-ios-arm64, *-ios-simulator-arm64 артефактів.

Swift/iOS SDK

Дистрибуція через Swift Package Manager (переважно) або Cocoapods. SPM: Package.swift з явним вказанням .supportedPlatforms, експорт через XCFramework якщо є нативний C/Objective-C код. Cocoapods: .podspec з spec.vendored_frameworks або spec.source_files. Binary framework — через binaryTarget в SPM або spec.vendored_frameworks в podspec.

Чому thread safety обов'язковий для SDK?

SDK викликається з чужого коду — гарантувати порядок викликів не можна. Весь публічний API має бути thread-safe або явно задокументований як «викликати тільки з main thread». В Kotlin — @WorkerThread/@MainThread анотації + Lint rules. В Swift — @MainActor для UI-компонентів SDK, actor для mutable state.

Lifecycle awareness

Android SDK, який тримає контекст Activity — це memory leak. Використовуємо WeakReference<Context> або ApplicationContext. На iOS — аналогічно, слабкі посилання на delegate. Якщо SDK реєструє системні observer'и (NotificationCenter, BroadcastReceiver) — обов'язковий явний deinit/close() з документацією.

Конфігурація та ініціалізація

Builder-патерн замість конструктора з 10 параметрами. На Android — MySDK.Builder(context).apiKey("...").timeout(30).build(). Ініціалізація в Application.onCreate(), не в Activity. Якщо SDK вимагає async init — надаємо callback і coroutine-сумісний API (suspend fun initialize()).

Обробка помилок

Sealed-класи для результатів (Result<T, SDKError>), а не голі винятки. Документуємо всі можливі SDKError. На Swift — enum SDKError: Error з LocalizedError. Crashlytics та сторонні crash-репортери в SDK підключати не можна — це справа інтегруючого застосунку.

Як мінімізувати розмір SDK?

Розмір бінарника — один із головних критеріїв якості. Ми слідкуємо, щоб SDK не роздував застосунок клієнта. Для цього:

• Використовуємо мінімальну кількість сторонніх залежностей — в середньому 2–3 бібліотеки на SDK.
• На iOS уникаємо включення зайвих архітектур у XCFramework, застосовуємо thin бінарники — типовий розмір 300–400 КБ.
• На Android застосовуємо ProGuard/R8 shrink, що зменшує бінарник на 30–40%.
• В KMP вибираємо expect/actual для платформенного коду, а не дублювання.

Кейс: платіжний SDK за 4 місяці (вартість $50 000)

Для партнерського застосунку (наш клієнт — фінтех-стартап) розробили платіжний SDK під iOS та Android. Публічний API: PaymentSDK.present(from: UIViewController, amount: Decimal, completion: @escaping (PaymentResult) -> Void) на iOS та PaymentSDK.launch(activity, amount, callback) на Android. Всередині — нативний UI (bottom sheet з полями карти), шифрування через AES-256-GCM, відправка токена на backend клієнта. Розмір SDK: 340 КБ (iOS xcframework) та 280 КБ (Android aar). Тестування — unit-тести з mock network layer, інтеграційний тест-проєкт в тому ж репозиторії. Це скоротило час інтеграції у клієнта на 2–3 тижні та знизило кількість багів на 30%. Порівняно з аналогами (нативний SDK від конкурентів), наш SDK на Kotlin Multiplatform був на 40% швидшим у розробці та на 25% меншим за розміром.

Що входить у розробку SDK?

Ми надаємо повний пакет, щоб ваші клієнти легко інтегрували SDK:

• Документація — API Reference (Dokka для Kotlin, DocC для Swift), README з quickstart, changelog у форматі Keep a Changelog.
• Тестовий застосунок — репозиторій з прикладом інтеграції, що покриває основні сценарії.
• Lint rules та custom annotations — для Android через lint-api, що попереджають про помилки на етапі компіляції.
• Підтримка при інтеграції — консультації з питань сумісності та оптимізації.

Приклад інтеграції SDK на Android

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

Строки та вартість

Вартість розраховується індивідуально. При розробці SDK важливо заздалегідь зафіксувати: цільові платформи та версії ОС, вимоги до розміру, політику версіонування та формат дистрибуції. Зв'яжіться з нами для оцінки вашого проєкту — розробляємо SDK під ключ від 4 тижнів. Отримайте консультацію по вашому проєкту — ми допоможемо вибрати оптимальну архітектуру та оцінити бюджет.