複数のユーザーが同じCloudKitレコードを同時に編集できるソーシャルメディアアプリケーションを構築しています。一度に1人のユーザーしか編集できないようにロック機構を実装する必要がありますか（これらの編集は互いに競合する可能性があります）、CloudKitにはこれに対処するための便利な組み込み方法がありますか？複数のユーザーが同じCloudKitレコードを編集する
ロック機構を実装すると、編集可能なレコードにバイナリ属性を追加することになります。この属性の値は、誰かが編集している場合は1、現在編集していない場合は0になります。これは妥当な方法のようですか？
Cloudkitには、これを管理するための変更トークンというメカニズムがあります。これは、レコードが変更されるたびに更新されるタイムスタンプと似ています。書き込もうとすると、最後に変更したトークンが新しいデータと共にサーバーに渡されます。最後のライターが常に上書きするなど、サーバーがどのようにコリジョンを処理するかを指定するポリシーを設定できます。または、最後の作家が拒否されたこと。
後者の場合、2番目のライターはNSEエラーを受け取ります。そのエラーのuserInfoには、サーバーの現在のバージョン、送信しようとしたバージョン、共通の祖先という3つのバージョンのレコードが埋め込まれています。これにより、差異を比較し、適切なデータをマージして再保存することができます。または、レコードを再度フェッチして（変更トークンのバージョンを更新します）、再度保存してください。
WWDCクラウドキットの動画を視聴することをおすすめします。 WWDCセッション2014のセッション231、「Advanced Cloudkit」、WWDC 2015セッション715「Cloudkit Tips and Tricks」は、最も有益な情報を持っています。
これは古い質問ですが、レコードがまだ作成されていない場合は、この「変更トークン」の作業がありますか？レコードが一意のIDとして電話番号を使用し、別のフィールドとして名前を使用するとします。 2人はほぼ同じ時間に同じIDで異なる名前で送信します。実際に勝つのは1つだけです。 – DerrickHo328
@ DerrickHo328は変更トークンを最後の書き込みのタイムスタンプと考えます。それは完全に正確ではないかもしれませんが、この議論のためには十分に近いです。したがって、2人のユーザーが2つの変更を送信すると、成功した書き込みごとに変更トークンが更新されます。クラウドキットの衝突ポリシーを制御して、既存のレコードを常に上書きするか、または上で説明したようにそれを拒否することができます。 – Thunk