Реалізація перенесення даних при зміні пристрою (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)
            }
        }
    }
}

Порівняння методів міграції

Поширені помилки

• Перенесення без валідації версії: дані із застосунку v1.0 імпортуються у v3.5 без міграції схеми — креб або некоректний стан.
• Незашифрований QR: QR-код містить plaintext дані користувача — хтось може сфотографувати екран.
• Не інвалідирується міграційний токен: код можна використовувати повторно — дані витечуть на третій пристрій.

Що входить в роботу з міграції даних

Додатково надаємо документацію з інтеграції, навчаємо вашу команду та даємо гарантію на 12 місяців. Економія на підтримці після впровадження міграції сягає 50% бюджету техпідтримки.

Процес роботи

1. Аналіз — вивчаємо поточну модель даних, визначаємо, що потрібно переносити.
2. Проектування — вибираємо відповідний метод (серверна синхронізація, QR, P2P або комбінацію).
3. Реалізація експорту — пишемо код для безпечного вивантаження з шифруванням та контролем версій.
4. Реалізація імпорту — завантаження з валідацією, обробка дублів та старих версій.
5. Тестування — перевіряємо переривання з'єднання, часткову передачу, міграцію з різних версій.
6. Деплой та моніторинг — публікуємо оновлення в сторах, відстежуємо помилки.

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

Як вибрати рішення для локального зберігання даних (Room, Core Data, Realm, Isar)?

Ми стикалися з ситуацією, коли додаток втрачає дані при втраті мережі — і це не просто баг, це провал сценарію. Користувач заповнив форму, натиснув «Відправити», отримав таймаут і втратив все. Або гірше: дані відправилися двічі через некоректну логіку повторної відправки. Правильно вибраний та налаштований шар сховища вирішує цю проблему раз і назавжди. Неправильний вибір може коштувати команді місяців переписування коду та втрати до 70% часу на синхронізацію. Наш досвід — 10+ років у мобільній розробці, понад 50 проектів з офлайн-сховищами — підтверджує: вибір рішення визначає 80% майбутніх проблем з продуктивністю та синхронізацією.

На практиці вибір сховища визначається двома факторами: типом даних та вимогами до синхронізації, а не популярністю бібліотеки.

Room (Android) — обгортка над SQLite з compile-time верифікацією SQL-запитів. Якщо запит невалідний, збірка падає — це краще, ніж SQLiteException в рантаймі. Room добре інтегрується з Kotlin Flow та LiveData, що робить реактивні UI-оновлення прямолінійними. Основна складність — міграції схеми. @Database(version = N, exportSchema = true) з файлами міграцій в assets/databases/ — обов'язкова практика, інакше при оновленні додатка fallbackToDestructiveMigration() просто зітре дані користувача.

Core Data (iOS) — не база даних, а фреймворк управління графом об'єктів поверх SQLite (або XML, або in-memory). NSPersistentContainer з viewContext для читання на main thread та newBackgroundContext() для запису — базова схема. Проблема починається, коли розробник робить save() в viewContext з фонового потоку: EXC_BAD_ACCESS в рандомний момент, відтворюється раз на тиждень, в крешлозі майже нічого корисного. Потрібно використовувати performAndWait або perform для кожного контексту строго в своєму потоці. Apple Core Data Programming Guide рекомендує саме такий підхід.

Realm виграє там, де потрібна швидкість роботи з великими наборами об'єктів та вбудована реактивність через Results + observe(). Realm зберігає об'єкти напряму, без маппінгу ORM, тому читання не потребує десеріалізації. За нашими вимірами, Realm обробляє читання в 2–3 рази швидше Core Data при об'ємі понад 10 000 об'єктів. На Flutter Realm SDK (ex-MongoDB Realm) підтримує Device Sync — але це вже managed-сервіс з окремою інфраструктурою.

Hive та Isar — Flutter-специфічні рішення. Hive — key-value сховище, швидко, просто, підходить для налаштувань та кешів. Isar — повноцінна документо-орієнтована БД з індексами, написана на Rust, компілюється в нативний код. Для Flutter-додатків з офлайн-функціональністю Isar зараз переважніше: вбудований query builder з типобезпечними фільтрами, транзакції, watchObject/watchQuery для реактивності.

Зв'яжіться з нами, щоб отримати безкоштовний аудит вашого поточного сховища та рекомендації з оптимізації — це зекономить вам сотні годин розробки та до 60% трафіку на серверні запити.

Чому офлайн-синхронізація — найскладніша частина?

Локальне сховище саме по собі нескладне. Складність — у синхронізації з сервером при наявності конфліктів.

Найчастіший патерн — optimistic updates з rollback. Користувач редагує запис, UI відображає зміну миттєво, фоновий запит йде на сервер. Якщо сервер повертає помилку — відкочуємо локальний стейт. Виглядає просто. На практиці: якщо користувач встиг піти з екрану і повернутися, а відкат відбувся через 3 секунди — UX зламаний. Потрібна явна черга операцій зі станом (PENDING, SYNCED, FAILED) в окремій таблиці.

На Android для фонової синхронізації використовуємо WorkManager з Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED). Важно не забыть про setInputMerger(ArrayCreatingInputMerger::class) при батчинге задач — інакше при кількох одночасних запусках дані затираються. Типова реалізація черги операцій:

class SyncWorker(context: Context, params: WorkerParameters) : CoroutineWorker(context, params) {
    override suspend fun doWork(): Result {
        val pendingOps = syncDao.getPendingOperations()
        for (op in pendingOps) {
            try {
                apiClient.send(op.payload)
                syncDao.markSynced(op.id)
            } catch (e: Exception) {
                syncDao.markFailed(op.id, e.message)
                return Result.retry()
            }
        }
        return Result.success()
    }
}

На iOS аналог — BGTaskScheduler з BGProcessingTaskRequest. Обмеження iOS на фоновий час виконання (~30 секунд для refresh tasks) означають, що синхронізація повинна бути інкрементальною: не «синхронізувати все», а «синхронізувати наступні N записів, зберегти курсор».

Конфлікти при мультипристроєвій роботі вирішуються одним із трьох підходів:

• Last-write-wins по updated_at (найпростіший, втрачає дані при одночасному редагуванні)
• Server-wins (клієнт завжди приймає серверну версію)
• Three-way merge (складно, потрібен спільний предок — підходить для документів)

У більшості B2C-додатків достатньо last-write-wins з вектором часу на рівні користувача, але при спільному редагуванні потрібен CRDTs-підхід — тоді дивимося на Automerge або Yjs з мобільними біндингами.

Як ми будуємо шар сховища

Репозиторний патерн — не опціональний, а обов'язковий. UserRepository не знає, звідки дані: з Room, Realm чи мережі. ViewModel викликає repository.getUser(id), отримує Flow/Stream, відображає дані. Логіка кешування — всередині репозиторія.

Для Flutter типова архітектура: Isar для персистентності, Riverpod для управління стейтом, ConnectivityPlus для визначення стану мережі, кастомний SyncService з чергою операцій. Riverpod AsyncNotifier зручно покриває логіку «показати кеш, оновити з мережі, показати нові дані». Приклад репозиторія з кешуванням:

class UserRepository {
  final Isar isar;
  final ApiClient api;

  Future<User> getUser(String id) async {
    // 1. спробувати з локального сховища
    final cached = await isar.user.where().idEqualTo(id).findFirst();
    if (cached != null) return cached;
    // 2. інакше з мережі
    final remote = await api.fetchUser(id);
    // 3. зберегти локально
    await isar.writeTxn(() => isar.user.put(remote));
    return remote;
  }
}

Окрема тема — шифрування. Якщо додаток зберігає медичні дані, платіжні картки або корпоративні документи, SQLCipher (Android) та NSFileProtection (iOS) — не опція. Realm підтримує шифрування нативно через ключ у 64 байти, який потрібно зберігати в Keychain/Keystore, а не в SharedPreferences. Економія на безпеці може обійтися у витік даних з гучними наслідками.

Що входить в роботу

Ми гарантуємо прозорий процес і фіксуємо кожен етап:

Бажаєте уникнути типових помилок при проектуванні сховища? Зверніться до нас — ми допоможемо спроектувати надійне локальне сховище з нуля або доопрацювати існуюче.

Які етапи роботи?

Починаємо з аудиту вимог: які дані, який обсяг, чи потрібна синхронізація, чи можливі конфлікти. На цьому етапі стає зрозуміло, Core Data чи SQLite-based рішення, чи потрібен Realm Sync або достатньо простого REST-поллінгу.

Далі — проектування схеми з урахуванням міграцій. Схему змінюють у будь-якому проекті — питання не «чи будуть міграції», а «наскільки болісно вони пройдуть». Експортуємо схему в JSON, зберігаємо в репозиторії, пишемо тести на міграцію кожної версії.

Розробка йде з покриттям репозиторного шару юніт-тестами: моки мережевого шару, реальна in-memory база для тестування запитів. Перед релізом — профілювання запитів через Android Profiler (вкладка Database Inspector) або Core Data debug флаги (-com.apple.CoreData.SQLDebug 1).

Термін реалізації шару сховища з базовою офлайн-синхронізацією — від 2 до 6 тижнів залежно від складності схеми та вимог до конфлікт-резолюції. Вартість розраховується індивідуально після аудиту вашого проекту. Замовте розробку під ключ — отримайте консультацію з вибору оптимального стеку та міграціям.