Mac CatalystだけでAPIのシンボルやメンバーが見つからず、iOSではビルドできる状態ですか。
最短の判断は、同じコミットで両方のビルド先を比較し、APIの対応範囲とXcode 27.2 RCのリリースノートを確認することです。Beta 2に記録された問題をRCにも当てはめず、RCの記載と手元での再現を確かめてから、条件コンパイルまたはツールチェーンの調整を選びます。
この記事は、iOSとMac Catalystでコードを共有する個人開発者や小規模チーム向けです。
Catalystだけで発生するシンボル・メンバーのエラーを、アプリ全体の不具合と決めつけずに切り分けたい場合に役立ちます。
最終更新：2026年10月29日。Xcode 27.2 RCの公開状況と既知問題は、AppleのRCリリース記録およびRCリリースノートを確認対象としています。Beta 2で記録された内容とRCで確認できた内容は、別々に扱います。
ビルド先ごとの違いから原因を絞る
最初に、同一コミット、同じスキーム、同じ構成でiOSとMac Catalystをビルドします。両方が失敗するなら、Catalyst固有のAPI制限よりも、共通コードの型エラー、依存関係、ビルド設定などを先に調べます。
AppleはXcode 27.2 RCを公開していますが、RCが公開された事実だけでは、Beta 2の既知問題が継続中か解消済みかは判断できません。まずRCのリリースノートを確認し、対象SDKやシステムの条件はAppleのXcodeシステム要件と照合してください。
| 症状 | 先に確認すること | 次の判断 |
|---|---|---|
| iOSとCatalystの両方で失敗 | 最初のエラー、共通コード、依存関係 | まず共通のコンパイル原因を調査 |
| Catalystだけで失敗 | 呼び出しAPIの対応プラットフォーム、実際のビルド先 | API範囲かCatalyst固有の問題かを分ける |
| エラーが出たり消えたりする | 使用したXcode、SDK、構成、キャッシュの有無 | 条件を固定して再現性を確認 |
コマンドラインのビルドでは、まずXcodeの選択状態とスキームを記録します。xcodebuildのオプションや設定値は、Appleのコマンドラインツール資料を参照してください。
xcodebuild -version
xcodebuild -list
xcodebuild -showBuildSettings -scheme App
出力例では、Xcodeのバージョンに加え、ビルド設定のSDKROOTやPLATFORM_NAMEを記録します。以下は確認対象の例であり、特定のプロジェクトで必ず同じ値になるという意味ではありません。
Xcode 27.2
SDKROOT = ...
PLATFORM_NAME = ...
同じスキームでも、選択した実行先や構成によって実際のビルド条件は変わります。記録した設定が意図したiOSまたはMac Catalystのものかを確認してから、エラー比較に進みます。
APIが見つからない場合の確認順
iOS 27.1専用APIがMac Catalystで見つからない理由
iOSでは使用できるAPIでも、Mac Catalystで同じように利用できるとは限りません。エラーの最初の行から型名・メンバー名・呼び出し元ファイルを特定し、そのAPIが対象SDKとMac Catalystで利用できるかをAppleの資料で確認します。Mac Catalystの仕組みや対応範囲を調べる際は、iPadアプリのMac版を作成するAppleの資料も参照できます。
Beta 2のリリースノートには、iOS 27.1専用APIを使用するプロジェクトでMac Catalystのコンパイルエラーが起きる既知問題と、条件コンパイルによる回避策が記録されています。ただし、この記載が示すのはBeta 2での既知問題です。RCでも同じ症状が発生すると断定せず、Beta 2の記録とRCの記載を分けて照合してください。
| エラーの見え方 | API側で調べる点 | 工具側で調べる点 |
|---|---|---|
| 「型が見つからない」 | 型が対象SDK・プラットフォームで公開されているか | 選択中のSDKとビルド先 |
| 「メンバーが存在しない」 | メンバーの利用可能条件、APIの対応範囲 | RCノートに同種の既知問題があるか |
| ヘッダーやモジュールを読み込めない | import、依存関係、条件付き公開設定 | ビルド構成と検索パス |
ここで大切なのは、似たエラーメッセージだけを根拠に既知問題と決めないことです。API自体がMac Catalystを対象としていない場合と、対象APIをコンパイラが正しく扱えていない場合では、修正方法が異なります。
共有コードに条件コンパイルを適用する
iOS専用の実装をCatalyst向けビルドから除外する必要がある場合は、エラーが出る行だけでなく、専用APIを参照する型、プロパティ、呼び出し元まで確認します。呼び出し箇所だけを囲っても、共有ファイルの初期化処理やプロトコル適合部分が同じAPIを参照していれば、コンパイルエラーが残ることがあります。
| 言語 | 条件コンパイルの考え方 | 注意点 |
|---|---|---|
| Swift | targetEnvironment(macCatalyst)などの条件で対象環境を分ける |
APIを参照する宣言と呼び出し側の両方を確認 |
| Objective-C | TargetConditionals.hのプラットフォーム判定マクロを利用する |
マクロの定義と、条件対象のファイルがビルドに含まれるかを確認 |
Swiftでは、たとえばCatalyst以外に限定するコードを次のように分けられます。実際の条件は、APIの対応範囲とAppleの記録に合わせて選んでください。
#if !targetEnvironment(macCatalyst)
func useIOSOnlyAPI() {
// iOSで利用する処理
}
#endif
Objective-Cでは、一般にTargetConditionals.hで定義されるプラットフォーム条件を使って分岐します。プロジェクトで使用するマクロ名と適用条件は、対象SDKのヘッダーおよびAppleの資料で確認し、Swiftの記法をそのまま転用しないでください。
条件コンパイルは、APIをCatalystで使えるように変換する仕組みではありません。対象外のコードをそのビルドから除外する方法です。アプリの機能として両方のプラットフォームに必要なら、Catalyst用の代替実装や機能縮退時の挙動も設計する必要があります。
条件コンパイル後に検証する項目
修正後は、エラーが消えたことだけで完了にせず、iOS側で必要な処理が残っていること、Catalyst側で除外範囲が適切なこと、共有コードの別経路が未保護でないことを確かめます。
- [ ] 同じコミットからiOSとMac Catalystの両方をビルドする
- [ ] エラーが出たAPIの宣言・呼び出し元・初期化経路を確認する
- [ ] 条件コンパイルがAPIを参照する全経路を対象にしている
- [ ] iOSビルドで専用機能が引き続きコンパイルされる
- [ ] Catalystビルドで代替動作または機能制限が意図どおりである
- [ ] Xcode、SDK、構成、ビルド先を記録し、再現条件を残す
RCの回避策を再確認する
Xcode 27.2 RCでもBeta 2の回避策は有効か
Beta 2の記載だけでは、RCでの有効性は確定できません。RCリリースノートに問題や修正の記載があるかを確認し、記載が見当たらない場合も「解消済み」とは決めず、同じプロジェクト条件で再現するかを調べます。
回避策を適用したのに失敗する場合は、条件が実際のエラー経路を覆っているか、ビルド先とSDKが想定どおりかを順に見直してください。別のエラーに変わった場合は、元の問題が残っていると即断せず、新しく発生した箇所から調査をやり直します。
| 状況 | 判断 | 対応 |
|---|---|---|
| RCノートに該当記載があり、同じ条件で再現 | RCでの問題として報告可能 | 再現情報とログを整理 |
| RCノートに記載がなく、手元では再現 | RCの一般的な問題とは断定しない | 最小再現を作り、Appleへ報告 |
| 手元で再現しない | 解消済みと一般化しない | Xcode・SDK・構成の差を記録 |
リリース候補版の状態を判断する材料は、Appleの公開情報と再現可能なプロジェクト結果です。RCノートに未記載であることだけを理由に「問題なし」と結論づけるのも、Beta 2での記録だけを理由に「RCにも残っている」とするのも適切ではありません。
iOSだけ成功する場合の最小再現
iOSは成功しCatalystだけが失敗するなら、プロジェクト全体を切り離す前に、同一コミット・同一スキームでそれぞれのビルドを実行し、結果を比較します。差が出たら、エラーが起きるファイルとAPI呼び出しだけを残した最小構成にして、依存ライブラリや独自ビルド設定が原因に混ざっていないかを調べます。
再現記録には、少なくとも次の情報を含めます。
- Xcodeのバージョンと、選択されている開発者ディレクトリ。
- iOSとMac Catalystそれぞれのビルド先、SDK、構成。
- 同一コミットで実行したコマンドと、失敗した最初の完全なエラー。
- エラーを起こす最小コードと、条件コンパイルを加えた場合の差。
- クリーンなビルドでも再現するかどうか。
Appleへ問題を報告する場合は、再現手順、最小プロジェクト、関連ログをまとめてから、Feedback Assistantの現在の案内に従います。単一のプロジェクトで起きた結果は、その構成での再現結果として記述し、すべてのCatalystアプリに共通する不具合として広げないことが重要です。
2つのビルド先を安定して比較する環境
一台のMacで両方をビルドできれば、同一コミットからiOSとCatalystを連続して検証しやすくなります。一方、ローカル環境では空き容量やXcodeの更新タイミング、作業中の構成変更が比較条件に影響することがあります。別のMac環境を使う場合も、バージョンと設定を記録し、同じ手順を再実行できる形に整える必要があります。
| 確認方法 | 向いている場面 | 判断上の制約 |
|---|---|---|
| 手元のMacで両方をビルド | 日常的な開発、接続機器を使う検証 | ローカルの空き容量や設定変更が再現性に影響 |
| 別のMac環境で再現 | 手元の環境と切り分けたい場合 | Xcode・SDK・構成を揃えないと比較にならない |
| CIのビルド結果を使う | 継続的な回帰確認 | ログと実行環境を保存しないと後から追跡しにくい |
ViewMiniの日本向けMac環境を使う場合も、まずXcodeのバージョン、SDK、対象プラットフォームを記録し、ローカル環境と同じコミットで比較してください。利用条件や環境の概要はViewMiniのサービス案内で確認できます。なお、ここではXcode 27.2 RCを使ったViewMini環境の実測記録を提示できないため、特定構成での成功や互換性を保証するものではありません。
ローカルMacで安定して二つのビルド先を比較でき、継続的な検証も不要なら、手元の環境を整えるのが合理的です。反対に、RCの再現確認だけを分離したい、または常時使うビルド環境を用意する前に短期間試したい場合は、Macを購入する前にレンタル環境を選択肢として比較できます。WindowsやLinux上の代替環境ではXcodeを使うMac Catalystビルドを直接確認できず、単発の再現でも設定差が残ることがあります。遠隔Macの利用もネットワーク接続や環境設定が必要ですが、条件を記録して独立したMac上で同じ検証を繰り返したい場合は、ViewMiniの利用条件を確認してから判断できます。
Catalystのビルド検証に、専有のMac環境を
ViewMiniの専有物理Macで、開発ツールや依存関係をプロジェクトに合わせて構成できます。