WatchのSDKがプレリリースされた。Watchで動作するWatchKitアプリは、いったいどのようなアーキテクチャにより駆動されるのか。この興味深い仕組みについて考察する。Developerふたつの予想Appleがウェアラブルデバイスを開発しているという噂が流れていた頃、そのアプリケーションのアーキテクチャについて異なる二つの予想をしていた。一つは、ウェアラブル端末本体で動作する通常のアプリを作るというパターン。Wearが採用しており、Androidのアプリを作るのとほとんど同じようにウェアラブル端末で動作するアプリを作ることができる。これが採用されると、UIKitの多くのコンポーネントが利用できることになり、柔軟なアプリを作成できる。その反面でウェアラブル端末の少ないバッテリーは大きく消費される恐れがあるし、比較的非力なSoCに最適化する必要がある。加えて、ウェアラブル端末には通常インターネットに接続する機能はなく、コンパニオンとなるスマートフォンから借用することになるが、これを実装するのは面倒な作業になる。一つは、コンパニオンとなるスマートフォンの側にアプリの機能を実装し、その画面をウェアラブル端末に表示するというパターンである。ウェアラブル端末をセカンドスクリーンとして用いることになる。結果としてウェアラブル端末のハードウェア上の機能に束縛されることなくアプリを作ることができる。TVを利用するAirPlayや、車載端末であるCarPlayのアーキテクチャに近いものであろう。Energyで接続されることが予想され、画面を逐一転送できるだけの通信速度は出ないだろうと思われる。これらの二つの予想は、それぞれに利点や問題を持っている。Appleの最近の技術的なトレンドを考慮すると、後者の方に分があるように思われた。SDKのページを見ると以下のように記載されている。Extensionとしてプログラムが動作する。Watchのユーザーインターフェイスを更新する。これは最初の二つの予想のちょうど中間的なアーキテクチャと言える。Watchの側で動作させる。結果として多くの問題が解決され、アプリはiPhoneの潤沢なリソースや機能を利用できるし、BLEで画面を送信する必要もない。WatchとiPhoneの間のやりとりに遅延が生じることである。Watchの側で素早く表示しつつ、少し遅れてiPhoneでアクションが起きる、ということになる。WatchのViewの様子を取得することができないようになっている。Watchのユーザーインターフェイスに行った操作を記憶しておく必要がある。Watchのリソースに含めておくべきである。Watchの側へ登録しておくことで、再表示するときのコストを大きく下げられる。Watchで利用できない。WatchKitで事前に用意されたユーザーインターフェイス要素だけを用いてデザインする必要がある。WatchとWatchKitのSDKは、ウェアラブル端末に注意深く最適化されたものであることが読み取れる。WatchKitのアーキテクチャによって、優れたユーザーエクスペリエンスが得られるだろう。Watchに限らず、その他のiOS関連機器にも有効なアーキテクチャであると考えられる。TVのほか、将来登場するかもしれない新たな端末にも応用可能である。Xで長年開発してきた技術の結実である。ところでWatchKitアプリに独自のユーザーインターフェイスを作ることは未来永劫できないのだろうか。答えはXcodeにある。Builderに独自のViewを表示できるようになった。内部的には独自のViewをXcodeとは別のプロセスで動作させ、レンダリングさせているように見える。Watch側でカスタマイズしたViewだけを動作させることは技術的に可能になると予想できる。将来のWatchKitでそのような機能が搭載されるかもしれない。以上の内容はAppleによって公開された情報を元に書かれています。検索リンクはてなブログブログをはじめる(無料)お知らせ最新記事SwiftUIではSingletonの代わりにEnvironmentを使うことができる紛らわしい文字列をもっと紛らわしくするapple/swift-formatを試す息子にカメラを与えるCoreImage.CIFilterBuiltins月別アーカイブはてなブログをはじめよう!cockscombさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。