能登 要

札幌在住のiOSアプリ開発者。SwiftUI により分割されたデバイス間を縦横にやりとりできる考え方に転換しています。

iOSアプリ開発者。2009年のiPhoneアプリ開発開始時期から活動。開発言語のアップデートの中でSwiftUIおよび周辺技術に着目中。

Apple Widget考古学 - App Extension の技術Stack

ウィジットに関する読み物。OSXから数えると10年以上経過しているのでAppleのウィジットに関する経緯の確認。

端的に云うと

WidgetKitはApple提供テクノロジーの塊。WidgetKitのベースとなる技術スタックは主役と脇役が入れ替わることがある。

1) ウィジット前史 = 原初のiPhoneはウィジェットライク

iPhone発売当初からモバイルアプリの画面遷移の基本は確立されていた。一方で時計といったユーティリティアプリはOSⅩのWidgets(Dashboard上に表示するJavaScriptベースのアプリ)からルックスライクを拝借していた。iPhone原初の姿は3.5-4.0インチの画面、モバイルアプリ用ともウィジット用とも見て取れる画面サイズにアプリとウィジットが混在していた時期だった。

DashboardWidget

画面サイズが大きくなるにつれアプリが単機能ではいられなくなり(そもそもAppleが機能不足のアプリを審査で落としていた)、自然とウィジット然としたアプリは姿を消していった。

Note: ウィジットのアイデア自体はさらに遡りYahoo! Widget Engine(https://en.wikipedia.org/wiki/Yahoo!_Widgets)あたりに行き着く。雑感だが(2020年となっては)クラシカルなJavaScriptとXMLによる画面レンダリングしたミニアプリはセキュリティやエネルギー効率などが無視できた良い時期に出てきたアイデアだし後年姿を変え登場することから魅力はあるアイデアだと思う。

2) WidgetKitの前身 - Today Extension

Today Extensionはアプリの拡張機能としてWWDC2014で発表されたウィジットだったiOS/macOSのExtension 機能としてそれぞれUIKit/AppKitで実装する。

WWDC2014ではExtension でサポートした機能としてwatchOS1.0アプリ、カスタムキーボードなどがある。

TodayExtension の利点はExtensionとしての制限はあるがアプリに近い機能(タイマーなどのダイナミックな変更)を実現できた。アプリに近しい機能は有している

ただし2016年から4年も経過するとToday Extensionにも機能不足点が見えてきており、

a) Today Extension側で独立した設定用UIなどは提供されていない b) アプリのロック画面に表示されるにもかかわらずエネルギー効率が考えられていない c) フォントサイズやウィジット幅の検知はiOS/macOSごとのSDKだのみ

がある。細かいアップデート(2016年)はあったが6年間で抜本的なアップデートが行われないToday Extensionを一気に解決したのがWidgetKit といえる。

3) WidgetKitの登場

iOS14から追加されたWidgetKitは前身のToday Extension をリプレイスできる。

4年目にしてリプレイスすることになったウィジット機能だが、リプレイスにあたり要因としては様々な理由があるように見受けられる。WidgetKitの利点を示すと、

  1. iOS/macOSでで共有のコードを記述可能。開発の敷居を下げている
  2. ウィジットのエネルギー効率を見直し
  3. SwiftUI経由でフォントサイズやウィジット幅を考慮できる
  4. 複数ウィジット対応
  5. ウィジット毎のユーザーカスタマイズ対応

があげられる。

Meet WidgetKit - WWDC 2020 - Videos - Apple Developer https://developer.apple.com/videos/play/wwdc2020/10028/

SwiftUIの新機能としても紹介されている

What's new in SwiftUI - WWDC 2020 - Videos - Apple Developer https://developer.apple.com/videos/play/wwdc2020/10041/

4) Apple提供テクノロジーのパズルと化すWidgetKit

エネルギー効率の向上と引き換えにUIkit/AppKitを使って実現できた機能を取り上げられた以外全て良いことづくめに見えるがApple提供テクノロジーを理解しているという前提に基づく、

具体的には以下となる。

  1. Extensionについての理解
  2. AppGroupによる情報共有方法の理解
  3. SwiftUIの実装
  4. [オプション]設定画面はSiri Intent Extensionで提供

Appleのテクノロジーの組み合わせは理にかなってる。SwiftUIはマルチプラットフォームを試行もしているが宣言的UIなのでウィジット用画像を生成するレンダラーとしても利用している。1と2については2018年の勉強会プレゼンテーションでSiri Intent Extensionで必須なAppleのテクノロジーを紹介している。

[プレゼン資料] Siri をだしにしてみる(Siri Develop Guide 2018) | Irimasu Densan Planning - いります電算企画 https://irimasu.com/siri-develop-guide-2018

4もSiri Intent ExtensionをWidgetの意図(Intent)を実現するために本来のSiri Intentとは用途が異なるかもしれないが採用されている。ユーザーが入力したIntentをOS側で永続化しておいたり、ウィジットへのパラメーター私はIntent経由、ローカライズに対応、アプリを起動せずに高速に呼び出し可能などウィジットの設定を実装する場合はIntentを理解しておく必要がある。

Widget App Extension Stack

5) Appleの技術スタックのコスト高感

WidgetKitの技術スタックは理にはかなっているがAppleの技術スタックを理解するにはコストが高すぎる。

Widgetを含めた拡張機能に言えることだが、技術スタックごとのテクノロジーそれぞれの習得は容易だが、扱うテクノロジーの数の多さとテクノロジーの関係形を一度に理解するコストに対するメリットが薄く、拡張機能は目的が細分化され問題やりとりするためのやりとりがWebの膨大な情報量で埋れやすい。

そもそもアプリ開発者は、拡張機能に時間をかける暇などなく他に心を砕く問題が多いのである。アプリ開発者にとっては、Apple、Android両プラットフォーム対応とか、SDKアップデート毎に壊れるデプロイ環境の整備とか、アプリアーキテクチャを検討するとか色々あるのである。

アプリの拡張機能としてだけみると発展性がないかもしれない。

6) 主と傍の技術が入れ替わるApple製品

アプリの拡張機能から始まったwatchOSアプリは、watchOSのアプリとして独立したことを考えると拡張機能とアプリのmain/sub関係が逆転するケースも出てきている。

Note: iOS13からwatchOSの独立したアプリを作成可能となったが、利用者がアプリと考えている機能は拡張機能として組み込まれている。watchOSアプリの本体は拡張機能のコンテナのような振る舞いをする。

何を言いたいかというと、WidgetKit、Siriを支えているAppleの技術スタックは決してわきの機能ではないのである。2020年に主と思われているアプリが心砕いている問題が主役の座から転げ落ちないとも限らない。

WidgetKitは格納機能やAppleの技術スタックを体験するのに手頃なので、気負いせずWidgetKit対応サンプルアプリを作成してみることを提案する。