Strategies for synchronizing data to WatchOS using SyncEngine

[scogeo]

I have the need to sync data to Apple Watch via CloudKit. I have a prototype working of this using SwiftData and would like to explore the equivalent in SqliteData.

The primary design constraint is to synchronize a subset of data to the watch due to storage and connectivity limitations. In my SwiftData prototype this is accomplished by syncing a subset of the data models to the watch, and only synchronizing all the data to iOS devices that have the storage capacity to support the full data set.

For the purposes of this discussion, I will use the Reminders example app to keep things simple. Suppose we wanted to synchronize the reminders to the watch, but not include the RemindersListAsset table due to concern about the image sizes.

Would it be sufficient to just not include the RemindersListAsset when creating the SyncEngine as follows and not impact synchronization for iOS devices.

extension DependencyValues {
  mutating func bootstrapDatabase() throws {
    defaultDatabase = try Reminders.appDatabase()
#if os(watchOS)
    defaultSyncEngine = try SyncEngine(
      for: defaultDatabase,
      tables: RemindersList.self,
      Reminder.self,
      Tag.self,
      ReminderTag.self
    )
#else
   defaultSyncEngine = try SyncEngine(
      for: defaultDatabase,
      tables: RemindersList.self,
      RemindersListAsset.self,
      Reminder.self,
      Tag.self,
      ReminderTag.self
    )
#endif
  }
}

There could obviously be more complicated use cases where there are Apple Watch specific tables that contain a subset of the reminders appropriate for the watch app and are kept in sync with the main tables via triggers, etc.

But I wanted to confirm that such a design approach is sound and would not cause issues in syncing for other devices or create any type of "pending" sync issues on the watch.

[mbrandonw]

Hi @scogeo,

Would it be sufficient to just not include the RemindersListAsset when creating the SyncEngine as follows and not impact synchronization for iOS devices.

As far as I can tell this should work just fine. This of course will not prevent the assets from being sent to the watch from CloudKit, though I imagine the same is true of your SwiftData prototype too. But at the very least that data will not be stored to the local SQLite database. The sync engine will keep around an UnsyncedRecordID for those rows so that if ever someday you do decide to add RemindersListAsset to the watch app sync engine you will properly backfill those rows. But I think that is OK since each row is only 3 strings.

I will also say that even if you are not synchronizing a table to CloudKit you probably should still create the table in your local database schema. The reason for this is that it allows all of your queries to gracefully degrade on the watch app. For example, you wouldn't want to have to do an #if os(watchOS) check on a query that wants to join to the RemindersListAsset table. Instead you should just be free to join to that table whenever you want, while knowing that many on the watch app it will just be empty.

There could obviously be more complicated use cases where there are Apple Watch specific tables that contain a subset of the reminders appropriate for the watch app and are kept in sync with the main tables via triggers, etc.

Theoretically it could be possible to use #if watchOS to omit certain fields from your @Tables for your watch app, and that would have the affect of your watch app not storing those fields locally when it receives a CKRecord from CloudKit. However, #ifs don't currently work with the @Table macro and it is significant work to make them work, so we are not prioritizing that anytime soon.