AppleのiCloudはCore Dataの同期問題で非難される

iCloudをMacおよびiOSユーザーのドキュメント、データ、メディアファイルの新しいデジタルハブにするというAppleの野心的な計画に対し、Appleがデータベース同期に関連する問題に対処すると信じていない開発者らから苦情が寄せられていると伝えられている。ただし、状況は改善されると考えられるという期待はあります。

問題を処理するために Apple が提供する選択肢が限られていることに不満を感じた複数のアプリ開発者は、主に以下の問題に焦点を当てた苦情をブログエントリを通じて公開しました。コアデータデータベースとの同期iCloud。

彼らの苦情はジャーナリストによって取り上げられ、これらの特定の限られたデータベース同期問題と Apple のオンライン サービス全体を混同することが多く、その結果、Apple を非難しながら、iCloud の傘全体が希望の見えない「壊れた」と宣言する見出しになった。 iCloudを「自動で簡単」と宣伝したため。

Apple の秘密主義は厳重な秘密主義のため、同社が特定の問題に対する修正をどれだけ早く発表するかを確実に予測することが難しく、自社の顧客からは iCloud のサポートの欠如や iCloud 内の同期の問題に対する苦情や低評価が降り注ぐにもかかわらず、開発者の計画は複雑になっている。開発者が iCloud のサポートを追加した後のアプリ。

「Apple には、iOS 7 で iCloud をすべて修正し、2 年経ってようやく問題なく使えるようになったと言ってもらいたいが、私は期待を裏切らない」と、ある匿名の iOS 開発者は伝えた。言った ザ・ヴァージ「なぜ iCloud は「うまく機能しない」のか?」という見出しの記事

さらに事態を複雑にしているのは、「iCloud」という言葉が、Apple が自社のオンライン サービスのほぼすべてをカバーするために曖昧に使用している非常に広範なマーケティング用語であるという現実です。

一般的に、「クラウド」とはインターネットを指し、多くの場合、特にネットワーク ベースのサービスを指しますが、最近ではファイルの単純な「クラウド ストレージ」も指します。 「iCloud」で起こっていることはすべて、メール、連絡先、カレンダーサービスを含むAppleのサーバー上で行われているだけです。開発者らはこれらのサービスを問題視しておらず、散発的な中断にもかかわらず、ユーザーからの異常な量の苦情は発生していない。

業界をリードする iTunes、iBooks、iOS のメディア コンテンツや Mac App Store ソフトウェアを含む、Apple のさまざまなデジタル ダウンロードおよびショッピング サービスも、「iCloud」の傘下にまとめられています。これは開発者が不満を抱いている iCloud でもない。

同社はまた、ユーザーのさまざまな Mac や iOS デバイスのいずれかから、場合によっては Web からアクセスできるように、ドキュメントを「クラウド」に保存する独自のアプリベースのファイル ストレージ サービスも提供しています。フォト ストリーム、Find My iPhone、Back to My Mac、およびその他のさまざまなデータ同期サービス (Safari ブックマークやリーディング リストなど) も、iCloud に関連する機能です。

これらの機能はいずれも、開発者が報告している iCloud の問題とは直接関係しておらず、その結果、Apple の便利で一般的に信頼できる (ただし完全ではない) iCloud が「壊れている」とは考えていない 2 億 5,000 万人のユーザーの多くに混乱をもたらしています。

Apple の iCloud の暗い、希望の光

サードパーティのアプリ開発者にとっての iCloud の主な問題は、独自のアプリとクラウドの間でデータベースを確実に同期する (およびデバイス間で同期を維持する) 問題に関連しています。これは、開発者がアプリ内のデータの管理と保存を簡素化し、ソフトウェア タイトルの独自の側面に集中できるようにするために設計された Apple フレームワークである Core Data によって処理されます。 Core Data 自体は、ほとんどの開発者の間で高く評価されています。

Apple は 2005 年の Mac OS X Tiger で Core Data を導入し、iOS 3.0 で App Store 開発者が Core Data を利用できるようにしました。 Core Data を使用すると、開発者はユーザーのデータをオブジェクトとして操作し、データの保存と取得の複雑さの多くを処理できるようになります。 Core Data フレームワークは、さまざまなタスクに適したデータを保存する方法のオプションを提供します。単純な XML テキスト ファイルまたはバイナリ データ (どちらも標準ファイルの例) として、あるいは SQLite データベース (組織化されたデータを含む特殊なファイル) 内に保存するかのいずれかです。特殊なトランザクションを介してアクセスおよび変更されます)。

Apple が iCloud を導入したとき、新しい「文書とデータCore Data フレームワークを使用したサービスの機能により、アプリが使い慣れたフレームワークを活用して、iCloud 経由でアプリのデータを保存および取得できるようになります。ドキュメントベースのデータ ファイルまたは単純な「キーと値のペア」（環境設定など）の場合、iCloudかなりうまく機能しているようです。

Apple の開発者向けドキュメントには、「iCloud の背後にある中心的な考え方は、デバイス間の明示的な同期を排除することです。ユーザーは同期について考える必要がなく、アプリが iCloud サーバーと直接対話することはありません。この記事で説明されているように iCloud ストレージ API を採用すると、ドキュメントに保存すると、変更は iCloud アカウントに接続されているすべてのデバイスに自動的に反映され、ユーザーはどこからでも個人コンテンツに安全かつ一貫性のある透過的なアクセスを得ることができます。」

実際にアプリに iCloud サポートを実装するのは簡単ではありません。 Apple 自体は、Mac OS X Mountain Lion に組み込まれているさまざまなアプリに iCloud サポートを追加するのに約 1 年を費やしましたが、iWork アプリの iOS バージョンと Mac バージョンの間で iCloud ベースのファイルを動作させるにはさらに時間がかかりました (下図)。

SQLite データベースに加えられた増分変更を iCloud と同期するというより野心的な取り組みはさらに複雑です。何人かの開発者は、これをまったく機能させるのにかなりのフラストレーションを感じていると報告しています。そして、彼らの取り組みは、ユーザーの予期せぬアクションによって複雑になっています。ユーザーは、たとえば、自分のデバイスで iCloud からログアウトし、新しいユーザーとしてログインする可能性があり、さらに複雑になります。状況に陥ってしまう。

Apple は自社アプリにドキュメントベースの iCloud 同期を実装していますが、同社も FileMaker 子会社も、iCloud と同期された SQLite データベースをあまり活用していないようです。また、Apple がまだそれを使用していない場合は、サードパーティの開発者向けにも洗練されていないと考えてよいでしょう。

イノベーションのためのキャッチ 22

Mac および iOS プラットフォームは、Core Data のアーキテクチャ (および iCloud との統合) に依存して、多くの革新的な機能を提供します。からのすべて自動保存to Versions (下記) to Time Machine は、ユーザーの作業を段階的に保存するという新しいコンセプトを活用して、リアルタイムでロールバック、アーカイブ、さらにはデバイス間で同期できるようにします。 Apple は過去数年にわたって、これらの機能 (およびその基礎となるフレームワーク) を展開し、段階的に強化してきました。

その間、Apple の批評家たちは、Apple がリリースした新しいハードウェアやソフトウェアのアップデートすべてにどれだけ感動していないのかについて不満を漏らしており、同時に Apple のしばしば積極的な計画の結果として生じた変化や成長痛についても不満を述べてきた。新しい機能を展開します。

Apple の iCloud ジレンマ (さらに広義には OS X と iOS に関するあらゆる問題) に対する別の解決策は、あらゆる面でイノベーションを大幅に縮小すること (競合他社が追いつくことを可能にするか、Apple は十分にイノベーションを行っていないという批評家たちの不満を増幅させること) のどちらかでしょう。 ');新しいソフトウェアや機能に対する厳しい批判を避けるために Google が行っているように、新しいソフトウェアの機能に「ベータ版」の警告を表示します (Apple が Siri で行ったように、これは実際の効果はありませんでした);または、さまざまなプロジェクトに取り組むために大規模なチームを編成する（開発が複雑になり、会社がすでに抱えている人員配置と運用上の問題が増加する）混雑したキャンパス資格のある経験豊富な開発者を雇用することの難しさ）。

本当の解決策は簡単ではない

モバイル開発プラットフォームで提供される唯一のクラウド同期リレーショナル データベース アーキテクチャを完成させることは、時間のかかる大仕事です。未完成、あるいは少なくとも洗練されていない現状では、サードパーティのアプリをそのようなシステムで動作させるのに苦労することも困難です。物事について文句を言うのははるかに簡単で、単純な解決策 (より多くの開発者を雇いましょう! 「とにかく使えるようにしましょう!」) を提供することも、ほぼ同じくらい簡単で、これまでのところ、これらの点ではさらなる進歩が見られます。

さらに複雑なのは、Apple がアプリで Core Data の採用と iCloud のサポートの両方を開発者に求めていることです。一部のアプリでは、これにより開発者は可能な限りの限界に達することになり、さらにエンド ユーザーからユーザビリティに関する苦情が生じる状況になります。

この問題の解決は複雑であり、それがそもそも Apple が Core Data に取り組み始めた理由そのものです。複数のデバイス間でデータベース トランザクションの同期を管理することは、特にサードパーティのアプリケーションが非常に特殊な使用例に遭遇する可能性がある場合や、顧客のさまざまな異常な状況に対応する必要がある場合には、単純に困難です。この複雑さこそが、アプリ開発者が多大な労力と費用を費やして独自のカスタム ソリューションを展開するのではなく、Apple に iCloud のデータベース同期の問題を解決してほしいと望んでいる理由です。

アプリ開発者またはそのユーザーが同期の問題に遭遇すると、解決するのが難しく、費用がかかる場合もあります。さらに、Apple は現在、iCloud 内の破損したデータベースや不適切に同期されたデータをサルベージするための強力なツールを提供していません。ほとんどの場合、ユーザーにとっての唯一の選択肢は、iCloud から既存のデータを削除して最初からやり直すことです。

解決策の 1 つは自分で行うことです

開発者スティーブ・ストレーザ書きました、「データの同期の現実は、それが難しく、ネットワークの可用性が常に信頼性や高速性を保証するとは限りません (特にモバイルでは)。更新や問題を処理するには、大量の目立たないコードを作成する必要があります。」

AppleのiCloudチームについて同氏はさらに、「彼らがやっていることは非常に困難であり、どのアプリにも適用できる方法でこの規模の問題を解決しようとしているチームを大いに尊敬している。しかし、共感は築き上げることができるものではない」と付け加えた。もちろん、DIY ソリューションの欠点は次のとおりです。本当に、本当に難しい。」

Streza 氏は続けて、独自の同期インフラストラクチャを構築すること、または Apple の iCloud を使用することの長所と短所について詳しく説明しました。 「iCloud」について同氏は、「美しいアイデアではあるが、ほとんどのアプリは本番環境に対応しておらず、終わりのない頭痛の種となり、永遠にApple製品専用のアプリを開発することになるだろう」と結論付けた。

十分に進歩したテクノロジーは魔法と区別がつきません

一部の開発者は、iCloud での Core Data データベース同期に対する Apple のアプローチ全体に懐疑的な姿勢を表明していますが、同社はこのテクノロジーに多大な投資を行っています。大規模な開発にも数十億ドルを費やしている新しいデータセンターこれにより、iWeb や他の初期の MobileMe 機能、あるいは最近の Google のように、同社が単純にプロジェクトを放棄する可能性が低くなります。もっているRSS リーダーを使用すると、CalDAV カレンダー同期と ActiveSync プッシュ Gmail がサポートされます。

さらに、Apple の最近の経営再編が、Core Data に関する iCloud の根本問題の解決に注目を集めるのに役立つ可能性があるという兆候もあります。 Core Data フレームワークは、Steve Jobs の NeXT が 90 年代初頭に Enterprise Objects Framework で行った作業から回収されました。オリジナルの EOF により、NeXT アプリと WebObjects アプリを大規模データベースと統合できるようになりました。 Core Data は、デスクトップ開発者が遭遇する問題を解決するためにこのテクノロジーを再利用したものです。

オリジナルEOFプロジェクトNeXT では Craig Federighi によって管理されていました。彼は 1996 年に Apple が NeXT を買収したときに入社し、2001 年に同社が EOF を Java に移植することを決定し事実上破棄した後に退職しました。

2009 年、Apple が EOF を Core Data に変換する作業を完了した後、当時の Apple の OS X 責任者、Bertrand Serlet は、OS X の作業にフェデリギ氏を再び採​​用しました。2 年後の昨年 8 月、Serlet はフェデリギ氏を再び採​​用しました。発表された彼の引退に伴い、彼の後任としてフェデリギを紹介し、Apple の OS X への取り組みを主導しました。

Serlet氏は当時、「Craig氏は過去2年間、Mac OSチームの管理で素晴らしい仕事をしてくれた。Lionは素晴らしいリリースであり、移行はスムーズに行われるはずだ」と語った。

3か月後、Appleの最高経営責任者ティム・クック氏は次のように発表した。別の激変これにより、Scott Forstall氏がiOSのリーダーシップから解任され、OS XとiOSの両方がFederighi氏の指揮下に置かれることになった。

Core Data の進歩を期待している開発者にとって、EOF の元の開発者が現在 iOS を管理しているという考えは、少なくとも良いニュースです。フェデリギ氏の指揮の下、Apple の OS チームが過去 1 年間に何を達成したかはまだ分からないが、同社が iOS 7、OS X 10.9、 iCloud v3。