はじめに (対象読者・この記事でわかること)

この記事は、すでにApp Storeにリリース済みのiOSアプリを「Xcode 15以降」でアップデートしようとしたところ、App Store Connectで「Invalid Binary」エラーが出てしまい審査に進めない……という困難に直面した開発者の方を対象にしています。

私自身、2024年冬に4年間運用しているSwift製アプリを最新化しようとした際、同エラーに遭遇し3日間はまってしまいました。本記事ではその際の調査と試行錯誤をもとに、「Invalid Binary」が出る代表的な3つの原因と、それぞれの切り分け・解決手順を実際のスクリーンショット付きで共有します。記事を読み終える頃には、ビルド設定・署名・フレームワークの見直しがスムーズに行えるはずです。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。

  • iOSアプリのビルド・Archive・App Store Connect提出の基本的な流れ
  • Apple Developer Programでの証明書(App Store用配布証明書)・プロビジョニングプロファイルの作成経験
  • CocoaPodsまたはSwift Package Manager(SPM)で外部ライブラリを導入したことがある
  • ターミナルでxcodebuildコマンドを叩いたことがある（エラー調査時に便利）

App Store提出で「Invalid Binary」が急増した背景

2023年秋にリリースされたXcode 15以降、Appleはバイナリ検証ロジックを強化し、従来は審査通過していた細かな違反（無効なアーキテクチャ、重複フレームワーク、Info.plist不足など）を「Invalid Binary」として却下するようになりました。特に以下のケースで該当エラーが出やすくなっています。

  • ビルド設定でVALID_ARCHSやEXCLUDED_ARCHSを古いままにしている
  • CocoaPodsでuse_frameworks!を指定したまま、一部のフレームワークが静的にビルドされている
  • 新しいPrivacy Manifest（PrivacyInfo.xcprivacy）が未追加
  • 配布用プロビジョニングプロファイルがApp Store用ではなくAd HocやDevelopmentのまま

Invalid Binaryを解消するための切り分け手順

ここでは、実際に私が行った「エラーが出た→原因を切り分けた→解決した」までの道筋を3ステップで紹介します。すべての手順はXcode 15.3以降・macOS 14以降で検証済みです。

ステップ1：ビルドログで「IDEDistribution.standard.log」を読む

  1. Archive後、Organizerで「Distribute App」を押す前に、該当Archiveを右クリックし「Show in Finder」→Products/Applications/アプリ名.xcarchiveを探します
  2. ターミナルで以下を実行し、ログを抽出
    bash xcrun iderutil --extract-idistribution-logs アプリ名.xcarchive
  3. 出力されたIDEDistribution.standard.logをVSCodeなどで開き、error/warningでフィルタ
  4. 以下のような文言があれば、該当箇所を優先的に修正 - Unsupported architecture 'arm64e' - Found duplicate frameworks:（同一フレームワークが複数バンドルされている） - Missing required bundle identifier（Embed Frameworksでproductモジュールが重複）

ステップ2：CocoaPods/SPMの重複フレームワークを排除

CocoaPodsを使っている場合、Podfileを以下のように見直します。

Ruby

platform :ios, '15.0'
use_frameworks! :linkage => :static   # 静的リンクを明示
# 動的にしたいライブラリのみ個別指定
dynamic_frameworks = ['FirebaseAnalytics']
dynamic_frameworks.each do |framework|
  use_frameworks! :linkage => :dynamic, :frameworks => [framework]
end

SPMの場合、Xcode 15では「Embed & Sign」がデフォルトになるため、不要なターゲットにEmbedが付いていないか確認します。

  • Project Navigator → ターゲト→General→Frameworks, Libraries, and Embedded Content
  • 同一フレームワークが「Embed & Sign」と「Do Not Embed」の両方に存在していないかチェック
  • 重複していたら、App ClipやWidget Extensionなどの拡張ターゲト→Embedを「Do Not Embed」に

ステップ3：Privacy Manifestを追加・ビルド設定を最新化

  1. File → New → File → App Privacyテンプレートを選択しPrivacyInfo.xcprivacyを作成
  2. 必要なNSPrivacyAccessedAPITypes（例：NSPrivacyAccessedAPICategoryFileTimestamp）を記載
  3. Build Settingsで以下を確認 - ENABLE_BITCODE → NO（Xcode 15で非推奨） - VALID_ARCHS行を削除（標準アーキテクチャに任せる） - IPHONEOS_DEPLOYMENT_TARGETを15.0以上に
  4. Archive→Distribute App→App Store Connect→Uploadまで進み、エラーが消えることを確認

ハマった点：エラーメッセージが「Invalid Binary」の1行のみで具体的な原因がわからない

Apple側のメールやConnectのIssuesタブに「Invalid Binary」としか出ないため、最初は方針が見えませんでした。上記ログ抽出スクリプトを使う前は、以下の「手がかりなし」運を頼りにしていました。

  • 別のMacでビルド→結果は同じ
  • 新規プロビジョニングプロファイルを作り直し→変化なし
  • CocoaPodsを丸ごと外してみる→エラー変化せず

解決策：「IDEDistribution.standard.log」にたどり着くまで

Twitterの開発者コミュニティで同様の報告を見つけ、Repliesでidistribution-logsコマンドを教えてもらいました。ログを見た瞬間に「重複フレームワーク」が原因であることが判明。即座に上記ステップ2を適用したところ、審査提出まで復活しました。重要なのは「エラーメッセージが乏しくても、ログはちゃんと出ている」という事実です。

まとめ

本記事では、Xcode 15以降で急増した「Invalid Binary」エラーの原因切り分けと、実践的な対処法を紹介しました。

  • エラー原因の大半は「重複フレームワーク」「無効アーキテクチャ」「Privacy Manifest未追加」の3パターン
  • idistribution-logsコマンドで詳細ログを抽出し、重複・無効箇所を特定
  • CocoaPods/SPMのEmbed設定とBuild Settingsの見直しで9割が解決

この記事を通して、審査提出前のビルドエラーを自力で解消できるようになり、App Storeでのリリースサイクルがスムーズになることを願っています。次回は「App Store Connect APIを使ったCI/CD自動化」について、実践的なワークフローを紹介予定です。

参考資料