Розробка мобільного SDK/бібліотеки
Розробка SDK відрізняється від розробки додатку. Додатки розробляються для кінцевих користувачів; SDK — для розробників, які їх інтегрують у свої проекти. Помилки в публічному API SDK коштують дорого — після релізу виправлення означає breaking changes, які ламають чужий код.
Дизайн публічного API
Перше питання: яка мінімальна поверхня API, яку неможливо видалити? Все інше має бути internal/private. Принцип найменшої експозиції — не опціональний.
Зворотна сумісність — головний контракт. Семантичне версіонування: мажорна версія — тільки для breaking changes. Додавання методів до інтерфейсу — breaking change для імплементаторів. Замість розширення інтерфейсів додаємо нові або використовуємо default implementations (Swift protocol extensions, Kotlin interface defaults). Позначаємо нестабільні API: @experimental у Kotlin, @available(*, deprecated) у Swift.
Kotlin SDK. Публікуємо через Maven Central або GitHub Packages. build.gradle.kts з MavenPublication, підпис через GPG (signing plugin), javadoc.jar обов'язковий для Maven Central. Artifact координати: 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.
Розмір бінарника SDK. Критичний — ніхто не хоче +5 МБ до свого додатку. Суворий контроль залежностей: мінімізуємо transitive dependencies. Якщо SDK потребує мереживого шару — не тягнемо OkHttp або Alamofire, пишемо за стандартною бібліотекою (HttpURLConnection, URLSession). Виключення — SDK для конкретних екосистем (Firebase SDK — очікуються Kotlin корутини).
Ключові технічні аспекти
Thread safety. SDK викликається з чужого коду — гарантувати порядок викликів неможна. Все публічне API має бути thread-safe або явно задокументовано як «викликайте тільки з main thread». Kotlin: @WorkerThread/@MainThread аннотації + Lint rules. Swift: @MainActor для UI компонентів SDK, actor для змінювального стану.
Lifecycle awareness. Android SDK, який тримає контекст Activity — витік пам'яті. Використовуємо 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 для партнерських додатків: Android (aar через Maven) + iOS (xcframework через SPM). Публічне 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 KB (iOS xcframework) та 280 KB (Android aar). Тестування: unit-тести з mock network layer, інтеграційний тест-проект у тому ж репозиторії.
Документація та Developer Experience
Автоматично генеруємо API Reference: Dokka для Kotlin, DocC для Swift. README з quickstart обов'язковий. Changelog у форматі Keep a Changelog. Приклад додатку у репозиторії як живий приклад інтеграції.
Lint rules та власні аннотації для Android SDK через lint-api. Попереджуємо про неправильне використання на етапі компіляції, а не в runtime.
Час реалізації
| Тип SDK | Орієнтовні строки |
|---|---|
| Простий аналітичний SDK (eventi + сесії) | 4–6 тижнів |
| UI SDK (власні компоненти, екрани) | 6–12 тижнів |
| Платіжний / безпечний SDK | 3–5 місяців |
| KMP SDK (iOS + Android з однієї кодобази) | 3–6 місяців |
Ціна розраховується індивідуально. При розробці SDK важливо заздалегідь закріпити: цільові платформи та версії ОС, вимоги до розміру, політику версіонування та формат дистрибуції.