@omatsu393posted at 2026-06-17

Xcode 27 betaで特定のSwiftUIプロジェクトだけ、Debug executableをONにするとdyld4::startでEXC_BAD_ACCESSになる

Q&A

解決したいこと

SwiftUIで開発しているiOSアプリを実機でデバッグしようとすると、Debug executableがONの場合だけ、アプリの画面が表示される前に以下のエラーで停止します。

Thread 1: EXC_BAD_ACCESS (code=1, address=0x0)

error: memory read failed for 0x0

停止位置は、自分が書いたSwiftコードではなく、毎回ほぼ以下の場所です。

dyld4::start

アセンブリ表示では、次のような行で停止します。

add x8, sp, #0x1f8

一方、SchemeのDebug executableをOFFにすると、同じアプリが実機上で正常に起動します。

通常どおりDebug executableをONにし、ブレークポイントやコンソール出力を使用しながらデバッグできる状態に戻したいです。

原因や、追加で確認すべき設定・ログについて、ご存じの方がいらっしゃいましたら教えていただきたいです。

開発環境

Mac：Apple Silicon
メモリ：8GB
Xcode：27.0 beta
Xcode Build version：27A5194q
iPhone：iOS 27 beta
UI：SwiftUI
依存関係：Swift Package Manager
バックエンド：Firebase
認証：Firebase Authentication、Google Sign-In
実行先：iPhone実機

Xcodeの選択状態は、以下のコマンドで確認しました。

xcodebuild -version
xcode-select -p

結果は以下です。

Xcode 27.0
Build version 27A5194q
/Applications/Xcode-beta.app/Contents/Developer

なお、以下の情報はセキュリティ上、本文や画像から削除しています。

FirebaseプロジェクトID
Bundle ID
メールアドレス
Firebase AuthenticationのUID
Google OAuthクライアントID
Macのユーザー名
/Users/ユーザー名/から始まる絶対パス
Apple Developer Team ID
APNsトークン
FCMトークン
APIキー
実際に使用しているURL

発生している問題

Debug executableがONの場合

以下の設定で実行しています。

Product
→ Scheme
→ Edit Scheme
→ Run
→ Info
→ Debug executable：ON

実際のScheme設定は以下の状態です。

実機へのインストール後、アプリの画面が表示される前に停止します。

Thread 1: EXC_BAD_ACCESS (code=1, address=0x0)

実際に停止している画面は以下です。

コールスタックには、自分のSwiftファイルや関数名がほとんど表示されません。

先頭フレームは0x00000000となっており、memory read failed for 0x0と表示されています。

主に以下のような内容が表示されます。

dyld4::start
MemoryManager
xpc_bundle_resolve
memory read failed for 0x0

Debug executableがOFFの場合

以下の設定では、実機上で正常に起動します。

Debug executable：OFF

起動後は、以下の機能も正常に動作しています。

ログイン
画面遷移
Firestoreへのアクセス
Firebase Authentication
チャット
通知
各種設定画面

そのため、アプリ自体が常にクラッシュしているのではなく、LLDBが接続されるデバッグ起動時だけ停止しているように見えます。

再現手順

Xcodeで対象プロジェクトを開く
実行先にiPhone実機を選択する
SchemeでDebug executableをONにする
Runする
アプリ画面が表示される前にdyld4::startで停止する

毎回ほぼ同じ位置で再現します。

正常に動作したケース

同じMac、同じXcode 27 beta、同じiOS 27 betaのiPhoneで、新規の空のSwiftUIアプリを作成しました。

import SwiftUI

@main
struct DebugTestApp: App {
    var body: some Scene {
        WindowGroup {
            Text("Hello, world!")
        }
    }
}

この空アプリは、Debug executable：ONのまま正常に起動しました。

そのため、Mac、iPhone、Xcode、LLDBのすべてが、どのプロジェクトでも壊れているわけではなさそうです。

別のMacユーザーで確認した結果

Macに新しいユーザーを作成し、対象プロジェクトを共有フォルダ経由で開きました。

結果は以下でした。

新規の空のSwiftUIアプリ
→ Debug executable：ONで正常起動
問題が起きる対象プロジェクト
→ Debug executable：ONでdyld4::startにてEXC_BAD_ACCESS

そのため、元のMacユーザー固有のXcode設定やキャッシュだけが原因ではないと考えています。

別のiPhoneで確認した結果

別のiPhone実機でも確認しましたが、同じ症状が発生しました。

iPhone A：同じエラー
iPhone B：同じエラー

特定のiPhoneだけの問題ではなさそうです。

アプリの起動コードを最小構成にした結果

アプリ固有の処理を除外するため、対象プロジェクトの@mainを一時的に以下の最小構成へ変更しました。

import SwiftUI

@main
struct AppEntryPoint: App {
    var body: some Scene {
        WindowGroup {
            VStack(spacing: 16) {
                Image(systemName: "checkmark.circle.fill")
                    .font(.system(size: 60))

                Text("起動テスト")
                    .font(.title2.bold())

                Text("デバッガ付きで起動できています")
            }
        }
    }
}

この状態では、以下を使用していません。

FirebaseApp.configure()
AppDelegate
AuthStore
Firestore
StateObject
通常のRootView
通知処理
Google Sign-In
アプリ内の各画面

しかし、対象プロジェクトでは、この最小構成でも同じ位置で停止しました。

dyld4::start
Thread 1: EXC_BAD_ACCESS
address=0x0

そのため、SwiftUIの画面処理やFirebaseへのアクセスが始まる前に、問題が起きている可能性を考えています。

Firebaseの初期化順序を修正

当初は以下のような構成でした。

@StateObject private var authStore = AuthStore()

init() {
    FirebaseApp.configure()
}

AuthStoreの初期化では、以下のようにFirebase Authenticationへアクセスしています。

init() {
    currentUser = Auth.auth().currentUser
    observeAuthState()
}

StateObjectの生成がinit()本体より先に行われる可能性を考え、Firebaseを初期化した後に各Storeを生成する形へ変更しました。

@StateObject private var authStore: AuthStore
@StateObject private var chatStore: ChatStore
@StateObject private var planStore: PlanStore

init() {
    if FirebaseApp.app() == nil {
        FirebaseApp.configure()
    }

    _authStore = StateObject(
        wrappedValue: AuthStore()
    )

    _chatStore = StateObject(
        wrappedValue: ChatStore()
    )

    _planStore = StateObject(
        wrappedValue: PlanStore()
    )
}

しかし、変更後も症状は変わりませんでした。

また、前述のとおり、Firebaseを使用しない最小構成の@mainでも同じ症状が発生しました。

AuthStore内のfatalErrorについて

プロジェクト内を検索したところ、Apple Sign-In用のnonce生成処理にfatalErrorが1件ありました。

nonisolated static func randomNonceString(
    length: Int = 32
) -> String {
    precondition(length > 0)

    let charset: [Character] = Array(
        "0123456789ABCDEFGHIJKLMNOPQRSTUVXYZabcdefghijklmnopqrstuvwxyz-._"
    )

    var result = ""
    var remainingLength = length

    while remainingLength > 0 {
        var randoms = [UInt8](
            repeating: 0,
            count: 16
        )

        let errorCode = SecRandomCopyBytes(
            kSecRandomDefault,
            randoms.count,
            &randoms
        )

        if errorCode != errSecSuccess {
            fatalError(
                "SecRandomCopyBytes failed with OSStatus \(errorCode)"
            )
        }

        randoms.forEach { random in
            if remainingLength == 0 {
                return
            }

            if Int(random) < charset.count {
                result.append(charset[Int(random)])
                remainingLength -= 1
            }
        }
    }

    return result
}

この処理はAppleログイン時に呼ばれる処理で、アプリ起動直後には呼ばれていません。

また、Debug executable：OFFでは正常起動するため、このfatalErrorが今回の直接原因とは考えにくいと思っています。

AppDelegateの構成

現在のAppDelegateは、通知と認証URLのコールバックを扱っています。

プロジェクト固有の名前を一般化したコードです。

import UIKit
import FirebaseAuth
import GoogleSignIn

final class AppDelegate: NSObject, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [
            UIApplication.LaunchOptionsKey: Any
        ]? = nil
    ) -> Bool {
        NotificationManager.shared.configure()
        return true
    }

    func applicationDidBecomeActive(
        _ application: UIApplication
    ) {
        Task {
            await NotificationManager.shared.resetAppBadge()
        }
    }

    func application(
        _ application: UIApplication,
        didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data
    ) {
        NotificationManager.shared.updateAPNSToken(deviceToken)
    }

    func application(
        _ application: UIApplication,
        didFailToRegisterForRemoteNotificationsWithError error: Error
    ) {
        print(
            "Failed to register remote notifications:",
            error.localizedDescription
        )
    }

    func application(
        _ application: UIApplication,
        open url: URL,
        options: [
            UIApplication.OpenURLOptionsKey: Any
        ] = [:]
    ) -> Bool {
        if Auth.auth().canHandle(url) {
            return true
        }

        if GIDSignIn.sharedInstance.handle(url) {
            return true
        }

        return false
    }
}

ただし、AppDelegateを利用しない最小構成の@mainに変更しても、症状は変わりませんでした。

使用しているSwift Package

Swift Package Managerから、主に以下を導入しています。

FirebaseCore
FirebaseAuth
FirebaseFirestore
FirebaseStorage
FirebaseFunctions
FirebaseMessaging
GoogleSignIn
GoogleSignInSwift

Build Phases → Link Binary With Librariesの状態は以下です。

Google Sign-Inを一度外して確認

Build Phases → Link Binary With Librariesから、Google Sign-In関連を一度外して確認しました。

コード内でGoogleSignInをimportしているため、以下のコンパイルエラーが発生しました。

Unable to resolve module dependency: 'GoogleSignIn'
No such module 'GoogleSignIn'

その後、GoogleSignInとGoogleSignInSwiftをSwift Package Managerから再追加しました。

依存関係のエラーは解消しましたが、dyld4::startでのクラッシュは変わりませんでした。

Swift Package Manager関連で試したこと

以下を実行しました。

File
→ Packages
→ Reset Package Caches

File
→ Packages
→ Resolve Package Versions

作業中、一時的に次のようなエラーが表示されたことがあります。

Missing package product 'FirebaseCore'
Missing package product 'FirebaseAuth'
Missing package product 'FirebaseFirestore'
Missing package product 'FirebaseStorage'
Missing package product 'FirebaseFunctions'
Missing package product 'FirebaseMessaging'
Missing package product 'GoogleSignIn'
Missing package product 'GoogleSignInSwift'

Package Dependenciesを再解決した後、このエラーは解消しました。

ただし、Package Productのエラーが消えた後も、EXC_BAD_ACCESSは変わりませんでした。

dependency graph関連のエラー

作業中、以下のエラーが発生したことがあります。

Could not compute dependency graph:
Failed to receive dependency graph response

また、以下も発生しました。

unable to initiate PIF transfer session
(operation in progress?)

Xcodeを終了し、DerivedDataとPackage Cacheを整理した後、ビルドできる状態には戻りました。

現在はビルド自体は成功しますが、デバッガ付き実行時にdyld4::startで停止します。

Firebase SDKの更新

Firebase SDKが古い場合に、Xcodeの更新後にEXC_BAD_ACCESSが起きたという記事を見つけたため、Firebase SDKを更新しました。

更新後、ビルドは成功しました。

しかし、実機デバッグ時の症状は変わりませんでした。

Build Settingsで確認したこと

Enable Debug Dylib Support

以下のコマンドで設定を確認しました。

xcodebuild \
-project プロジェクト名.xcodeproj \
-scheme スキーム名 \
-configuration Debug \
-showBuildSettings 2>/dev/null \
| grep -i "DEBUG_DYLIB"

結果は以下でした。

ENABLE_DEBUG_DYLIB = NO

XcodeのBuild Settingsから一時的に以下へ変更して確認しました。

Enable Debug Dylib Support = Yes

結果は以下です。

YESでも同じ症状
NOでも同じ症状

現在は元のNOへ戻しています。

Build ConfigurationをReleaseに変更

Schemeの以下を変更しました。

Edit Scheme
→ Run
→ Info
→ Build Configuration
→ Release

その状態でDebug executable：ONにして実行しましたが、同じ症状でした。

Debug構成＋Debugger接続：クラッシュ
Release構成＋Debugger接続：クラッシュ

SchemeのDiagnosticsで試したこと

以下をすべてOFFにして確認しました。

Address Sanitizer
Thread Sanitizer
Undefined Behavior Sanitizer
Main Thread Checker
Thread Performance Checker
Hardware Memory Tagging
Malloc Scribble
Malloc Guard Edges
Zombie Objects
Malloc Stack Logging
Metal API Validation
Shader Validation
Show Graphics Overview
Log Graphics Overview

すべてOFFでも症状は変わりませんでした。

現在は通常利用していた以下だけをONへ戻しています。

Main Thread Checker
Thread Performance Checker

Zombie Objectsなどのメモリ診断機能はOFFです。

DerivedDataの削除

以下を実施しました。

Xcodeを完全終了
DerivedDataを削除
Xcodeを再起動
Product → Clean Build Folder
実機へ再インストール

ターミナルからもDerivedDataを削除しました。

rm -rf ~/Library/Developer/Xcode/DerivedData/*

症状は変わりませんでした。

アプリの再インストール

以下も実施しました。

iPhoneから対象アプリを削除
iPhoneを再起動
Macを再起動
Xcodeを起動
Product → Clean Build Folder
実機へ再インストール

症状は変わりませんでした。

Xcodeの選択先を確認

以下のコマンドでXcode betaを選択しました。

sudo xcode-select -s /Applications/Xcode-beta.app/Contents/Developer

その後、以下を確認しました。

xcodebuild -version
xcode-select -p

結果は以下です。

Xcode 27.0
Build version 27A5194q
/Applications/Xcode-beta.app/Contents/Developer

Macには通常版XcodeとXcode betaの両方が入っていますが、現在はXcode betaが選択されています。

Attach to Processでの確認

Debug executable：OFFでアプリを起動した後、以下を試しました。

Debug
→ Attach to Process
→ 対象アプリ

アタッチすると、同じようにdyld4::start付近で停止する場合がありました。

その際も、自分のSwiftコードではなく、以下のような表示でした。

dyld4::start
EXC_BAD_ACCESS
address=0x0
memory read failed for 0x0

この結果から、アプリの起動処理そのものよりも、Debuggerを接続したタイミングに関連している可能性も考えています。

Macのメモリ確認

Macのメモリ不足や故障も疑い、以下を実行しました。

memory_pressure

結果の一部は以下です。

System-wide memory free percentage: 73%
Swapins: 0
Swapouts: 0

さらに以下も確認しました。

vm_stat

大量のSwapや、明確なメモリ不足は確認できませんでした。

また、新規の空SwiftUIアプリは同じMac上で正常にデバッグできています。

Macのストレージ容量

作業途中ではMacの空き容量が少ない状態でした。

その後ファイルを整理し、約14GB程度の空きを確保しました。

df -h /

空き容量を確保した後も、症状は変わりませんでした。

Apple Diagnosticsについて

Apple Silicon MacでApple Diagnosticsも試しました。

ただし、現在使用しているOSがbeta版であることに関連した表示が出て、診断を完了できませんでした。

一方で、別のMacユーザーでも空アプリは正常にデバッグできているため、物理メモリやMac本体の故障が直接原因である可能性は低いのではないかと考えています。

Xcodeの警告について

Xcode 27 betaでビルドすると、以下のような警告が複数表示されています。

iOS 26以降で非推奨になったMapKit API
非推奨になったNavigationLinkのinitializer
MainActor-isolated propertyに関する警告
戻り値を使用していないという警告
古いUIKit APIに関する警告

ただし、これらはコンパイルエラーではありません。

また、対象プロジェクトの@mainを最小構成にしても同じ起動前クラッシュが発生したため、これらの警告が直接原因なのか判断できていません。

staticなFirebaseプロパティについて

プロジェクト内には、以下のようなstaticプロパティがあります。

private static let db = Firestore.firestore()

private static let storage = Storage.storage()

Firebaseの初期化前に評価される可能性を考え、computed propertyへ変更する案も確認しました。

private static var db: Firestore {
    Firestore.firestore()
}

ただし、Firebaseを使用しない最小の@mainへ変更しても同じ症状が出るため、直接原因とは判断できていません。

危険そうなSwiftコードの検索

以下に該当するコードも検索しました。

unsafeBitCast
Unmanaged
withUnsafe
assumingMemoryBound
as!
try!
fatalError
preconditionFailure

検索に使用した例です。

grep -RIn \
--include="*.swift" \
-E 'unsafeBitCast|Unmanaged|withUnsafe|assumingMemoryBound|as!|try!|fatalError|preconditionFailure' \
ソースコードのフォルダ

見つかった主なものは、前述したApple Sign-Inのnonce生成時のfatalErrorでした。

起動時に実行される低レベルなポインタ処理は、現在のところ確認できていません。

Combineについて

他のAIから「Combineを入れると、どこで問題が起きているか確認できる」という案もありました。

ただ、Combineは値やイベントの非同期処理に使うフレームワークであり、今回のようなdyld4::startでの起動前クラッシュを直接解析するものではないと認識しています。

もしこの認識が間違っており、Combineを使って原因を特定する具体的な方法がある場合は、その方法も教えていただきたいです。

Gitについて

変更履歴を確認しようとしましたが、このプロジェクトではGit管理を開始していませんでした。

git status
git log --oneline --all -15

結果は以下です。

fatal: not a git repository

そのため、問題が発生する前後の差分をGitで確認することはできませんでした。

症状が始まる少し前に、nilに関連するSwiftコードを修正した記憶があります。

ただし、@mainを最小構成へ変更しても同じ症状が出るため、そのSwiftコードが直接原因なのかは判断できていません。

現時点で分かっていること

対象アプリはDebuggerなしなら正常に動く
対象アプリはDebuggerを接続すると起動前に停止する
新規の空アプリはDebugger付きでも正常に動く
別のMacユーザーでも対象アプリだけ失敗する
別のiPhoneでも対象アプリだけ失敗する
アプリの画面コードを最小構成にしても失敗する
Firebaseの初期化順を修正しても失敗する
Firebase SDKを更新しても失敗する
Google Sign-Inを再追加しても失敗する
Package Cacheを削除しても失敗する
DerivedDataを削除しても失敗する
DiagnosticsをすべてOFFにしても失敗する
Debug Dylib SupportをYESとNOの両方で試しても失敗する
Debug構成とRelease構成の両方で失敗する
Macの別ユーザーでも再現する
別の実機でも再現する
空き容量を増やしても変わらない
Macのメモリ不足を示す結果は出ていない

現在疑っている原因

現在は以下を疑っています。

Xcode 27 betaとiOS 27 betaの組み合わせ
LLDBまたはdebugserver
dyldが読み込むデバッグ用ライブラリ
特定プロジェクトに残っている古いBuild Setting
project.pbxprojの不整合または破損
Swift Package Managerのリンク情報
FirebaseまたはGoogle Sign-Inのロード時処理
Entitlements
署名された実行ファイルとdSYMの不整合
デバッグ用に挿入されるライブラリ
過去のXcodeからプロジェクトを引き継いだ影響

質問したいこと

1. Debug executableがONのときだけ落ちる原因

Debug executable：ONのときだけ、dyld4::startで以下のエラーになる場合、どのような原因が考えられるでしょうか。

EXC_BAD_ACCESS
code=1
address=0x0

2. SwiftコードよりDebugger側を疑うべきか

Debug executable：OFFでは正常起動するため、Swiftコード内の通常のnil参照よりも、以下を疑うべきでしょうか。

LLDB
debugserver
dyld
署名
デバッグ用dylib
Swift Packageのリンク
Entitlements

3. 正常な空プロジェクトとの比較方法

同じMac、Xcode、iPhoneで、新規の空プロジェクトは正常にデバッグでき、特定のプロジェクトだけ失敗します。

この場合、正常な空プロジェクトと対象プロジェクトのどこを比較するのが有効でしょうか。

Build Settings
Build Phases
Package Dependencies
project.pbxproj
Scheme
Entitlements
Linker Flags
Runpath Search Paths
Other Swift Flags
Other Linker Flags

4. Swift Packageがdyld4::startで問題を起こす可能性

FirebaseやGoogle Sign-Inなど、Swift Package Managerで導入したライブラリが、アプリのSwiftコードが実行される前のdyld4::startで問題を起こす可能性はありますか。

5. リンクされているライブラリの確認方法

実際にアプリへリンクされているライブラリや署名を確認するため、以下のようなコマンドが有効でしょうか。

otool -L アプリの実行ファイル

codesign -d --entitlements :- アプリの実行ファイル

dwarfdump --uuid アプリの実行ファイル

dwarfdump --uuid アプリのdSYM

実機向けビルド成果物に対して、どのパスを指定すればよいかも教えていただきたいです。

6. LLDBで追加確認するコマンド

LLDBコンソールで、停止原因をさらに詳しく調べるために有効なコマンドはありますか。

現在、以下を候補として考えています。

bt
thread backtrace all
image list
register read
settings show target.env-vars

7. project.pbxprojの確認方法

.xcodeproj/project.pbxprojに、古い設定や壊れた参照が残っているか確認する方法はありますか。

新しいXcodeプロジェクトを作成し、SwiftファイルやAssets、設定を少しずつ移植する方法が、最終的な切り分けとして有効でしょうか。

8. Xcode 27 betaとiOS 27 betaでの同様の事例

Xcode 27 betaとiOS 27 betaの組み合わせで、同じようにdyld4::startでEXC_BAD_ACCESSになった方はいらっしゃいますか。

補足

必要であれば、個人情報や認証情報を削除した上で、以下の情報を追加できます。

Build Settingsの該当箇所
Build Phases
Scheme設定
Package.resolved
project.pbxprojの一部
LLDBのthread backtrace all
LLDBのimage list
署名情報
Entitlements
ビルドログ
エラー発生時のスクリーンショット

長文になってしまいましたが、原因の切り分け方法だけでも教えていただけると助かります。

よろしくお願いいたします。

0 likes

Xcode 27 betaで特定のSwiftUIプロジェクトだけ、Debug executableをONにするとdyld4::startでEXC_BAD_ACCESSになる

解決したいこと

開発環境

発生している問題

Debug executableがONの場合

Debug executableがOFFの場合

再現手順

正常に動作したケース

別のMacユーザーで確認した結果

別のiPhoneで確認した結果

アプリの起動コードを最小構成にした結果

Firebaseの初期化順序を修正

AuthStore内のfatalErrorについて

AppDelegateの構成

使用しているSwift Package

Google Sign-Inを一度外して確認

Swift Package Manager関連で試したこと

dependency graph関連のエラー

Firebase SDKの更新

Build Settingsで確認したこと

Enable Debug Dylib Support

Build ConfigurationをReleaseに変更

SchemeのDiagnosticsで試したこと

DerivedDataの削除

アプリの再インストール

Xcodeの選択先を確認

Attach to Processでの確認

Macのメモリ確認

Macのストレージ容量

Apple Diagnosticsについて

Xcodeの警告について

staticなFirebaseプロパティについて

危険そうなSwiftコードの検索

Combineについて

Gitについて

現時点で分かっていること

現在疑っている原因

質問したいこと

1. Debug executableがONのときだけ落ちる原因

2. SwiftコードよりDebugger側を疑うべきか

3. 正常な空プロジェクトとの比較方法

4. Swift Packageがdyld4::startで問題を起こす可能性

5. リンクされているライブラリの確認方法

6. LLDBで追加確認するコマンド

7. project.pbxprojの確認方法

8. Xcode 27 betaとiOS 27 betaでの同様の事例

補足

No Answers yet.

Your answer might help someone💌