iCloud 同期の最小アーキ（家族共有の実装候補）

2026/9/17

背景与問題

OPC（B 方向）。家族で同じデータを共有する機能（親と家族が同じ台帳を見る）を実装する場合、自前バックエンドは重い。Apple 純正の CloudKit 同期（NSPersistentCloudKitContainer）が「実費ほぼゼロ」で家族共有まで届くかを、先人の教訓から判定する。

（出典はいずれも 2026-09-17 アクセス）

NSPersistentCloudKitContainer は「実費ほぼゼロ」でクラウド同期を提供——indie 開発者の 8 年間の回顧で、保守コストの低さが繰り返し確認されている（Fatbobman「My Eight Years with CloudKit」）。
ログイン不要の家族共有が実装可能：二人のユーザー（両親など）が同じデータを共有・同期する構成の実装体験談がある（r/iOSProgramming の教訓まとめ）。
既知の罠：起動時にしか同期されない問題——Remote Notifications Background Mode の有効化が解（cdf1982 の実例解説）。デバッグは Apple 公式 TN3164 がある（Apple TN）。
共有 DB（他人と共有）は personal DB より手間が増える。抽象の限界が出たら CKSyncEngine へ（Superwall 解説）。「無料同期で indie の大半は足りる」という評価（Medium）。

家族共有の最小構成を確定：CloudKit shared DB + NSPersistentCloudKitContainer。アカウントシステムを作らない（Apple ID の iCloud に乗る）——solo の保守面積が最小（実例あり）。
既知の罠を設計に先入れ：Remote Notifications を有効化（起動時のみ同期の罠の解、事実）。デバッグ手順は TN3164 をブックマーク。
同期衝突ルールは c-offline-first-emerging と共通化：役割優先（家族>親）+後勝ち+履歴。2 つの課題で同期の考えを一つに揃える。
抜け出し基準を先に決める：container の抽象（クエリ・共有の複雑さ）で足りなくなったら CKSyncEngine——最初からは使わない。Android 側は別解（CloudKit 不可）なので Android 版の共有は Web 版か諦めるかを別判断に（推测）。