Синхронизация iCloud: CloudKit и NSUbiquitousKeyValueStore

Отметим: когда пользователь меняет iPhone, данные приложения должны появиться на новом устройстве автоматически. Иначе — потеря клиента. Мы интегрируем синхронизацию iCloud через три механизма: NSUbiquitousKeyValueStore, CloudKit и iCloud Documents (UIDocument). Каждый решает свою задачу, но для сложной синхронизации с минимальными задержками лучше всего подходит CloudKit. Синхронизация данных через iCloud — не просто перенос файлов, а сложный процесс с дельтами, конфликтами и ограничениями хранилища. Без правильной архитектуры пользователь теряет прогресс, настройки или заметки при смене устройства.

Один из наших проектов — приложение для заметок с многопользовательским редактированием. Первая версия использовала полную выгрузку всех записей при каждом запуске. Трафик превышал 10 МБ на пользователя в день. Переход на дельта-синхронизацию с serverChangeToken сократил передаваемые данные до 1 МБ — снижение на 90%. Пользователи перестали жаловаться на медленную загрузку, а количество запросов к CloudKit уменьшилось в 10 раз.

Когда использовать NSUbiquitousKeyValueStore, CloudKit или iCloud Documents?

Apple предоставляет 10 МБ бесплатного хранилища CloudKit на пользователя, дополнительный 1 ГБ стоит $0.99 в месяц. Экономия на трафике от дельта-синхронизации может сократить затраты на запросы в 5 раз.

NSUbiquitousKeyValueStore

Самый простой вариант — для небольших конфигурационных данных. Лимит 1 МБ на всё хранилище, 1024 ключа, до 256 КБ на ключ. Синхронизируется автоматически, без кода синхронизации.

let store = NSUbiquitousKeyValueStore.default

// Запись
store.set(userId, forKey: "lastUserId")
store.set(["theme": "dark", "fontSize": 16], forKey: "userSettings")
store.synchronize() // запрашивает немедленную синхронизацию, не гарантирует

// Чтение
let theme = store.string(forKey: "userSettings.theme") ?? "light"

// Подписка на изменения с других устройств
NotificationCenter.default.addObserver(
    self,
    selector: #selector(iCloudDidChange),
    name: NSUbiquitousKeyValueStore.didChangeExternallyNotification,
    object: NSUbiquitousKeyValueStore.default
)

@objc func iCloudDidChange(_ notification: Notification) {
    guard let keys = notification.userInfo?[NSUbiquitousKeyValueStoreChangedKeysKey] as? [String]
    else { return }
    // Обновляем локальное состояние для изменённых ключей
    keys.forEach { updateLocalState(forKey: $0) }
}

Идеально для настроек. Для прогресса игры, заметок, файлов — CloudKit.

Почему выбирают CloudKit для сложной синхронизации?

CloudKit — полноценная база данных в iCloud. Три типа хранилищ:

import CloudKit

class CloudKitManager {
    let container = CKContainer(identifier: "iCloud.com.company.appname")
    var privateDB: CKDatabase { container.privateCloudDatabase }

    // Сохранение заметки
    func saveNote(_ note: Note) async throws {
        let record = CKRecord(recordType: "Note",
                              recordID: CKRecord.ID(recordName: note.id))
        record["title"] = note.title as CKRecordValue
        record["content"] = note.content as CKRecordValue
        record["modifiedAt"] = Date() as CKRecordValue
        record["isPinned"] = note.isPinned as CKRecordValue

        let savedRecord = try await privateDB.save(record)
        print("Saved: \(savedRecord.recordID.recordName)")
    }

    // Загрузка всех заметок
    func fetchAllNotes() async throws -> [Note] {
        let predicate = NSPredicate(value: true)
        let query = CKQuery(recordType: "Note", predicate: predicate)
        query.sortDescriptors = [NSSortDescriptor(key: "modifiedAt", ascending: false)]

        let (results, _) = try await privateDB.records(matching: query)
        return results.compactMap { (_, result) in
            guard let record = try? result.get() else { return nil }
            return Note(
                id: record.recordID.recordName,
                title: record["title"] as? String ?? "",
                content: record["content"] as? String ?? "",
                isPinned: record["isPinned"] as? Bool ?? false
            )
        }
    }
}

Как настроить дельта-синхронизацию: пошаговая инструкция

1. Создайте подписку на изменения записей (CKQuerySubscription) — это позволит получать silent push при каждом изменении.

   func setupSubscription() async throws {
       let predicate = NSPredicate(value: true)
       let subscription = CKQuerySubscription(
           recordType: "Note",
           predicate: predicate,
           subscriptionID: "notes-changes",
           options: [.firesOnRecordCreation, .firesOnRecordUpdate, .firesOnRecordDeletion]
       )
   
       let notificationInfo = CKSubscription.NotificationInfo()
       notificationInfo.shouldSendContentAvailable = true // silent push
       subscription.notificationInfo = notificationInfo
   
       try await privateDB.save(subscription)
   }
   

2. Реализуйте обработку push-уведомлений в AppDelegate — при получении silent push вызывайте метод fetchChanges().

   func application(_ application: UIApplication,
                    didReceiveRemoteNotification userInfo: [AnyHashable: Any]) async -> UIBackgroundFetchResult {
       let notification = CKNotification(fromRemoteNotificationDictionary: userInfo)
       if notification?.containerIdentifier == "iCloud.com.company.appname" {
           await cloudKitManager.fetchChanges()
           return .newData
       }
       return .noData
   }
   

3. Используйте CKFetchRecordZoneChangesOperation с serverChangeToken — загружайте только изменённые записи.

   func fetchChanges() async throws {
       let zone = CKRecordZone(zoneName: "NotesZone")
       var config = CKFetchRecordZoneChangesOperation.ZoneConfiguration()
       config.previousServerChangeToken = UserDefaults.standard
           .data(forKey: "notesZoneChangeToken")
           .flatMap { try? NSKeyedUnarchiver.unarchivedObject(ofClass: CKServerChangeToken.self, from: $0) }
   
       let operation = CKFetchRecordZoneChangesOperation(
           recordZoneIDs: [zone.zoneID],
           configurationsByRecordZoneID: [zone.zoneID: config]
       )
   
       operation.recordWasChangedBlock = { _, result in
           guard let record = try? result.get() else { return }
           Task { await self.localStore.upsert(record) }
       }
   
       operation.recordWithIDWasDeletedBlock = { recordID, _ in
           Task { await self.localStore.delete(id: recordID.recordName) }
       }
   
       operation.recordZoneFetchResultBlock = { _, result in
           guard case .success(let info) = result else { return }
           // Сохраняем токен для следующей дельта-синхронизации
           if let tokenData = try? NSKeyedArchiver.archivedData(
                   withRootObject: info.newServerChangeToken, requiringSecureCoding: true) {
               UserDefaults.standard.set(tokenData, forKey: "notesZoneChangeToken")
           }
       }
   
       privateDB.add(operation)
   }
   

Как избежать конфликтов при одновременном редактировании?

CloudKit не решает конфликты автоматически для Custom Zones. При save по существующему recordID, если recordChangeTag не совпадает — ошибка serverRecordChanged. Нужен ручной merge. Мы используем стратегию last-writer-wins или трёхстороннее слияние. Вот обработчик конфликта:

// В блоке save с CKModifyRecordsOperation
operation.perRecordSaveBlock = { recordID, saveResult in
    if case .failure(let error) = saveResult {
        if let ckError = error as? CKError, ckError.code == .serverRecordChanged {
            let serverRecord = ckError.userInfo[CKRecordChangedErrorServerRecordKey] as! CKRecord
            let clientRecord = ckError.userInfo[CKRecordChangedErrorClientRecordKey] as! CKRecord
            // Разрешаем конфликт: берём последнюю версию
            serverRecord["modifiedAt"] = Date()
            operation.recordsToSave = [serverRecord]
        }
    }
}

Что входит в работу

Сроки: от 2 до 4 недель. Стоимость рассчитывается индивидуально. Получите консультацию — мы оценим ваш проект за один день. Свяжитесь с нами, чтобы обсудить детали.

Мы занимаемся iOS-разработкой более 10 лет, реализовали 30+ проектов с синхронизацией через CloudKit. Гарантируем бесшовную синхронизацию между устройствами в течение 24 часов после деплоя. Закажите интеграцию CloudKit уже сегодня и избавьтесь от проблем с синхронизацией.

Apple CloudKit Documentation

Как выбрать решение для локального хранения данных (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 недель в зависимости от сложности схемы и требований к конфликт-резолюции. Стоимость рассчитывается индивидуально после аудита вашего проекта. Закажите разработку под ключ — получите консультацию по выбору оптимального стека и миграциям.