Appleプラットフォームマトリクス：どのターゲットがどのアプリにふさわしいか

Appleは、開発者が単一のSwiftコードベースでターゲットにできる消費者向けコンピューティングプラットフォームを6つ出荷しています。iPhone、iPad、Mac、Watch、Vision、そしてTVです。SwiftUIとiOS 26ツールチェーンの組み合わせにより、いずれを追加してもXcode上ではチェックボックスを入れるだけの操作になりました。このチェックボックスこそが罠です。追加のターゲットはひとつひとつが機能ではなく責務であり、デザイン、テスト、アクセシビリティ、ランタイムモデル、継続的なメンテナンスの表面積をそれぞれ拡張していきます。アプリにとって正しいターゲット数は、フレームワークが許す数より少ないのです。

クラスター内のアプリは、それぞれ異なる組み合わせで動いています。Returnは6プラットフォーム（iPhone、iPad、Mac、Watch、Vision、TV）で出荷しています。Get Bananasは4つ（iPhone、iPad、Mac、Watch）で出荷しています。RepsとWaterはリリース前で、複数のコンパイル済みターゲットを持っていますが、ローンチ前に絞り込む予定です。Ace CitizenshipとTappy Colorはそれぞれ、iPhoneのみで出荷されています。同じ開発者、同じツールチェーンでありながら、6通りの異なるプラットフォーム判断がなされているのです。これらの判断にはルールがあり、そのルールには共有マップがふさわしいでしょう。

本稿はそのルールを明らかにするものです。各プラットフォームは、「コンパイルが通るから」ではなく、そのプラットフォームが本当にもたらす具体的なユーザー価値によって組み入れられる権利を獲得します。出荷段階まで生き残るマトリクスとは、各ターゲットが自らの存在を正当化するか、あるいは切り落とされた後に残ったものです。

TL;DR

• 6プラットフォーム、6つの異なる責務：iPhone（デフォルト）、iPad（サイズクラス対応）、Mac（ウィンドウ/メニュー/キーボードのイディオム）、Watch（ランタイム契約）、Vision（空間メンタルモデル）、TV（フォーカスエンジン）。
• ターゲットを追加するごとに、テスト範囲、デザイン作業、アクセシビリティ、継続的なリリース調整が増えます。Xcodeの「プラットフォームを追加」チェックボックスは、そのコストを隠してしまうのです。
• 適切なテストは技術的なテストではなく、ユーザー価値のテストです。ユーザーがそのプラットフォームでこのアプリを動かすことから本当に恩恵を受けるか？答えが「そこでも動く」であれば、切り捨てましょう。
• ほとんどのアプリは、1〜3プラットフォームで出荷すべきです。4〜6プラットフォームは稀であり、各プラットフォームが他では提供できないユーザー価値を本当に加える場合にのみ、その枠を獲得できます。

iPhoneがデフォルト

すべてのAppleアプリはiPhoneから始まるか、さもなくば始まりません。iPhoneは最大のインストールベース、最も洗練されたアクセシビリティ表面、App Storeを通じた最強の流通経路、そしてSwiftUIの正典的なデザイン言語を備えています。私が出荷したクラスター内のアプリはすべてiPhoneで動作します。iPhoneファースト以外のデザインで出荷したものはひとつもありません。

iPhoneのユーザー価値テスト：ユーザーはこのアプリを電話で開くだろうか？ほぼすべての消費者向けカテゴリーで、答えはイエスです。ヘルスとフィットネスのアプリは電話に住んでいます。生産性ツールは電話に住んでいます。ゲームは電話に住んでいます。コミュニケーションツールも電話に住んでいます。デフォルトがiPhoneなのは、ユーザーがいる場所が電話だからです。

例外は、開発ツール（Xcode、Terminal）と、画面の広さを必要とするクリエイティブツール（Final Cut、Logic）です。これらはMacから始まり、明確な連携がある場合にのみiPhoneのコンパニオンを獲得します（ワークアウト中のWatchの心拍数を電話がチャートで表示する、カメラ連係など）。消費者向けソフトウェアにおいて、iPhoneファーストは議論の余地がありません。

iPadはピクセル数の多いiPhoneではない

CatalystによってUIKitのiPhoneアプリをサイズクラスのブレークポイント付きでiPadに出荷することが可能になりました。SwiftUIは@Environment(\.horizontalSizeClass)とNavigationSplitViewを通じて、同じことをさらに容易にしました。「iPadに出荷する」ことの技術的コストは低いのです。プロダクトのコストは、そのアプリが本当にiPadのより大きなキャンバスにふさわしいかどうかという問いにあります。

iPadにイエスとなる3つのシグナル：

ユーザーがより広い画面を求めるコンテンツを読む、または作成するアプリ。 読書アプリ（Books、ニュース、コミック、長文ドキュメント）。お絵かき/ペイントアプリ（Procreate）。Apple Pencilを使ったノート取り（Notability、GoodNotes）。Get Bananasがそのスロットを獲得しているのは、セクション付きの買い物リストが狭いキャンバスより広いキャンバスでより役立つからであり、iPadのデザインは同じセクションリストをより大きな領域に適応させています。

iPhoneやMacとの連携価値があるアプリ。 Apple Notes、リマインダー、メールはすべて、ユーザーが連続性を期待するためiPadのスロットを獲得しています。ReturnのiPad上の瞑想履歴も同じ理由でその枠を得ています。ユーザーはiPhoneで開始し、タイマーが動いている間にiPadをちらりと見るのです。

iPadネイティブの入力アフォーダンスを持つアプリ。 スケッチや手書きのためのApple Pencil。より広い表面でのマルチフィンガージェスチャー。タイルベースのレイアウトの恩恵を受けるStage Managerのワークフロー。アフォーダンスがiPhoneに存在しなければ、iPadターゲットはその位置を獲得します。

iPadにノーとなるシグナル：

スケールしても付加価値のない単一カラムのコンテンツ。 瞑想タイマーの主要なビューはカウントとボタンです。iPadは両方を大きくしますが、それは機能ではありません。クイックログ式の水分補給トラッカーも同じです。広い画面は5秒のロギングセッション中にユーザーが行うことを変えません。

iPhone固有のハードウェアに依存するアプリ（ロック画面、Dynamic Island、特定のiPhone専用構成のProMotion、特定のカメラフォーマット）。これらのデザイン前提は移植が困難です。デザインを作り直すか、ターゲットをスキップするかのどちらかです。

ユーザーがすでにMacにより良い行き先を持っているアプリ。 キーボードサポートのないiPad上のコードエディタは、Macアプリの不完全な版です。デザインがiPad固有の入力モデルにふさわしい位置を獲得しない限り、ターゲットはスキップしましょう。

Macはウィンドウ、メニューバー、キーボードのイディオム

Mac CatalystまたはDesigned for iPad経由でMacに出荷されたSwiftUIアプリは、本物のMacアプリを生み出すことなくmacOS上で動きます。本物のMacアプリは、ウィンドウのリサイズセマンティクス、メニューバー（SwiftUIのCommands(content:)）、キーボードショートカット、macOSのファイルピッカー、Finderとのドラッグ＆ドロップ、そしてMacネイティブの共有を尊重します。これらのいずれかを省くと、Macユーザーが気づき、評価を下す「ウィンドウの中のiPadアプリ」体験が生まれてしまいます。

Macにイエスとなるシグナル：

ユーザーがアプリ内で時間を過ごし、それが本物のデスクトップウィンドウであることから恩恵を受けるアプリ。 Mac上のGet Bananasがその枠を獲得するのは、デスクで長い買い物リストを編集するユーザーが、キーボードナビゲーション付きの本物のウィンドウから恩恵を受けるからです。Mac上のReturnがその枠を獲得するのは、仕事用マシンで瞑想タイマーを動かしたいユーザーが、本物のメニューバーアプリや特定の隅に固定されたウィンドウから恩恵を受けるからです。

マルチウィンドウまたはマルチドキュメントのワークフロー。 分割ペインを持つコードエディタ。参照画像を並べて表示する写真エディタ。スプレッドシート。これらはどれもiPadやiPhoneで適切な形では生き残りません。Macが正しいプラットフォームなのです。

キーボード駆動のインタラクション。 キーボードを無視するMac上のSwiftUIアプリは、名ばかりのMacアプリです。新規にCmd+N、閉じるにCmd+W、フォーカス移動にTab、選択に矢印キー。コストはアプリごとです。すべてのMacターゲットには、考え抜かれたキーボード表面が必要です。

Macにノーとなるシグナル：

ウィンドウの恩恵を受けない、小さく単一タスクのツールであるアプリ。 ユーザーが1日1回5分間動かす朝のタイマーには、Macターゲットは不要です。ユーザーはMacの隣にあるiPhoneでそれを動かせます。

iPhone型のUIが根本的に移植できないアプリ。 カメラアプリ。Apple Watchのコンパニオンアプリ。入力モデルがタッチファーストで、キーボード/マウスの同等物が電話を触るより悪くなるアプリ。

チームがMac固有の継続的なメンテナンスにコミットできない場合。 MacのリリースはiPhoneのリリースとは異なる精査を受けます。macOSのアップデートサイクル、Gatekeeperの署名、公証、Mac専用のApp Storeレビュー。これらはそれぞれ、チームが予算化しなければならないリリースサイクルの作業を追加します。チームがそれを予算化しないなら、ターゲットはスキップしましょう。

Apple Watchはランタイム契約

Watchは、「そこに出荷する」という指示が積極的に誤解を招くプラットフォームです。WatchのランタイムモデルはwatchOSランタイムはバックグラウンドタスクではなく契約であるで詳しく扱っていますが、iOSのものとは根本的に異なります。手首が落ちると、システムがアプリを一時停止し、特定のセッションタイプ（mindfulness、workout-processing、alarmなど）のみが一時停止後に動作可能です。ランタイムストーリーのないWatchターゲットは、2回目の使用で破綻します。

Watchにイエスとなるシグナル：

watchOSランタイムモデルが認識するセッション形状を持つアプリ。 瞑想タイマー（mindfulnessセッション）。フィットネスアプリ（workout-processing）。アラームクロック（alarm）。ナビゲーション（navigationセッションタイプ）。Returnは、瞑想がmindfulnessにきれいにマッピングされるためWatchで出荷しています。Watchアプリは手首が落ちている間もタイマーを動かし続けます。ランタイム契約がそれを許可しているからです。

ユーザーが本当に手首を入力面として求める場合。 運動中の心拍数ビューア。電話を取り出さずに開始するタイマー。一目で情報を表示するコンプリケーション。Get BananasはiPhoneの正典ストアと組み合わせた高速リストチェックの面としてWatchで出荷しています。Repsのようなワークアウトアプリも同じ理由でWatchターゲットを獲得しています。手首にセットを記録する方が、ポケットから電話を釣り出すより速いからです。

コンパニオンアプリの価値が本物の場合。 一部のWatchアプリは、主にiPhone駆動のデータの表示として存在します（例：iPhoneがタイマーを動かし、Watchが残り時間を表示するレシピタイマー）。これらが枠を獲得するのは、デバイス間同期が誠実に作られている場合（Single Source of Truth: SwiftData + MCP + iCloudで扱っています）、かつWatchビューがミラーリング以上の本物の仕事をする場合に限られます。

Watchにノーとなるシグナル：

主張できるセッションタイプがないアプリ。 Watch上の読書アプリは、名ばかりのWatchアプリです。ユーザーは手首で本を読めず、ランタイムモデルはセッションを延長しません。スキップ。

チームがwatchOS固有のデバッグにコミットできない場合。 Watchのデバッグは独特に痛みを伴います。シミュレータの動作は、実際のApple Watchで手首を落とした条件下でしか表面化しない仕方で、実機の動作と乖離します。チームがハードウェアと、それでテストする意欲を持たないなら、Watchターゲットは壊れた状態で出荷されます。

データモデルが1MBのデバイス間同期エンベロープに収まらない場合。 iPhoneからWatchへのデバイス間同期は通常、NSUbiquitousKeyValueStoreを経由します（マルチプラットフォーム出荷の記事で扱っています）。このストアは合計1MB + 値あたり1MB + 1024キーです。アプリのセッション状態がそのエンベロープに収まらないなら、Watchターゲットには別の同期アーキテクチャが必要となり、それは本物のエンジニアリング投資となります。

Visionは空間メンタルモデル

Vision Proは、3D空間に浮かぶ平面パネルとしてアプリを出荷するように誘惑します。そのパネルはSwiftUIのウィンドウであり、visionOS上のSwiftUIはそれをワンクリックの操作で出荷可能にします。そのパネルは、より劣ったiPadです。プラットフォームの本当の価値は、RealityKitと空間メンタルモデルで扱っている空間メンタルモデルから生まれます。そこではコンテンツがパネルではなく部屋の中に住んでいます。

Visionにイエスとなるシグナル：

部屋の中にあることから恩恵を受ける3Dコンテンツを持つアプリ。 ユーザーが歩き回れる仮想彫刻。実際の壁に当てるメジャー。鏡像のユーザーの体にフォームの手がかりを投影するワークアウトコーチ。クラスター内でvisionOSに登場するアプリのほとんどは、ネイティブvisionOSターゲットではなくDesigned for iPad互換性を経由しています。その互換性はユーザーにとっては問題ありませんが、アプリをVisionネイティブな体験にするものではありません。RealityKitの空間メンタルモデルに関する記事は、プラットフォームを獲得するということは、その上で動かすこと以上の何かを意味すると論じています。

ハンドトラッキングが正しい入力モデルである場合。 つまむような掴み、両手でのスケーリング、空中での描画。visionOSは他のどのプラットフォームも持たない入力アフォーダンスを与えます。visionOSの枠を獲得するアプリは、それに身を寄せます。

アプリが空間固有の表面（ロック画面相当、イマーシブスペース、オーナメント）を扱う場合。 iPhone UIをVision上に浮かべるだけの生産性アプリは、ユーザーがデバイスを使う初日から目に見えるノイズです。ユーザーを再び戻ってこさせるアプリは、空間表面を活用するものです。

Visionにノーとなるシグナル：

根本的にパネル形状で、奥行きから何の恩恵も受けないアプリ。 ノート取りアプリ、チャットアプリ、設定ユーティリティ。visionOSはそれらを動かしますが、ユーザーがiPadではなくvisionOSでそれらを使う理由はありません。スキップ。

開発チームがvisionOS固有のテスト環境を持たない場合。 visionOSは最小のインストールベースと最も脆弱なパターンを持つプラットフォームです。実機なしでVisionターゲットをテストするのは独特に困難で、watchOSのケースよりさらに難しいです。

プライバシーとプレゼンスの懸念が支配的な場合。 ヘルス情報を開示するアプリ。機密性の高い職場ツール。visionOSデバイスは、iPhoneとは異なる仕方で世帯のメンバー間で共有されます。プライベートな情報を表面化するアプリは、iPhoneとは異なる姿勢をそこで取る必要があります。

Apple TVはフォーカスエンジン

TVアプリはSiri Remoteのフォーカスエンジンによって駆動されます。ユーザーはリモコンでフォーカスハイライトを動かし、押して選択し、タッチインタラクションを目にすることはありません。tvOS上のSwiftUIは.focusable(...)修飾子、@FocusStateプロパティラッパー、状態バインディングのための.focused(...)を通じてこれをサポートしますが、すべてのTVアプリにはゼロからのフォーカスデザインが必要です。iPhoneのタップ＆スクロールモデルは移植できません。

TVにイエスとなるシグナル：

TV視聴距離でのコンテンツ消費のためのアプリ。 ストリーミングビデオ（Apple TV+、Netflix）。写真スライドショー。ユーザーがリモコンで操作するファミリーゲームアプリ。ユーザーはソファの上、画面は遠く、入力はまばら、TVが正しいプラットフォームなのです。

iPhoneにはない「リーンバック」のユースケースを持つアプリ。 ユーザーが一緒に動くワークアウト動画。コンロの前でユーザーが参照する料理アプリ。ユーザーが眠りながら聴くお休み前のお話。これらはどれも、コーヒーテーブルに立てかけた電話ではうまくサービスされません。

インタラクションモデルがまばらでフォーカス駆動のナビゲーションに合致する場合。 ユーザーが一度に1つずつ選ぶアイテムのリスト。オプションのグリッド。線形の再生フロー。それより複雑なもの、マルチタッチジェスチャー、細かいテキスト入力、ドラッグ＆ドロップは、tvOSでは動作せず、ターゲットが間違っていることを意味します。

TVにノーとなるシグナル：

アプリがテキスト入力を必要とする場合。 リモコン経由のTVテキスト入力は、Appleプラットフォームの中で最悪の入力モデルのひとつです。アプリが検索ボックス以上のものを必要とするなら、TVはスキップしましょう。

アプリの価値がユーザーの手が他の作業のために空いていることに依存する場合。 フィットネス追跡。ヘルスモニタリング。リアルタイムコラボレーション。TVは画面であり、ウェアラブルではありません。

インストールベースに対してメンテナンスコストが高すぎる場合。 tvOSはiOSに比べて小さなインストールベースを持ちます。開発コストは現実です（フォーカスデザイン、別のテスト、tvOS用のApp Storeレビュー）。ほとんどのアプリにとって、計算が枠を正当化しません。瞑想アプリがApple TVの枠を獲得するのは、ユースケースが本当に報いる「ソファに座っている間、低輝度で画面に出しっぱなしにする」モードがある場合のみです。そのモードがなければ、タイマーがTVのリーンバックパターンにきれいにマッピングされるアプリでさえ、メンテナンスの対価に値しません。

マトリクスを実践に移す

各クラスターアプリの実際のマトリクス：

パターン：各行は意図的な追加であると同時に、意図的な切り捨てでもあります。Returnが6プラットフォームに到達するのは、各々が具体的なユーザー価値テストを通じて正当化されるからであり、iPhone専用アプリがそこに留まるのは、他に何もないからです。同じツールチェーン、異なるプロダクト、異なるマトリクスです。

マトリクスを持続可能にする3つのアーキテクチャ判断

マルチプラットフォームアプリを自重で崩壊させない3つのパターン：

共有コアはプラットフォーム固有の表面のために#if canImport(SwiftUI) && canImport(<platform>)をターゲットにします。 コアドメインロジック（データモデル、ビジネスルール、同期）はどこでもコンパイルされます。プラットフォーム固有のUIはコンパイル時条件の背後に住みます。SwiftUIの@available(iOS 26.0, macOS 26.0, ...)はほとんどのケースをカバーします。本当に分岐する表面（iPhone同等物のないMacメニューバー、iPad同等物のないWatchコンプリケーション）は、ターゲット固有のグループに自分専用のファイルを持ちます。

デバイス間同期は1つの基盤を経由し、ドメインごとに選びます。 デバイスをまたいだ小さなセッションレベルの状態にはNSUbiquitousKeyValueStore（Returnはこれをデバイス間タイマー状態に使用しています）。プロセス間ブリッジにはiCloud DriveのJSONファイル（Get BananasはMCPサーバーとともにこれを使用しており、Single Source of Truthで扱っています）。プロセス内の状態にはSwiftData。基盤をドメインごとに混ぜるのは問題ありませんが、同じドメインに2つの基盤を使うことが、ドリフトを生む失敗モードです。

各プラットフォームには、アプリごとに文書化された明示的な拒否パターンがあります。 「ユースケースにリーンバックモードがなければTVには出荷しない」「アプリがパネルではなくRealityKitを使用しない限りVisionには出荷しない」「セッションタイプなしにはWatchに出荷しない」。これらの拒否はプロジェクトの判断であり、アプリごとに捉えて一貫して適用します。書かないと拒否するものの精神でです。

プラットフォーム追加が間違いとなる場合

より簡単な道が間違った道となる3つのケース。

チームがツールチェーンが容易にするからターゲットを追加する。 Xcodeの「ターゲットを複製」ウィザードは、MacやvisionOSターゲットの追加を4クリックの操作にします。その4クリックには、デザインレビュー、アクセシビリティ監査、App Storeのスクリーンショット作成、継続的なリリース調整、プラットフォームごとのテストは含まれていません。その作業を伴わずにウィザードから出荷されたターゲットは、初日から壊れています。

チームがターゲット数をステータスのシグナルとして扱う。 「我々は5つのAppleプラットフォームで出荷します」はローンチツイートでは印象的に聞こえます。ローンチツイートはユーザーのデバイスでは動きません。アプリが動くのです。両方を完璧に仕上げる2プラットフォームのアプリは、引き伸ばされた5プラットフォームのアプリよりも優れたプロダクトです。

チームが継続的メンテナンスを過小評価する。 各Appleプラットフォームは年に1回、メジャーOSアップデートをリリースします。5プラットフォームのアプリには、対応すべきリリースノートが5セット、テストすべき動作変更が5セット、最新に保つべきApp Storeメタデータが5セットあります。コストは複利で増えます。それらを維持する帯域なしに5つすべてに出荷するチームは、それらのプラットフォームのうち3つで徐々に劣化していくプロダクトを生み出します。

このパターンがiOS 26+で出荷するアプリにとって意味すること

3つのテイクアウェイ。

1. プラットフォームの組み入れは、エンジニアリングの判断ではなく、まずプロダクトの判断です。 Xcodeのチェックボックスはエンジニアリング側、ユーザー価値テストはプロダクト側です。「ユーザーがこのアプリをそのプラットフォームで動かすことから本当に恩恵を受けるか」という問いに明確な答えがなければ、ターゲットは切り捨てられます。

2. 各プラットフォームは具体的な責務をもたらします：サイズクラス（iPad）、ウィンドウ/メニュー/キーボード（Mac）、ランタイム契約（Watch）、空間モデル（Vision）、フォーカスエンジン（TV）。 責務を省くと、Mac上のiPadアプリ、Vision上の電話アプリ、Watch上のiPhoneアプリが生まれ、これらはすべてプラットフォームの実際のユーザーが気づく目に見える失敗となります。

3. ほとんどのアプリは1〜3プラットフォームで出荷すべきです。 4〜6プラットフォームは稀であり、各プラットフォームが本当にユーザー価値を加える場合にのみ獲得されます。クラスターのアプリは1〜6にまたがります。6プラットフォームのケース（Return）は規則を証明する例外であり、追加のプラットフォームはそれぞれ、独自のユーザー価値テストを伴う別個のプロダクト判断でした。

完全なApple Ecosystemクラスター：Apple Intelligence表面のための型付きApp Intents、エージェント表面のためのMCPサーバー、両者の間のルーティングの問題、アプリ内オンデバイスLLM機能のためのFoundation Models、ランタイム対ツーリングのLLM区別、3つの表面の統合、シングルソースオブトゥルースパターン、Xcode統合のためのTwo MCP Servers、Apple開発のためのフック、Live Activities、watchOSランタイム契約、SwiftUIの内部、RealityKitの空間メンタルモデル、SwiftDataスキーマ規律、Liquid Glassパターン、マルチプラットフォーム出荷、書かないと拒否するもの。ハブはApple Ecosystem Seriesにあります。AIエージェントを伴うiOSのより広い文脈については、iOS Agent Developmentガイドをご覧ください。

FAQ

Appleプラットフォームターゲットを追加するかどうかをどう判断しますか？

ツールチェーンが許すかではなく、ユーザーがそのプラットフォームでアプリを動かすことから本当に恩恵を受けるかを問うてください。Xcodeのチェックボックスは技術側、ユーザー価値テストはプロダクト側です。各プラットフォームは具体的な責務（サイズクラス、ウィンドウ/メニュー、ランタイム契約、空間モデル、フォーカスエンジン）と具体的なメンテナンスコストをもたらします。答えが「そこでも動く」であれば、正しい判断は通常、ターゲットをスキップすることです。

6つすべてのAppleプラットフォームで出荷すべきですか？

通常はノーです。ほとんどのアプリは1〜3プラットフォームから恩恵を受けます。4〜6プラットフォームは稀であり、各プラットフォームが本当にユーザー価値を加える場合にのみ獲得されます（Returnが6つすべてに到達するのは、mindfulnessセッションがWatchに合い、タイマーがデスクの相棒としてiPadとMacに合い、visionOSがイマーシブモードに合い、TVがリーンバックのソファのユースケースに合うからです）。ほとんどのアプリにとって、tvOSのインタラクションモデルとvisionOSの空間要件は合わず、正しい判断はそれらのターゲットをスキップすることです。

iPadターゲットを追加する際の最も一般的な間違いは何ですか？

iPadを「ピクセル数の多いiPhone」として扱うことです。サイズクラスへの適応なしにiPadに落とされたSwiftUIのiPhoneアプリは、引き伸ばされた単一カラムのUIを生み、iPadユーザーはそれを即座に中途半端な仕事として判定します。正しいパターンは、@Environment(\.horizontalSizeClass)を読み、レイアウトをより大きなキャンバスに適応させ（NavigationSplitView経由で意味のあるところは2カラム、そうでなければ快適な間隔の単一リスト）、Apple PencilとマルチフィンガーのアフォーダンスをiPad固有の価値として考慮することです。

Apple Watchはなぜ他のプラットフォームとそれほど異なるのですか？

watchOSはiOSのバックグラウンド実行モデルを持ちません。手首が落ちると、システムがアプリを一時停止し、特定のセッションタイプ（mindfulness、workout-processing、alarmなど）のみが一時停止後に動作可能です。クリーンなセッションタイプのないアプリは、2回目の使用で壊れる体験を生み出します。クラスターのwatchOSランタイム記事で契約を詳しく扱っています。

プラットフォームマトリクス全体でデバイス間同期はどう機能しますか？

3つの基盤：小さなキー値の状態（設定、最後に選択されたタブ、デバイス間タイマー状態）にはNSUbiquitousKeyValueStore、プロセス間ブリッジにはiCloud Driveのファイル（Get Bananas + MCPサーバーパターン）、プロセス内の状態にはSwiftData。ドメインごとに1つの基盤を選びましょう。同じドメインに2つを混ぜるとドリフトが生まれます。クラスターのシングルソースオブトゥルースの記事が判断マトリクスを案内しています。