iCloud に不満を抱き、Apple の開発者コミュニティが一斉に声を上げるiCloud に不満を抱き、Apple の開発者コミュニティが一斉に声を上げる

10年前、マックス・ゼーレマンがまだ学生だった頃、執筆ツール「Ulysses」と「The Soulmen」を発表しました。以前のWWDCインタビューで、彼はTMOのデイブ・ハミルトンにOS Xアプリの進化について語りました。そして、スマートで技術的な変化がiPad用編集アプリ「Daedalus」へとどのように繋がったかについても語りました。また、間もなく刷新される「Ulysses III」のプレビューも披露してくれました。

その後、Ulysses IIIの開発過程で、Appleの開発者向けiCloud APIの使用時に深刻な同期問題が発生しました。今春Ulysses IIIがリリースされた後、TMO向けのアプリレビューの過程でこの問題が議論されたため、Seelemann氏にお話をお伺いしました。インタビューの内容はこちらです。

________________________

John Martellaro:この iCloud API 問題について、全体像を把握するために背景を少し教えていただけますか?

Max Seelemann: Ulysses IIIはドキュメントベースのシューボックスアプリとして設計されています。iCloudに透過的に保存される単一のドキュメントライブラリです。保存と同期はユーザーから完全に見えないようになっています。ファイル名、開いているウィンドウ、保存ダイアログはありません。iCloudのドキュメントストアは自然な流れで動作しますが、私たちの設計ではNSDocumentのような一般的な便利な機能を利用できませんでした。標準コンポーネントは、従来のドキュメントベースアプリケーションにあまりにも忠実にモデル化されています。さらに、私たちのニーズには柔軟性に欠け、重すぎました。

マックス・ゼーレマン

JM:最初の問題はどうやって発生したのですか?

MS:低レベルのNSFileCoordinator APIを使って独自のiCloudレイヤーを実装する必要があることは、当初から明らかでした。しかし、そうすることで、ロスレス保存の保証、iCloudとの連携、バージョンの適用、利用可能なすべてのドキュメントをユーザーに表示することなど、システムが通常行うすべての処理を自分たちで行わなければならなくなりました。さらに、設計上、手動でファイルを並べ替えるためのメタデータを保存し、大量のファイルを一度に移動、コピー、削除するためのクラウドセーフな手段も必要でした。

これは非常に複雑な作業です。対処すべき状況が数多くあります。競合する変更（2台のMacで同じドキュメントを編集する）、互換性のない操作（同じシートを2つの異なるフォルダに移動する）、そして調整が必要な作業（ドキュメントの移動中は保存できない）などを考えてみてください。高速かつ最新の処理を実現したい場合は、マルチコアプロセッサを使用し、すべてをバックグラウンドスレッドで実行する必要があります。

どれほどの作業量だったか、数字で表してみましょう。Ulysses に同梱されているストレージレイヤーの開発には、2人のエンジニアがそれぞれ半年を費やしました。数万行のコードと、ほぼ同量のテストで構成されています。自宅で気軽にできるようなものではありません。

JM: Apple の iCloud API はどこから機能不全に陥るのでしょうか?

私たちにとって最も厄介だったのは、AppleのNSFileCoordinator APIの理解と、それに伴う数々の問題でした。問題は、見た目はシンプル、メソッドももちろんシンプル、ドキュメントも分かりやすく書かれているものの、使い方は全くシンプルではないということです。振り返ってみると、システム全体がAppleの標準的な用途のみを想定してテストされている印象を受けます。つまり、ユーザーが管理する単層のフォルダで、時折、少数のモノリシックファイルを開いたり、保存したり、名前を変更したりするような用途です。Pag​​es、Keynote、従来のドキュメントベースのアプリです。しかし、基盤となるAPIはより幅広い用途や高度な状況を想定して設計され、ドキュメント化されているものの、そのような使い方をするとすぐに機能しなくなります。

例えば、監視対象フォルダ（NSFilePresenter）内のファイルの追加と削除に関する通知があります。通知は存在し、ドキュメントにも記載されているものの、実際には一度も呼び出されていません。私たちの責任かもしれませんが、これらの通知が呼び出された例を一度も見たことがありません。最終的に、追加および削除されたファイルを検出する独自の方法を構築しました。iCloudディレクトリの内容の更新を取得する別の方法（Spotlight経由）があり、これはAppleが標準のiCloudオープンウィンドウで使用している方法とほぼ同等です。そのため、通知システムは遅れをとってしまったのです。

JM:これまでの最大の課題は何でしたか?

MS:これまで私たちが抱えてきた最大の問題、そして完全に解決できるかどうか疑問に思っている問題は、開発者フレームワーク外での実装にあります。開発者が直面する問題に加え、iCloud のドキュメント同期は、バックグラウンドで動作する複数のシステムプロセスによって構成されています。

これらはすべて文書化されていないため、現時点での理解のみをお伝えします。まず、ubdというプロセスがあります。これはAppleのクラウドサーバーと実際に通信し、アップデート通知を取得し、ファイルを分割して転送するなどを行います。librariandは、現在利用可能なファイルのリスト、同期状態、進行中の転送を管理し、これらすべてをSpotlightに公開するプロセスです。そして最後に、filecoordinationdがあります。これは、一度に1つのアプリだけがファイルに書き込みを行うことを保証するファイルロックメカニズムです。これは、前述のファイル通知システムのシステム部分でもあります。

さて、階層が深くなり、ファイル数が多くなり、変更も大量に発生すると、すぐに問題が発生し始めます。3つのサブシステムそれぞれが壊れ、システムの再起動やiCloudの無効化/有効化が追いつかない状況も経験しています。数百個のパッケージを追加し、いくつかを開いてバックグラウンドプロセスを実行し、ファイルを移動させ始めると、ファイル連携が確実に機能しなくなります。私たちの経験では、ファイル変更の報告がランダムに停止するだけです。ファイルアクセスが全く許可されないこともあります。フォルダの削除は、場合によっては試行錯誤を繰り返し、中止して再試行する必要があります。

これらの問題の大部分は私たちの責任かもしれませんし、確かに一部はそうかもしれません。開発中に、コード内に数百もの潜在的な誤用を発見し、修正しました。問題は、これらのAPIが内部でどのように動作するのかについてのドキュメントが存在しないことです。すべてが単純なシナリオと単一ファイルへのアクセスで完結しています。これはある程度理にかなっています。なぜなら、Appleのデフォルト実装がまさにそうしているからです。

数ヶ月間試行錯誤した結果、フォールバック機構を実装することにしました。アプリがファイルコーディネーションからの通知を受け取れなくなった場合に備えて、Spotlightから取得した情報からファイルの変更を手動で解析します。この更新はSpotlightほど正確で即時性はありませんが、何もしないよりははるかに優れています。両方の機構が同時に機能しなくなることは極めて稀だと判断しました。

JM:これまで一生懸命頑張ってきましたが、今はどうですか?

MS:リリースから数週間が経ちましたが、私たちの実装はかなりうまく機能しているようです。iCloud に関する問題の報告はごく少数で、そのほとんどはシステムの再起動、または iCloud のドキュメント同期のオン/オフを切り替えることで解決できます。システムの再起動後も同期が完全に失敗するという状況は、ごく少数のユーザーで発生しました。最近、文書化されていないコマンドラインツールを発見しましたが、これは最も深刻なハングアップさえも解決できるようです。

iCloud が一度使い始めると、本当に素晴らしいと断言できます。デバイスに数秒で変更が反映されるのを見るのは、まさに魔法のようです。そこに到達するまでには、私たちにとって大変な苦労がありました。私たちが望むのは、iCloud システム全体の信頼性と安定性が向上することです。今のところ、新しい機能は必要ありません。私たちのような高負荷な使用状況でも、既存の機能がスムーズに動作してくれるようになれば完璧です。

JM:開発者の問題を理解する上で、本当に助かりました。数週間後には、WWDCでAppleに集まる開発者の方々もきっと多く、同じような問題について議論することになると思います。

___________________

この開発者問題に関する追加的で優れた背景情報は次のとおりです。「iCloudに不満を抱き、Appleの開発者コミュニティが一斉に声を上げる」