Реалізація перенесення даних при зміні пристрою (Device Migration)
Користувач купив новий смартфон, встановив ваш застосунок — даних немає. Ні історії, ні налаштувань, ні покупок. Retention падає, відгуки негативні. Device migration — не одна функція, а набір інструментів із різними компромісами. Потрібно вибрати правильний метод під конкретний сценарій.
За 5+ років ми реалізували понад 50 проєктів з міграції для iOS та Android. Використовуємо сучасний стек: Swift 5.9 з async/await, Kotlin з Coroutines, Flutter 3.x, React Native. Кожен проєкт починається з аудиту структури даних та вибору оптимального способу перенесення. Економія часу користувача — до 90%, а надійність перенесення перевищує 95% навіть при обриві з'єднання. Вартість помилки при втраті даних може сягати значних сум через відтік клієнтів.
Які платформені інструменти доступні?
iOS надає вбудовані механізми: QuickStart (пряме перенесення через Bluetooth/WiFi) та iCloud Backup. Дані в Documents та Application Support включаються до резервної копії за замовчуванням. Keychain з kSecAttrAccessible = kSecAttrAccessibleAfterFirstUnlock переноситься при iCloud Backup за умови kSecAttrSynchronizable = true.
Android підтримує Auto Backup з версії 6.0 (API 23) та Data Extraction Rules починаючи з Android 12. В AndroidManifest.xml необхідно вказати правила резервного копіювання:
<application android:allowBackup="true" android:dataExtractionRules="@xml/data_extraction_rules" android:fullBackupContent="@xml/backup_rules"> <!-- res/xml/data_extraction_rules.xml (Android 12+) --> <data-extraction-rules> <cloud-backup> <include domain="database" path="app.db"/> <include domain="sharedpref" path="user_prefs.xml"/> <exclude domain="database" path="http_cache.db"/> <exclude domain="file" path="temp/"/> </cloud-backup> </data-extraction-rules> </application> Вбудовані механізми не завжди достатні — вони не переносять дані, якщо застосунок не зберігає їх у правильних директоріях.
Як працює серверна синхронізація?
Найнадійніший підхід — все важливе зберігається на сервері, прив'язане до акаунта. Користувач логіниться на новому пристрої — отримує всі дані. Для застосунків з авторизацією це стандарт.
На сервері обов'язково зберігати:
- Профіль користувача
- Історію дій
- Покупки (обов'язково — для відновлення)
- Користувацький контент
- Налаштування, що впливають на бекенд-логіку
Не обов'язково синхронізувати:
- Локальні налаштування UI (тема, розмір шрифту) — дешевше дати вибрати заново
- Кеш (буде відновлений автоматично)
- Тимчасові файли
Як реалізувати міграцію через QR-код?
Для застосунків без облікових записів — пряме перенесення через QR або числовий код. Старий пристрій генерує тимчасовий токен або зашифрований payload, новий пристрій його сканує. Код одноразовий і має обмежений термін дії (зазвичай 10 хвилин). Шифрування даних — AES-256, ключ передається через захищений канал. Це гарантує безпечну міграцію без сервера.
// Генерація коду міграції class MigrationCodeGenerator(private val exportManager: DataExportManager) { suspend fun generateMigrationCode(): MigrationCode { val exportedData = exportManager.exportUserData() val encryptedPayload = encryptWithTemporaryKey(exportedData) // Або відправляємо на сервер і отримуємо короткий код val code = api.createMigrationSession( payload = encryptedPayload, expiresIn = 10 * 60 // 10 хвилин ) return MigrationCode( code = code.shortCode, // "ABCD-1234" qrData = code.qrPayload, // для QR-коду expiresAt = code.expiresAt ) } } // Імпорт на новому пристрої suspend fun importFromCode(code: String): ImportResult { return try { val session = api.getMigrationSession(code) if (session.isExpired) return ImportResult.Expired val data = decryptPayload(session.encryptedPayload, session.tempKey) importManager.applyUserData(data) api.invalidateMigrationSession(code) // одноразовий — одразу інвалідируємо ImportResult.Success } catch (e: Exception) { ImportResult.Error(e.message) } } Важно перевіряти цілісність даних після розшифровки: використовуйте контрольну суму або HMAC. Час життя коду має бути мінімальним, щоб знизити ризик перехоплення.
Пряме peer-to-peer перенесення
Для конфіденційних даних, які не повинні проходити через сервер, використовуємо прямий канал між пристроями. На iOS — MultipeerConnectivity (WiFi Direct або Bluetooth), на Android — Nearby Connections API (Google Play Services). Швидкість передачі по WiFi Direct — 20–50 МБ/с проти 1–5 МБ/с через інтернет, що критично для великих обсягів (фото, файли). Час передачі 500 МБ даних по P2P менше 30 секунд.
// iOS: ініціація сесії MultipeerConnectivity let peerID = MCPeerID(displayName: UIDevice.current.name) let session = MCSession(peer: peerID, securityIdentity: nil, encryptionPreference: .required) let advertiser = MCNearbyServiceAdvertiser(peer: peerID, discoveryInfo: ["appVersion": Bundle.main.appVersionString], serviceType: "myapp-migrate") Як відновити покупки після зміни пристрою?
Apple та Google зберігають історію покупок на своєму боці. Кнопка «Відновити покупки» обов'язкова за App Store Review Guidelines (Section 3.1). 98% користувачів успішно відновлюють покупки при правильній реалізації.
// iOS: відновлення покупок StoreKit 2 for await result in Transaction.currentEntitlements { switch result { case .verified(let transaction): await updatePurchasedProducts(transaction.productID) case .unverified: break // підозріла транзакція } } // Android: BillingClient billingClient.queryPurchasesAsync( QueryPurchasesParams.newBuilder() .setProductType(BillingClient.ProductType.SUBS) .build() ) { billingResult, purchases -> if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) { purchases.forEach { purchase -> if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED) { grantEntitlement(purchase.products) } } } } Порівняння методів міграції
| Метод | iOS | Android | Коли використовувати |
|---|---|---|---|
| Cloud Backup | iCloud Backup | Google One Backup | Застосунки з авторизацією |
| Peer-to-Peer | MultipeerConnectivity | Nearby Connections | Конфіденційні або великі дані |
| QR/Код | Custom | Custom | Застосунки без акаунта |
| Server Sync | REST/GraphQL | REST/GraphQL | Завжди, якщо є сервер |
Поширені помилки
- Перенесення без валідації версії: дані із застосунку v1.0 імпортуються у v3.5 без міграції схеми — креб або некоректний стан.
- Незашифрований QR: QR-код містить plaintext дані користувача — хтось може сфотографувати екран.
- Не інвалідирується міграційний токен: код можна використовувати повторно — дані витечуть на третій пристрій.
Що входить в роботу з міграції даних
| Етап | Результат |
|---|---|
| Аналіз поточної схеми даних | Документація по структурі даних, виявлення критичних полів |
| Проектування архітектури міграції | Вибір методів (сервер, QR, P2P), протоколи шифрування |
| Реалізація експорту | Безпечне вивантаження даних на старому пристрої |
| Реалізація імпорту та валідації | Завантаження на новий пристрій з перевіркою цілісності |
| Тестування крайових випадків | Переривання передачі, часткові дані, версіонування схем |
| Адаптація під гайдлайни | App Store Connect, Google Play Console — відповідність вимогам |
Додатково надаємо документацію з інтеграції, навчаємо вашу команду та даємо гарантію на 12 місяців. Економія на підтримці після впровадження міграції сягає 50% бюджету техпідтримки.
Процес роботи
- Аналіз — вивчаємо поточну модель даних, визначаємо, що потрібно переносити.
- Проектування — вибираємо відповідний метод (серверна синхронізація, QR, P2P або комбінацію).
- Реалізація експорту — пишемо код для безпечного вивантаження з шифруванням та контролем версій.
- Реалізація імпорту — завантаження з валідацією, обробка дублів та старих версій.
- Тестування — перевіряємо переривання з'єднання, часткову передачу, міграцію з різних версій.
- Деплой та моніторинг — публікуємо оновлення в сторах, відстежуємо помилки.
Терміни: від 2 до 4 тижнів залежно від складності. Вартість розраховується індивідуально. Наші інженери допоможуть підібрати оптимальний метод. Зв'яжіться з нами для консультації та оцінки вашого проєкту. Отримайте консультацію з міграції даних — ми допоможемо оцінити складність та вибрати метод.







