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 のユーザー価値テスト：ユーザーはこのアプリをスマートフォンで開くだろうか？ほぼすべてのコンシューマーカテゴリにおいて、答えは Yes です。ヘルス・フィットネスアプリはスマートフォンに住んでいます。生産性ツールはスマートフォンに住んでいます。ゲームはスマートフォンに住んでいます。コミュニケーションツールはスマートフォンに住んでいます。デフォルトが iPhone なのは、スマートフォンこそユーザーがいる場所だからです。

例外は開発ツール（Xcode、Terminal）と、画面領域を必要とするクリエイティブツール（Final Cut、Logic）です。これらは Mac から始まり、明確なハンドオフ（ワークアウト中の Watch の心拍数を、スマートフォンがチャートで表示する場合や、Camera Continuity）がある場合にのみ iPhone コンパニオンを獲得します。コンシューマーソフトウェアにおいて、iPhone ファーストは議論の余地がありません。

iPad はピクセルが増えた iPhone ではない

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

iPad-Yes のシグナル3つ：

ユーザーがより多くの画面を望むコンテンツを読んだり作成したりするアプリ。 読書アプリ（Books、ニュース、コミック、長文ドキュメント）。ドローイング／ペイントアプリ（Procreate）。Apple Pencil でのノート取り（Notability、GoodNotes）。Get Bananas が iPad の枠を勝ち取ったのは、セクション付きの買い物リストが、狭いキャンバスより広いキャンバスでより便利になるからです。iPad のデザインは、同じセクションリストをより大きな領域に適応させます。

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

iPad ネイティブな入力アフォーダンスがあるアプリ。 スケッチや手書き用の Apple Pencil。より大きな表面でのマルチフィンガージェスチャー。タイルベースのレイアウトから恩恵を受ける Stage Manager ワークフロー。そのアフォーダンスが iPhone に存在しないのであれば、iPad ターゲットはその場所を勝ち取ります。

iPad-No のシグナル：

スケールアップしても追加価値がない単一カラムのコンテンツ。 瞑想タイマーの主ビューはカウントとボタンです。iPad は両方を大きくしますが、それは機能ではありません。素早く記録する水分摂取トラッカーも同様で、より広い画面は5秒の記録セッション中にユーザーがすることを変えません。

iPhone 固有のハードウェアに依存するアプリ（Dynamic Island、特定の Pro 専用カメラフォーマット、iPhone 形状のグリップ人間工学）。これらのデザイン仮定はうまく翻訳されません。デザインを再構築するか、ターゲットをスキップするかです。

ユーザーがすでに Mac により良い受け皿を持っているアプリ。 キーボードサポートのない iPad のコードエディタは、Mac アプリの不自由なバージョンです。iPad 固有の入力モデル上でデザインがその場所を勝ち取らない限り、ターゲットをスキップしてください。

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

ネイティブ macOS ターゲットまたは「Designed for iPad」（Mac Catalyst は UIKit コードを Mac に持ち込む UIKit 等価のパス）を介して Mac に出荷された SwiftUI アプリは、本物の Mac アプリを生み出すことなく macOS 上で動作します。² 本物の Mac アプリは、ウィンドウのリサイズ意味論、メニューバー（SwiftUI の CommandMenu と CommandGroup ビルダーを伴う .commands { } Scene モディファイア）、キーボードショートカット、macOS のファイルピッカー、Finder とのドラッグ＆ドロップ、そして Mac ネイティブの共有を尊重します。³ これらのいずれかを省略すると、Mac ユーザーが気づき判断する「ウィンドウ内の iPad アプリ」体験が生まれます。

Mac-Yes のシグナル：

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

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

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

Mac-No のシグナル：

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

iPhone 形状の UI が根本的に翻訳されないアプリ。 カメラアプリ。Apple Watch コンパニオンアプリ。入力モデルがタッチファーストで、キーボード／マウス相当の操作がスマートフォンに触るより悪くなるアプリ。

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

Apple Watch はランタイム契約です

Watch は「出荷する」が積極的に誤解を招く指示となるプラットフォームです。Watch のランタイムモデルは watchOS Runtime Is a Contract, Not a Background Task で詳しく扱っており、iOS のものとは根本的に異なります。手首が下がるとシステムはアプリを停止し、特定のセッションタイプ（WKExtendedRuntimeSession の self-care、mindfulness、physical-therapy、alarm、加えて HKWorkoutSession の workout-processing、ダイブセッションの underwater-depth）のみがサスペンド後に動作できます。⁴ ランタイムストーリーのない Watch ターゲットは、2回目の使用で壊れます。

Watch-Yes のシグナル：

watchOS ランタイムモデルが認識するセッション形態を持つアプリ。 瞑想タイマー（mindfulness セッション）。フィットネスアプリ（workout-processing バックグラウンドモードの HKWorkoutSession）。スマートアラーム（alarm）。理学療法・セルフケアアプリ（対応するセッションタイプ）。Return が Watch に出荷されているのは、瞑想が mindfulness にきれいにマッピングされるからです。Watch アプリは、ランタイム契約がそれを許すため、手首が下がってもタイマーを動かし続けます。

ユーザーが本当に手首を入力表面にしたいアプリ。 運動中の心拍数ビューア。スマートフォンを取り出さずに開始するタイマー。一目で情報を表示するコンプリケーション。Get Bananas は iPhone のキャノニカルストアと組み合わせた素早いリストチェック表面として Watch に出荷されています。Reps のようなワークアウトアプリは同じ理由で Watch ターゲットを勝ち取っています。手首でセットを記録する方が、ポケットからスマートフォンを取り出すより速いからです。

コンパニオンアプリの価値が本物である場合。 一部の Watch アプリは、主に iPhone 駆動のデータの表示として存在します（例：iPhone がタイマーを動かし、Watch が残りカウントを表示するレシピタイマー）。これらが枠を勝ち取るのは、デバイス間同期が誠実に構築されている場合（Single Source of Truth: SwiftData + MCP + iCloud で扱っています）と、Watch ビューがミラーリングを超えた本物の仕事をしている場合のみです。

Watch-No のシグナル：

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

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

データモデルがデバイス間同期のエンベロープに収まらない場合。 iPhone から Watch へのデバイス間同期は、ライブ状態には WatchConnectivity、小さな永続化状態には NSUbiquitousKeyValueStore を使うのが一般的です（Return はセッション履歴の同期に後者を使用しています。マルチプラットフォーム出荷の投稿で扱っています）。このストアは全キー合計で 1 MB の上限があり、最大1024キーまでです。⁵ アプリのセッション状態がそのエンベロープに収まらないなら、Watch ターゲットには異なる同期アーキテクチャが必要となり、それは本物のエンジニアリング投資となります。

Vision は空間メンタルモデルです

Vision Pro はアプリを3D空間に浮かぶフラットなパネルとして出荷したくなる誘惑があります。そのパネルは SwiftUI のウィンドウであり、visionOS 上の SwiftUI はそれをワンクリック操作で出荷可能にしています。そのパネルは劣化版 iPad です。プラットフォームの真の価値は RealityKit and the Spatial Mental Model で扱っている空間メンタルモデルから来ます。コンテンツがパネル内ではなく部屋の中に存在するのです。

Vision-Yes のシグナル：

部屋の中にあることから恩恵を受ける3Dコンテンツがあるアプリ。 ユーザーが歩き回れる仮想彫刻。実際の壁に貼り付けるメジャー。ユーザーの体のミラーイメージにフォームの手がかりを投影するワークアウトコーチ。visionOS 上に現れるクラスタアプリのほとんどは、ネイティブ visionOS ターゲットではなく「Designed for iPad」互換性を介してそうしています。その互換性はユーザーにとっては問題ありませんが、アプリを Vision ネイティブな体験にするわけではありません。RealityKit の空間メンタルモデル の投稿は、プラットフォームを勝ち取ることはそこで動作させること以上を意味すると論じています。

ハンドトラッキングが正しい入力モデルである場合。 ピンチで掴む、両手でスケーリング、空中でのドローイング。visionOS は他のプラットフォームにはない入力アフォーダンスを提供します。visionOS の枠を勝ち取るアプリはそれに乗り込みます。

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

Vision-No のシグナル：

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

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

プライバシーとプレゼンスの懸念が支配的な場合。 ヘルス開示アプリ。センシティブな職場ツール。visionOS デバイスは iPhone とは異なる方法で家族メンバー間で共有されます。プライベートな情報を表面化するアプリは、iPhone とは異なるそこでの姿勢が必要です。

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

TV アプリは Siri Remote のフォーカスエンジンによって駆動されます。ユーザーはリモコンでフォーカスハイライトを動かし、選択するために押し、タッチ操作を一切見ません。tvOS 上の SwiftUI は .focusable(...) モディファイア、@FocusState プロパティラッパー、状態バインディング用の .focused(...) を通じてこれをサポートしますが、すべての TV アプリにはゼロからフォーカスデザインが必要です。⁶ iPhone のタップ＆スクロールモデルは翻訳されません。

TV-Yes のシグナル：

TV を見る距離でのコンテンツ消費のためのアプリ。 動画ストリーミング（Apple TV+、Netflix）。写真スライドショー。ユーザーがリモコンで操作する家族向けゲームアプリ。ユーザーがソファにいて、画面が遠く、入力が疎、これが TV が正しいプラットフォームである場合です。

iPhone にはない「リーンバック」のユースケースを持つアプリ。 ユーザーが一緒に行うワークアウトビデオ。コンロにいる間にユーザーが参照する料理アプリ。寝ている間にユーザーが聴くおやすみストーリー。これらはどれもコーヒーテーブルに立てかけたスマートフォンではうまく機能しません。

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

TV-No のシグナル：

アプリにテキスト入力が必要な場合。 リモコンでの TV のテキスト入力は、どの Apple プラットフォームでも最悪の入力モデルのひとつです。アプリに検索ボックス以上のものが必要なら、TV をスキップしてください。

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

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

実践におけるマトリクス

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

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

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

マルチプラットフォームアプリが自重で崩壊することを防ぐ3つのパターン：

共有コアは #if os(iOS)、#if os(macOS)、#if os(watchOS)（および類似）を使用してプラットフォーム固有の表面をゲートします。⁷ コアドメインロジック（データモデル、ビジネスルール、同期）はどこでもコンパイルされます。プラットフォーム固有の UI はコンパイル時条件分岐の背後に存在します。SwiftUI の @available(iOS 26.0, macOS 26.0, ...) は OS バージョンの差異をカバーします。プラットフォーム間で本当に分岐する表面（iPhone 相当のないMac メニューバー、iPad 相当のない Watch コンプリケーション）は、#if os(...) ゲートの背後にあるターゲット固有グループ内の独自ファイルを取得します。

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

各プラットフォームには、アプリごとに文書化された明示的な拒否パターンがあります。 「ユースケースにリーンバックモードがない限り、TV には出荷しません。」「アプリがパネルではなく RealityKit を使わない限り、Vision には出荷しません。」「セッションタイプなしでは Watch に出荷しません。」拒否はアプリごとに記録され一貫して適用されるプロジェクト判断であり、What I Refuse To Write About の精神に則っています。

プラットフォーム追加が間違っているとき

簡単な道が間違っている3つのケース。

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

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

チームが継続的なメンテナンスを過小評価する場合。 各 Apple プラットフォームは毎年メジャー OS アップデートをリリースします。5プラットフォームのアプリには反応すべき5セットのリリースノート、テストすべき5セットの動作変更、最新に保つべき5セットの App Store メタデータがあります。コストは複合します。メンテナンスする帯域幅なしに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つの表面の総合、Single Source of Truth パターン、Xcode 連携のための Two MCP Servers、Apple 開発のためのフック、Live Activities、watchOS ランタイム 契約、SwiftUI の内部、RealityKit の空間メンタルモデル、SwiftData スキーマ規律、Liquid Glass パターン、マルチプラットフォーム出荷、書かないと拒むこと。ハブは Apple Ecosystem シリーズ にあります。AI エージェントを伴うより広範な iOS のコンテキストについては、iOS Agent Development ガイド を参照してください。

FAQ

Apple プラットフォームターゲットを追加するかどうかはどう決めればよいですか？

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

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

通常は No です。ほとんどのアプリは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 のバックグラウンド実行モデルを持ちません。手首が下がるとシステムはアプリを停止し、特定のセッションタイプ（WKExtendedRuntimeSession の self-care、mindfulness、physical-therapy、alarm、加えて HKWorkoutSession の workout-processing）のみがサスペンド後に動作できます。⁴ きれいなセッションタイプのないアプリは、2回目の使用で壊れる体験を生み出します。クラスタの watchOS ランタイム投稿 が契約を詳しく扱っています。

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

3つの基盤：小さなキー値状態（設定、最後に選択されたタブ、デバイス間タイマー状態）には NSUbiquitousKeyValueStore、⁵ プロセス間ブリッジには iCloud Drive ファイル（Get Bananas + MCP サーバーパターン）、プロセス内状態には SwiftData。ドメインごとに1つの基盤を選択してください。同じドメインに2つを混合するとドリフトが生まれます。クラスタの single source of truth 投稿 が判断マトリクスを歩いています。

References