WWDC で、Apple は iOS 8 と OS X Yosemite の両方用の新しい App Extension アーキテクチャを発表しました。新しい拡張機能によって、両方のプラットフォームの通知センターで新しいタイプのウィジェットが有効になり、iOS でサードパーティのカスタム キーボードが有効になる方法を次に示します。
Apple は、iOS 8 および OS X Yosemite でサードパーティ開発のためのさまざまな新しい手段を導入しました。これらはすべて、App Extensions という共通のスレッドによって結び付けられています。前回の記事で調べた写真編集拡張機能Apple の新しい Cloud Kit に対応した写真アプリ向け。
この記事では、通知センターに表示されるウィジェットである「Today Extensions」や、モバイル デバイスで使用するカスタム キーボードを作成するために、同じ基盤となるテクノロジがどのように活用されているかを検証します。
ホーム画面ウィジェットとサードパーティ製キーボード (デフォルトのシステム キーボードを置き換える) は、以前から Android に関連付けられてきました。5年iOSに欠けているものとして。
アップルのことを考えると、コンセプトを作成しました1981 年に Mac デスクトップ用のミニアプリとしてデスク アクセサリが登場し、最近では OS X Tiger が宣伝しましたダッシュボードウィジェット2005 年（Google が Android を買収する前）、なぜ Apple が今になって初めて iOS 用のスタンドアロン ウィジェットを導入するのか不思議に思われるかもしれません。
カスタム キーボードも同様の悩みを抱えています。iPhone は 2007 年のデビュー時に、主な差別化機能の 1 つとして仮想オンスクリーン キーボードを提供しました。さらに、2008 年の最初の iOS App Store タイトルの中には、Swype に似た、IBM とリンピン大学で開発された技術を使用してジェスチャーを介してテキストを入力する非伝統的なキーボード アプリである ShapeWriter がありました (どちらもその後、Nuance に買収されました)すでにあるサポートを発表iOS 8 のカスタム キーボード拡張機能としての Swype 用)。
オリジナルの ShapeWriter はテキストを記録できましたが、ユーザーは使用するアプリに入力した内容をコピーして貼り付ける必要があったため、このテクノロジーはアプリに直接統合されたカスタム キーボード (カスタム数字キーボード以下の Apple の Numbers に表示されます)、またはシステム自体 (インストールされているアプリへの入力を可能にします)。
Android は、ShapeWriter のほぼ 1 年後までデビューさえしませんでした。その理由の 1 つは、Google の Android に対する当初のコンセプトがJava モバイル ボタン電話機、他の人が売っていたのと同じように。
ついにAndroidが登場仮想キーボードが機能しない場合Google はユーザーからの入力を重視しているため、物理ミニキーボードと LED 点灯トラックボール、業界の他の企業とはまったく対照的に、スティーブ・ジョブズが初代 iPhone の中核的な設計コンセプトとして宣伝していた再構成可能なキーボードの価値を理解できませんでした (下記)。
2009 年、Google は Android 1.5 Cupcake でウィジェットとサードパーティ製キーボードへの扉を開きました。このプラットフォームが市場に普及し始めるほぼ 1 年前でした。その結果、Android は仮想キーボードの点で iPhone パーティに 2 年遅れて登場したにもかかわらず、事実上すべての Android ユーザーが両方のアイデアの概念に精通するようになりました。
Apple がこれほど早期にリードしていたことを考えると、なぜ Apple は過去 5 年間、システムに統合されたカスタム キーボードやホーム画面ウィジェットのサードパーティ市場の開拓に抵抗してきたのでしょうか?一言で言えば、パフォーマンス、プライバシー、セキュリティです。
Apple は iOS のパフォーマンス、プライバシー、セキュリティに重点を置いているため、高級携帯電話の市場では Android のウィジェットやカスタム キーボード機能を上回っており、Android を使用している他のハードウェア メーカーが廃業したり、定期的に損失を出したりしている中 (Google の自社を含む)、Apple は持続的に利益を上げ続けています。モトローラ、四半期ごとに数億ドルの損失を出しました）。たとえティム・クック氏がタイムマシンを持っていたとしても、2009 年に戻って iOS エンジニアにウィジェットやサードパーティのキーボードに集中するよう促す必要はありません。
Android で最も業績の良いサムスンの株価が過去 5 年間で 119.3 パーセント上昇し、一方 Google の株価が同期間で 175.24 パーセント上昇したことを考えてみましょう。
2013 年を通じてメディアが妄想的なパニックを起こしたにもかかわらず、同じ 5 年間で Apple の株価は 362% 以上上昇しました。たとえティム・クックがタイムマシンを持っていたとしても、2009 年に戻って iOS エンジニアにウィジェットと 3 番目の機能に集中するよう促す必要はありません。パーティーキーボード。
ウィジェットやカスタム キーボードに価値がないと言っているわけではありません。 Android が両方を推進することで、さまざまな興味深い機能が浮き彫りになりました。そしてもちろん、Apple の iOS には、システムが提供するウィジェット (株価や天気など) やアプリ固有のカスタム キーボード (これも Apple 独自の Numbers と同様) も組み込まれています。 Appleがしなかったのは、結果を考慮せずにiOSを無制限の趣味の実験に広く開放することだ。
Android でまさにそれを行うという Google の決定は、構想が不十分で中途半端なソリューションを急いで市場に投入することに伴う問題を明らかにしました。 Android 上のウィジェットは一般にバッテリーの消耗に関係しており、依然としてシステムに影響を与える顕著なパフォーマンスの遅れの一因となる可能性があります。
さらに、Google によるウィジェットとサードパーティ製キーボードの両方の実装により、多くのエンド ユーザーが合理的に考えられないような重大なセキュリティ上の脆弱性とプライバシーの問題が明らかになります。サードパーティのキーボードがユーザーを監視しているかどうかを Google が監視することは事実上不可能です。そして、そのような悪意のある活動の発生を阻止するための機能的なセキュリティ境界が存在しないため、多くのユーザーが実際にユーザーのキー入力を記録し、ネットワーク経由でデータをアップロードしていることはよく知られています。
Android のセキュリティは主に単純な信頼に基づいています。一見正当なカスタム キーボード開発者であっても見つかったユーザーのキーストロークを処理のためにサーバーに送り返すため平文で入力したすべての内容を誰でも聞くことができるようにします。
Google が法人化される数十年前から悪意のあるセキュリティ攻撃に対処してきた経験豊富なプラットフォーム ベンダーとして、Apple は自社のプラットフォームを悪用される可能性のある状態にしておくことについて、より大きな懸念を抱いています。また、基本的なセキュリティ設計をエンド ユーザーに委任することもありません。エンド ユーザーのほとんどは、関連する複雑な問題に対処する専門知識を持っていません。
Android の設計において、Google は悪いことが起こらないということに繰り返し賭けてきましたが、その賭けはユーザーを犠牲にして定期的に負けてきました。しかし、Android の評判も傷つき、特に政府や企業の貴重な顧客に影響を与えています。全体的には少数派のままそして、Apple の iPad は、タブレットにおいては事実上まったく競合しません。
iOS 8 と OS X Yosemite の両方で、Apple はプッシュ通知と、定期的に更新される情報を表示するというウィジェットの主な役割との関係により、通知センター内にウィジェットを表示します。このため、Apple では通常、新しいウィジェットを「Today Extensions」と呼んでいます。
OS X では、Today Extensions が実質的にダッシュボードウィジェット10 年近く前に OS X Tiger (下) で導入されました。ダッシュボード ウィジェットは、すぐに呼び出したり閉じたりできるデスク アクセサリとして考案され、標準 Web ページと同様のレベルのセキュリティ サンドボックスを可能にするために HTML、CSS、および JavaScript で実装されました。 Web 標準は、外部ホストを暗黙的に信頼しないように設計されています。
ただし、Today Extensions は事実上、ダッシュボード ウィジェットのようなミニ Web ページではなく、他の App Extensions と同様に、Apple の XPC および最新の iOS スタイルの Cocoa サンドボックスに基づく新しいセキュリティ モデルを使用するネイティブ コードです。これらはシステムによって起動され、動的に管理されます。 iOS でメモリの使用量が多すぎる場合、システムは最適なパフォーマンスを維持するためにそれらを終了できます。
安全なネイティブ実装などをサポートするインフラストラクチャの構築には、舞台裏で何年ものエンジニアリングが必要です。 Apple が「権限の分離を可能にすることで App Sandbox を補完するプロセス間通信テクノロジ」と説明している XPC は、2011 年に OS X Lion に初めて導入されました。権限の分離は、危険な新たな脆弱性を引き起こすことなく、App Extensions が限定されたタスクを実行できるようにするための鍵となります。
App Extensions には、ネイティブのパフォーマンスと成熟したセキュリティ インフラストラクチャに加えて、それをサポートする存続可能な市場も必要です。ダッシュボード ウィジェットは、最初の目新しさが薄れた後、OS X では長い間低迷していました。その理由の 1 つは、ユーザーがダッシュボードを呼び出したときにウィジェットをアニメーション化する Web レンダリング プロセスの起動に伴う遅延が原因であり、また、無料のダッシュボード ウィジェットには、次のような機能的なビジネス モデルが欠けていたためです。 App Store のアプリ。
現在、拡張機能 (あらゆる形式のアプリ拡張機能と同様) は新規または既存のアプリにパッケージ化されているため、開発者は新しいウィジェットを有料 (または広告付き) アプリの貴重な機能として販売できるようになります。
今日の iOS 8 および OS X Yosemite の拡張機能
現在、拡張機能は iOS と OS X で若干異なる動作をします。モバイル デバイスでは、ウィジェットはテキスト入力や編集機能のないタッチ可能なプレゼンテーションとして表示されます (つまり、たとえば株式ウィジェットでは、表示される株式のリストを編集するにはコンパニオン アプリが必要になります)。 OS X では、ウィジェットをその場で編集でき、テキスト入力をサポートできます。
これらの違いは主に、iOS では通知センターが一目で情報を表示するように設計された一時的なプルダウンであるという事実によるものです。キーボードと編集コントロールを追加すると、ウィジェットを表示する価値がすべての編集 UI によって埋め尽くされてしまいます。また、モバイル デバイスでは、ウィジェットに使用できる処理能力とメモリが Mac よりも少なくなります。Apple の Today Extensions のビジョンは、他の通知のコンテキストでスコア、株式、および同様の情報への迅速なアクセスを提供することを目的としているのは明らかです。
iOS では、通知センターが合理的に対応できる以上に多くの UI とリソースを必要とするウィジェットは、スタンドアロン アプリとして実装する方が合理的です。Apple が 7 年前に初代 iPhone に独自の株価と天気の「ウィジェット アプリ」を実装したのと同じです。 。
Android とは対照的に、Apple の Today Extensions のビジョンは、不足を補うために単にホーム画面を綿毛のボックスで埋めるのではなく、他の通知のコンテキストでスコア、株価、および同様の情報に素早くアクセスできるようにすることを目的としているのは明らかです。重要なネイティブ アプリの数。
ウィジェット自体と同様に、通知センターも Android ユーザーが好んで文句を言いたがる機能の 1 つであり、皮肉なことに、「コピーレフト」の基盤の上に構築されたオープンソース プロジェクトを Apple が「盗んだ」とのことです。イデオロギー盗むことなど存在しない場所。
しかし、アイコンのホーム画面から個別のアプリを起動するように設計されたウィジェットとマルチタッチ モバイル デバイスの両方の全体的なコンセプトと同様に、Apple は Android がリリースされる前に、iOS 向けの集中通知システムを開発する取り組みの概要を公に説明していました。
2008 年初め、App Store と「iPhone OS 2.0」がリリースされたとき、当時 Apple の iOS 開発責任者である Scott Forstall 氏はこう述べました。発表された同社は、アプリがバックグラウンドでアクティブなままにし、常に新しいデータをポーリングしてバッテリー電力、CPU、メモリを消費することなく、外部サービスからの更新に応答できるようにするためのメカニズムとして、集中型プッシュ通知サービスをセットアップする予定です。
Apple のプッシュ通知サービスの概要。
当時、Samsung はまだ Windows Mobile 6 を推進していましたが、Windows Mobile 6 では (今日の Android と同様に) ユーザーがバックグラウンド プロセスとアプリが消費するメモリと CPU リソースを手動で管理する必要があり、Apple はこの実装を自社が望んでいた不適切な設計の一例として指摘しました。劇的に改善すること。
Windows Mobile 6 のタスク マネージャー アプリケーション。
しかし、Apple は同年後半、アプリとプッシュ通知の両方に対する圧倒的な需要を大幅に過小評価していたことを指摘し、ストレスを受けて会社を振り出しに戻し、プッシュ通知サービスの展開を 2009 年初頭の iOS 3.0 まで延期しました。 AP通信と他のアプリ開発者が参加するベータプログラムのテスト。
2009 年後半、大手 iOS 開発会社である Google は、特許を出願した「モバイルデバイスイベントの通知」については、後に Android に追加される機能について説明しています。 Android 愛好家は現在、Apple がタッチスクリーン スマートフォン、機能的なアプリ ストア、安全でバッテリー効率の高い通知システムの基礎をすべて整えたのではなく、単に Android から通知センターをコピーしただけだと主張しています。
2010 年に、Apple はプッシュ通知を API として Mac に導入しました。当初はサポートするためでした。FaceTime 通知その後、2011 年にはパブリック API としてより広範に利用されました。OS X ライオン。
現在の通知センターの基本デザイン (上) は、前年の iOS 5 で初めて Apple のモバイル デバイスに登場した後、2012 年の OS X Mountain Lion でユーザー向け機能として Mac に登場しました。
Google は、現在 Google が尊重していない種類の特許を特許取得しています
Apple の最新のウィジェット実装が Android から「平気でコピー」されたのではなく、実際には、Google は通知に関する Apple の公的取り組みを十分に認識していました。サムスン—特許を取得しようとした基本的な通知リストのコンセプト(下) それは、元 Apple エンジニアによって WebOS 用に Palm で開発された先行技術を含む、他の人が最初に開発しているのを目撃しました。
そのエンジニアの中にはリッチ・デリンジャー氏もいる。働いた1999 年から 2006 年まで Apple に勤務し、その後 Palm に転職しました。発展した2009 年の初めに登場した「webOS で使用される非侵入型バナー通知システム」(下)。
デリンジャー氏は、2010 年に Palm が HP に買収された後、Apple に戻りました。Apple はまた、これまでに実績を上げた Peter Hajas 氏も雇用しました。発展したMobileNotifier は、通知のプルダウン リストを表示するジェイルブレイクされた iOS 4 デバイス用のアプリです。その後、Apple は iOS 5 で公式の通知センターをリリースしました (上)。
並行して、Google は Palm の WebOS デザイナー、Matias Duarte を雇用しました。彼は、Palm の UI の開発に貢献したとされています。Android 3.0 ハニカム、および同社の最新の Web にインスピレーションを得た 'マテリアルデザイン' は、Android L と Chrome OS の将来のバージョンの両方に表示されます。この作品は、ユニークなカラーパレットではあるものの、7年前にリリースされたAppleのiPhone用の豊かなアニメーションUIから明確なインスピレーションを得ています。
システムプラグインとしてのカスタムキーボード
市場に急いで投入された最初の実装のアイデンティティよりも重要なのは、現在入手可能な優れた実装です。これは、Android ユーザーが Apple が Google から「盗んだ」と主張している 2 番目のタイプのアプリ拡張機能、つまりサードパーティ製のシステム全体のカスタム キーボードで特に顕著です。
遅ればせながらオンスクリーン キーボードの価値に気づいた Google は、2009 年にコア Android システム リソースへのサードパーティ アクセスを開放し、誰でもテキスト入力用のカスタム ソフトウェアを提供できるようにしました。 Google のデフォルトのシステム キーボードは広く考慮されているあまり良くないこと。 Google の仮想キーボードへの最初の試みは、サードパーティのオプションとともに提供されました。
一人のユーザーとして注目したに対して提起された質問の中でAndroid セントラル数年後、「iOS ユーザーとしての Android に関する最大の不満は、Jelly Bean 以外のキーボードはすべてゴミだと思っていたことでした。テキスト予測が iOS に大きく遅れをとっていて、単語を選択するのに一時停止しなければならないことがわかりました。私はかなりタイピングが早い方で、iPhone では比較的ミスが少なく、バックスペースキーを押す必要もまったくありませんでした。」
スペル修正や自動修正などの iOS 入力機能に加えて、中国語のフィンガーストローク入力のサポートを含む Apple のデフォルトのキーボードは、Android に付属の基本キーボードよりも大きな利点を長年保持してきました。サムスンが持っていることが判明したほど侵害されたApple が自社デバイスを iPhone との競争力を高めるために取得した、キーボードの自動修正に関する特許 8,074,172 件。
同時に、多くの Android ユーザーが魅力的だと考えるサードパーティのカスタム キーボードもありますが、ユーザーのプライバシーとセキュリティを保護するために Apple が十分な注意を払っていたため、これらの入力システムを iOS に移植することは以前は不可能でした。
新しいカスタム キーボードに対する Apple の厳格な規則
iOS 8 の新しいカスタム キーボード拡張機能を使用すると、開発者はいくつかの制限はありますが、代替システムを実装できます。まず、カスタム キーボードを使用して、ユーザーのパスコードやその他のパスワード フィールドなどの安全なテキスト フィールド オブジェクトを入力することはできません。ユーザーがカスタム キーボード (以下の新しい Swype など) を使用してセキュリティで保護されたテキストを入力しようとすると、iOS 8 は一時的にシステム キーボードに戻り、その後ユーザーは好みのキーボードに戻ります。
カスタム キーボードでは、連絡先の電話番号フィールドなどの「電話パッド」入力も禁止されます。アップルもメモカスタム キーボードはその実装方法により、「テキストを選択したり、カーソル位置を制御したりすることができず」、「挿入ポイント近くのインライン自動修正コントロールを提供できない」ということです。「カスタム キーボードを作成するときに最初に考慮する必要があるのは、ユーザーの信頼をどのように確立して維持するかということです。この信頼は、プライバシーのベスト プラクティスを理解し、それを実装する方法を知っているかどうかにかかっています。」 - りんご
Apple はまた、「デフォルトでは、キーボードはネットワークにアクセスできず、コンテナをそのコンテナを含むアプリと共有することはできません」と概要を説明しています。
同社のドキュメントでは、セクション全体が「ユーザーの信頼のための設計」に当てられており、開発者向けに、「カスタム キーボードを作成するときに最初に考慮する必要があるのは、ユーザーの信頼をどのように確立し、維持するかということです。この信頼は、プライバシーのベスト プラクティスとユーザーの信頼にかかっています。」それらを実装する方法を知っていること。」
同社はユーザーの信頼を獲得するためのデザインの3原則を明記している。 「キーストロークデータの安全性」では、「ユーザーは、キーストロークが入力している文書またはテキストフィールドに送られることを望んでおり、サーバーにアーカイブされたり、明らかではない目的に使用されたりしないことを望んでいる」と述べている。
「その他のユーザー データの適切かつ最小限の使用」では、「キーボードが位置情報サービスやアドレス帳データベースなどの他のユーザー データを使用している場合、そのメリットをユーザーに説明し実証する責任があなたにあります。」と付け加えています。
最後に、「精度」の下で、「入力イベントをテキストに変換する精度は、それ自体プライバシーの問題ではありませんが、信頼に影響します。ユーザーは、入力されたすべての単語でコードの正確さを確認します。信頼を考慮して設計するには、まず次のことを検討してください。ネットワーク アクセスを有効にすると、カスタム キーボードで多くのことが可能になりますが、責任も増大します。」
ネットワーク アクセスをオンにするには、カスタム キーボードがユーザーに許可を要求する必要があります。ユーザーがこれを許可することを選択する理由はさまざまです。これには、カスタム自動修正辞書の保存などの機能が含まれます。強化されたタッチイベント処理、入力予測、ディクテーション用の音声認識を提供します。ユーザーの連絡先またはネットワークが提供するデータから「ユーザーに関連する名前、場所、電話番号」に迅速にアクセスできるようにする。または位置情報サービスからの近くの地名の自動修正。
Apple は、ユーザーによってネットワーク アクセスが許可された場合、開発者がカスタム キーボードに実装するための特定の要件を概説しています。その中には、「ユーザーにテキストを返信したり、ユーザーに送信する機能を提供したりするのに必要な時間を超えて、受信したキーストロークや音声データを保存しないでください」という指示が含まれます。ユーザーに説明してください。」
カスタム キーボードに興味がないユーザーでも、iOS 8 のインテリジェントな機能の恩恵を受けることができます。クイックタイプキーボードは、会話のコンテキストから一般的な回答を分離することに加えて、アプリ ユーザーが入力しているアプリと宛先の人の両方に合わせてカスタマイズされた予測テキストを提供します (下記)。
Apple が考慮した App Extensions の設計
同様に写真編集拡張機能, カスタム キーボードと Today Extensions は、App Extensions の動作方法を厳しく規制する Apple のプラットフォームを介してユーザーに価値を拡張し追加する新しい方法をサードパーティ開発者に提供します。
Apple は、開発者の仕事の価値を強調することで開発者に利益をもたらす App Extensions も設計しました。同社は、「ユーザーが拡張機能を入力するとき、カスタム UI は、新しいコンテキストに移行していることを示すのに役立ちます。ユーザーは拡張機能を現在のアプリから区別できるため、拡張機能が提供する独自の機能を高く評価することができます」と述べています。 。」
同時に、Apple はユーザーが自分の環境をどのように管理するかについても考慮しました。 「ユーザーが拡張機能を別個のエンティティとして認識するということは、不正な動作をする拡張機能や適切に動作しない拡張機能を識別して削除できることも意味します」と Apple は述べています。同社はまた、ユーザーがアクティブ化または削除したい拡張機能を簡単に指定できる方法についても概説しました。
Today Extensions とカスタム キーボード機能の両方が App Extensions の設計に組み込まれているということは、Apple が代替オペレーティング システムが持つ認識されている利点を消去しようと取り組んでいることを示しています。ただし、iOS と OS X のデザインは、単に市場のトレンドに従うだけではありません。 Apple はまた、次のセグメントで概説するように、業界の他の企業とは共有されていない方法で、App Extensions を使用した独自の独自の機能を確立しています。
Isamu 
Isamu 
Isamu