モバイル開発におけるApp Extensionsとシステム統合：概要、種類、仕組み

iOSのApp Extensions：ウィジェットとコンテンツ共有拡張

iOSのApp ExtensionsはiOS 8で登場し、モバイル開発におけるシステム統合の基盤となりました。これらはメインアプリにバンドルされた個別のバイナリですが、分離されたプロセスで起動されます。各拡張機能には独自のInfo.plistと、NSExtensionPrincipalClassで定義されたエントリポイントがあります。システムがApp Extensionsのライフサイクルを管理します — タスク完了後にバックグラウンドに留まることはできません。

WidgetKitとToday Widget

WidgetKit（iOS 14+）は、ホーム画面にウィジェットを作成するための最新フレームワークです。WidgetKitはインターフェース記述にSwiftUIを、更新スケジュールの定義にTimelineProviderを使用します。ウィジェットには3つのサイズがあります：小（2×2セル）、中（4×2）、大（4×4）。UICollectionViewControllerベースの古いToday Widgetは引き続きサポートされていますが、AppleはWidgetKitへの移行を推奨しています。WidgetKitのApp Extensionsはアニメーション、キーボード入力、ジェスチャーをサポートしません — 定期的に更新される静的または疑似アニメーション要素です。

Share ExtensionとAction Extension

Share Extensionを使用すると、システム共有シートを介して任意のアプリからあなたのアプリにコンテンツを送信できます。Share ExtensionはNSExtensionItemを介してデータを受信し、UIにSLComposeServiceViewControllerを使用します。Action Extensionはその場でコンテンツを処理します — たとえば、他のアプリに切り替えずにブラウザでテキストを翻訳します。両方のタイプは制限時間内に処理を完了する必要があり、そうしないとシステムが拡張機能を「強制終了」します。これはモバイルアプリのApp Extensionsの重要な制限です — バックグラウンドタスクは拡張機能レベルでは利用できません。

CallKit、PushKit、SiriKit — 音声と通知のシステム統合

iOSのシステム統合はウィジェットをはるかに超えています：CallKit、PushKit、SiriKitにより、モバイルアプリはシステムレベルで動作できます。これらのフレームワークは特別なエンタイトルメントを必要としますが、ユーザーにシームレスな体験を提供します — CallKitを介した通話は通常の電話のように見え、Siriはアプリを開かずにリクエストを処理します。

CallKit — システムインターフェースでのVoIP通話

CallKitは、サードパーティアプリの通話をロック画面も含むシステム通話画面に統合します。CXProviderがアプリをVoIPサービスとして登録し、CXCallControllerが通話を管理します。CallKitは重複通話を自動的にブロックし、不要な番号をブロックするCall Directory Extensionをサポートしています。CallKitを用いたモバイル開発におけるシステム統合は、音声通信アプリにとって重要です — WhatsApp、Skype、Zoomが着信表示に使用しています。

PushKit — バックグラウンドプッシュ通知

PushKitはユーザーに表示せずに、モバイルアプリに直接プッシュ通知を配信します。PushKitは「強制終了」された状態からアプリを起動し、PKPushRegistryDelegateを介してデータを渡します。これはVoIPアプリの主要メカニズムです：PushKitが通話情報を配信し、CallKitがそれを表示します。PushKitは通常のプッシュ通知よりも配信優先度が高く、バナーを表示する必要がありません。モバイルアプリのApp Extensionsは、音声通信のためにPushKitとCallKitを組み合わせることがよくあります。

SiriKitとIntents Extension

SiriKitを使用すると、Siriおよびショートカットアプリを介してリクエストを処理できます。Intents Extensionは、サポートされているインテントを登録して処理する独立したApp Extensionです。SiriKitは20以上のドメインをサポートしています：通話、メッセージ、支払い、メモ、ワークアウト。ショートカットを使用すると、ユーザーは自動化を作成できます — たとえば、「Siriを介してWhatsAppでメッセージを送信」。SiriKitとショートカットによるシステム統合は、ユーザーがアプリを開かずにアクションを実行できるため、エンゲージメントを高めます。

AndroidのBroadcastReceiverとシステムサービス

BroadcastReceiverは、システムブロードキャストメッセージに反応するAndroidコンポーネントです。iOSのApp Extensionsとは異なり、BroadcastReceiverは個別のバイナリを必要としません — マニフェストまたはContext.registerReceiverを介してコード内にレシーバーを登録するだけで十分です。Androidのシステム統合は多くの場合、BroadcastReceiverから始まります：デバイス起動時のサービス開始からネットワーク接続への反応まで。

システムイベント用IntentFilter

IntentFilterはBroadcastReceiverを特定のシステムイベントにバインドします。代表的なイベント：BOOT_COMPLETED（デバイス起動）、CONNECTIVITY_ACTION（ネットワーク変更）、BATTERY_LOW（バッテリー残量低下）、TIME_SET（時刻変更）。レシーバーはAndroidManifest.xml、または動的登録の場合はContext.registerReceiverを介して登録されます。動的登録が推奨されます — マニフェストのパーミッションが不要で、アプリがアクティブな間のみ機能します。AndroidにはApp Extensionsという概念はありませんが、BroadcastReceiverは同様の役割を果たします — システム統合を通じてアプリの機能を拡張します。

NotificationListenerServiceとAccessibilityService

NotificationListenerServiceは、すべてのシステム通知を受信するサービスです。NotificationListenerServiceにはBIND_NOTIFICATION_LISTENER_SERVICE権限と、アクセシビリティ設定を介したアクセスが必要です。AccessibilityServiceはより強力なシステム統合ツールです：画面コンテンツの読み取り、クリックのシミュレーション、アクションの自動化が可能です。どちらのサービスも、ユーザーが設定で明示的に有効にする必要があり、セキュリティが向上します。AccessibilityServiceを介したモバイルアプリのシステム統合は、自動入力、スクリーンリーダー、アクセシビリティツールに使用されます。

class BootReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_BOOT_COMPLETED) {
            WorkManager.getInstance(context)
                .enqueueUniqueWork("post-boot", ...)
        }
    }
}

この例はBOOT_COMPLETEDイベントのBroadcastReceiverを登録しています。WorkManagerはデバイス起動後の遅延タスク実行に使用されます — これはAndroidアプリの標準的なアプローチです。

App Widget Provider — Androidでのウィジェット作成

AndroidのApp Widget Providerは、ウィジェットのコンテキストにおけるiOS App Extensionsの対応物です：ホーム画面にインタラクティブなコンテンツを表示するコンポーネントです。WidgetKitとは異なり、Androidウィジェットはユーザー入力（クリック、トグル、ジェスチャー）を受け付けることができます。App Widget Providerは、サイズと更新頻度のXML記述を通じてマニフェストに登録されます。

RemoteViewsとAppWidgetProvider

RemoteViewsはXMLレイアウトを通じてウィジェットインターフェースを記述し、限られたViewセットのみをサポートします。RemoteViewsはカスタムViewを許可しません — TextView、ImageView、Button、ProgressBarなどの標準コンポーネントのみです。AppWidgetProviderはウィジェットの更新、有効化、削除を処理する基底クラスです。onUpdateメソッドは、updatePeriodMillisを介したタイマー、または正確な制御のためにWorkManagerを介して呼び出されます。Androidのウィジェットとのシステム統合には注意が必要です — 更新頻度が高すぎるとバッテリーを消耗します。

Glance API（Jetpack）— 最新アプローチ

Glance APIは、XMLではなくKotlin DSLを使用してウィジェットを作成するためのJetpackライブラリです。Glance APIはRemoteViewsにコンパイルされ、Composeライクな構文をサポートします：GlanceComposable、Column、Row、Text。このライブラリは複雑なXMLコードの問題を解決し、JUnitを介したウィジェットテストを可能にします。Glance APIはまだすべてのRemoteViews機能をサポートしていません — 複雑なインタラクティブウィジェットにはクラシックなアプローチが適しています。Androidのモバイル開発におけるApp ExtensionsはGlance APIへと進化しており、ウィジェットの作成と保守を簡素化しています。

Content Provider、FileProvider、アプリ間データ共有

Content Providerは、統一されたContentResolverインターフェースを介してアプリ間で構造化データを共有するためのAndroidコンポーネントです。iOSのApp Extensionsとは異なり、Content Providerは別個のプロセスを作成しません — データは呼び出し元アプリのコンテキスト内で同期的に要求されます。Content ProviderはAndroidのシステム統合の基盤です：連絡先、メディアファイル、カレンダー、標準アプリがデータ公開に使用しています。

安全なファイル共有のためのFileProvider

FileProviderは、アプリ間の安全なファイル転送のためのContentProviderのサブクラスです。FileProviderは、Android 7+で禁止されている直接のfile://パスの代わりに、一時的なcontent:// URIを生成します。使用するには、XML構成でfiles-pathまたはexternal-files-pathを指定する必要があります。Androidのモバイル開発にApp Extensionsという別個の概念はありませんが、FileProviderがその機能を果たします — データ共有機能を単一のアプリを超えて拡張します。

iOSの対応物：File Provider Extension

iOSでは、ファイル共有の役割をFile Provider Extensionが担います。File Provider Extensionは、NSFileProviderManagerを介してアプリのファイルをFiles Appに公開します。FileProviderとは異なり、iOS拡張機能は個別のバイナリを必要とし、分離されたプロセスで実行されます。File Provider Extensionは、ファイル記述にNSFileProviderItem、フォルダーナビゲーションにNSFileProviderEnumeratorをサポートしています。File Provider Extensionを介したモバイルアプリのシステム統合により、ユーザーはアプリを開かずにFiles Appからアプリファイルを管理できます。

class MyFileProviderExtension: NSFileProviderExtension {
    override func item(for identifier: NSFileProviderItemIdentifier) throws -> NSFileProviderItem {
        return MyFileProviderItem(identifier: identifier)
    }
}

この例は、SwiftでのFile Provider Extensionの最小限の実装を示しています。item(for:)メソッドは識別子によってNSFileProviderItemオブジェクトを返します — Files Appでファイルを表示する際にシステムがこれを呼び出します。