SwiftUI Previewが表示されない？2026年リモートMacでの切り分け

AppleのXcode 27.2 Betaリリースノートには、別ユーザーが所有するPreviews JITディレクトリに関する特定のエラーへの対応が記載されています。リモートMacでSwiftUI Previewが表示されないときは、まずPreview Diagnosticsで最初の有効なエラーを確認し、通常のBuildと最小のプレビュー例、対象ランタイムを照合してください。原因を特定する前にキャッシュを一括削除したり、Xcodeを再インストールしたりするのは避けましょう。

この記事は、リモートMacでSwiftUIファイルを編集しているのに、Xcode Canvasが空白、更新エラー、起動失敗になる独立開発者向けです。
通常のBuildは成功するのにPreviewだけ動かない場合や、複数人で使うMacのユーザー権限が気になる場合にも、確認順を追って原因を絞れます。

SECTION 01最初に、画面の症状を分けてください

「Previewが表示されない」は、Canvasが閉じている、更新が停止している、プレビューのビルドに失敗する、起動後にクラッシュする、といった異なる状態をまとめた表現です。Canvasの表示状態とIssue navigatorを確認し、Preview Diagnosticsに残る最初の具体的なエラーを記録してください。Canvasでプレビューを操作・診断する方法も、表示の操作と診断情報を確認する際に参照できます。

通常のBuildが通ることは、Previewの実行まで成功する証明にはなりません。ビルド結果とPreviewの更新結果を分けて記録し、エラー全文ではなく「最初に失敗した処理」「対象のTarget」「読み込めなかったモジュール」を控えます。

SECTION 02最小のViewで、ファイルとPreviewコードを切り分けます

プロジェクト内に、外部データや独自依存を使わない小さなSwiftUI Viewを用意し、#Previewから表示できるかを確かめます。AppleのインターフェイスファイルにPreviewを追加する説明に沿って、プレビュー宣言の書き方と配置も確認してください。

最小例は表示できるのに、対象の画面だけ失敗するなら、対象Viewの初期化引数、プレビュー用データ、画像やリソースの読み込み、起動時に実行する処理を一つずつ外します。反対に、最小例まで表示できない場合は、個別の画面コードを直し続けず、Schemeやランタイム、Previewの実行環境を先に調べます。

遠隔操作中に別のファイルを開いていると、意図したViewではなく別のファイルの状態を見ていることがあります。Canvasが対象ファイルに追従しているかも確かめ、エラーの再現条件とともに記録してください。

SECTION 03Previewだけ失敗するなら、対象とランタイムを照合します

SwiftUI Previewが空白でもプロジェクトをBuildできる場合は、まずPreviewに選択されているScheme、Target、プラットフォーム、デバイス環境を確認します。選択した環境のランタイムが利用可能か、アプリのDeployment Targetと食い違っていないかも見ます。ランタイムやDeployment Targetを変更すると通常のビルドやテスト対象にも影響するため、Previewを直す目的だけで安易に変更しないでください。

AppleのXcode Build Settingsリファレンスでは、ビルド設定の意味を確認できます。設定名を推測で書き換えず、対象のTargetと構成を特定してから、プロジェクト本来の設定と照らし合わせてください。

「Preview Update Error」はどこから読みますか？

Preview Diagnosticsに表示された項目のうち、最初に実際の失敗を示しているエラーから追います。後続のエラーが多数並んでいても、最初の失敗が原因で関連処理が連鎖的に止まっただけの場合があります。診断情報からTarget、依存製品、読み込み対象、ビルドパスを特定し、問題が起きた箇所に絞って調べてください。

次の条件分岐で、確認する場所を決められます。

• 最小Viewは表示でき、対象Viewだけ失敗するなら、対象コード、初期化引数、プレビュー用データを調べます。
• 通常のBuildも失敗するなら、Previewではなく最初のビルドエラーとTarget設定を先に直します。
• Buildは通り、最小Viewも失敗するなら、選択中のScheme、プラットフォーム、ランタイムを照合します。
• 診断ログがモジュールやオブジェクトファイルを指すなら、該当する依存関係とビルドパスを確認します。
• JITディレクトリの所有者やアクセス拒否が明示されているなら、実行ユーザーとディレクトリの所有者を確認します。根拠がない状態で全体の権限を変更しないでください。

SECTION 04JITやディレクトリの権限エラーは、実行ユーザーから調べます

「モジュールが見つからない」「オブジェクトファイルを読み込めない」「署名を確認できない」といった診断があれば、対象のTargetと依存製品、ビルド成果物の場所をたどります。複数のエラーをまとめてDerivedDataの破損と決めつけると、依存関係やアクセス権の問題を見落とすことがあります。

リモートMacを複数人で使う場合は、Xcodeを起動したユーザー、プロジェクトファイルにアクセスするユーザー、Previewのビルドディレクトリを所有するユーザー、遠隔ログイン中のアカウントが一致しているかを確かめます。まず権限を広げるのではなく、対象ユーザーのまま最小Viewを開いた場合と比較してください。

Xcode 27.2 Betaのリリースノートが記しているのは、「別ユーザーアカウントがPreviews JITディレクトリを所有する」という特定の失敗条件に関するエラー表示の改善です。これは、そのバージョンの説明にある個別事例であり、すべてのPreview障害が複数ユーザーやJITに起因するという意味ではありません。Apple Developer Forumsの個別の開発ツールに関する投稿も、ひとつの事例として読み、手元の診断ログと照合してください。

SECTION 05修正後は、Preview・Simulator・配布用ビルドを別々に確認します

復旧を確認するときは、Canvas上で同じPreviewが再び更新されることだけで終わらせず、必要な検証をそれぞれ実行します。Previewの成功は、Simulatorでの実行や配布用アーカイブが成功することを保証しません。

• Preview：同じViewでCanvasを更新し、意図したプレビューが表示されるか確認します。
• 通常のBuild：選択したSchemeとTargetでビルドが完了するか確認します。
• Simulator：同じアプリをシミュレート環境で起動し、画面遷移や実行時の挙動を確認します。
• 実機：実際のデバイスで確認が必要な機能を検証します。
• 配布用アーカイブ：リリース作業に進む場合は、配布用の構成と署名を別途確認します。Simulatorまたは実機でアプリを実行する手順とアプリの配布手順は、それぞれの検証範囲を確認する資料です。

修正内容、対象ユーザー、選択したランタイム、成功した検証をメモに残しておくと、次回の更新失敗時に「環境が変わったのか」「対象コードが変わったのか」を比較しやすくなります。遠隔環境での結果は、利用中のMacとプロジェクトで実際に再現・確認した記録に基づいて判断してください。

SECTION 06既存環境を直すか、リモートMacを使い分けるか

手元の構成で原因が特定できるなら、その環境を維持する方が合理的です。一方、macOSを使えない開発端末ではXcodeのネイティブな作業環境を用意できず、共有Macのユーザーや権限が揃わない環境では、Previewの実行場所を管理する手間が残ります。キャッシュ削除や再インストールを繰り返しても、アカウントやランタイムの不一致は解消しません。

一時的な調査や、Xcodeを含むmacOS環境が必要な期間だけ利用したい場合は、Macを購入する前にレンタルも比較できます。継続的な重い処理や物理デバイス接続が必要なら、自前のMacが適するケースもあるため、作業内容と利用期間で判断してください。必要な期間だけ遠隔の開発環境を試す場合は、MACNOXの利用プランを確認し、利用を決める前に申込み方法とプロジェクトの権限要件を照合してください。

SECTION 07関連記事

• リモート環境でのiOS Simulator起動と画面表示を切り分ける
• SwiftUIの最小プロジェクトを作り、プレビューや実行環境を確認する