[Bug] upload-symbols 3.20 crashes with XPC "API Misuse" SIGTRAP on macOS 26.3.1 when invoked from Xcode build phase

[dan12411]

Description

upload-symbols (v3.20 build 39) bundled with FirebaseCrashlytics crashes with Trace/BPT trap: 5 (SIGTRAP / _xpc_api_misuse) when executed from an Xcode build phase (via xcodebuild subprocess) on macOS 26.3.1 / Xcode 26.2.

The same binary runs successfully when invoked manually from a login shell (including --version, --help, and a real upload with valid -gsp + dSYM). The same CI setup works on a second runner still on macOS 26.3 (build 25D125). After that runner is upgraded to 26.3.1, the crash reproduces there too.

Crash report asiSignatures: ["API Misuse"]. The failure path is inside libxpc triggered by xpc_connection_set_target_uid, which appears to be rejected in the Xcode build-phase subprocess environment because that context lacks a full audit session / login context.

This looks related to but distinct from #15896:

• [Bug] upload-symbols 3.20 crashes with "Path to CoreSymbolication is invalid" + SEGFAULT on CI (macOS 15.7.1 / Xcode 26.2) #15896 reports a clear Path to CoreSymbolication is invalid, aborting error and is fixed by reading DEVELOPER_DIR (PR Update upload-symbols with better logging and reading DEVELOPER_DIR to get Xcode path for CoreSymbolication #16007, pending release).
• This issue produces no error message — the process __builtin_traps inside xpc_connection_set_target_uid before any debug logging (-d) can run. DEVELOPER_DIR is already pointing at a valid Xcode installation on the failing machine (confirmed via xcode-select -p).

Reproducing the issue

1. Set up a CI runner on macOS 26.3.1 + Xcode 26.2.
2. In an iOS Flutter app integrating firebase_crashlytics, run the Xcode archive step from a CI environment (e.g. flutter build ipa or xcodebuild archive driven by a CI runner process).
3. Xcode invokes the [firebase_crashlytics] Crashlytics Upload Symbols Run Script build phase, which executes:

   "$PODS_ROOT/FirebaseCrashlytics/upload-symbols" --flutter-project "$PROJECT_DIR/firebase_app_id_file.json"
   

4. The script fails with:

   line N: PID Trace/BPT trap: 5       "$PODS_ROOT/FirebaseCrashlytics/upload-symbols" ...
   Command PhaseScriptExecution failed with a nonzero exit code
   

Manually running the same binary from a login shell on the same machine with the same arguments (real Google service plist, real dSYM folder) succeeds and uploads dSYMs to Crashlytics as expected.

Moving upload-symbols out of the Xcode build phase and invoking upload_symbols_to_crashlytics (Fastlane) / direct upload-symbols call from a regular shell context (CI script step) bypasses the crash completely and uploads the dSYMs successfully.

Firebase SDK Version

12.4.0 (also reproduces with 12.9.0, which includes the "Conformed to Mach IPC security restrictions" fix)

Xcode Version

26.2 (build 17C52)

Installation Method

CocoaPods

Firebase Product(s)

• Crashlytics

Targeted Platforms

• iOS

Relevant Log Output

Script-XXXXXXXXXXXXXXXXXXXX.sh: line N: PID Trace/BPT trap: 5       "${PODS_ROOT}/FirebaseCrashlytics/upload-symbols" --flutter-project "$PROJECT_DIR/firebase_app_id_file.json"
Command PhaseScriptExecution failed with a nonzero exit code

Crash report (excerpt):

asiSignatures: ["API Misuse"]

Thread 1 Crashed:
...
_xpc_api_misuse
xpc_connection_set_target_uid
-[SOServiceConnection _connectToService]
-[SOConfigurationClient defaultClient]
+[SOAuthorizationCore _canPerformAuthorizationWithURL:...]
AppSSO::shouldManageURL(...)
AppSSOProtocol::_canHandleTask(...)
-[__NSURLSessionLocal _protocolClassForTask:]
-[NSURLSessionTask resume]

Additional notes

On the failing machine, the binary's extended attributes include com.apple.provenance (from the pod fetch). Removing this attribute before execution does not change the behavior.

Environment comparison:

	Failing runner	Working runner
macOS	26.3.1 (25D2128)	26.3 (25D125)
Xcode	26.2 (17C52)	26.2 (17C52)
xcode-select -p	/Applications/Xcode-26.2.0.app/Contents/Developer	same
upload-symbols	3.20 build 39	3.20 build 39

Happy to provide additional crash reports or testing on the failing environment if that helps.

[dan12411]

Follow-up: same crash on Apple's own altool confirms this is a system-wide daemon context issue

Since filing this issue, we investigated further and confirmed that upload-symbols is not the only tool affected on macOS 26.3.1 under LaunchDaemon context. Apple's own altool (altoolShim, bundled in Xcode 26.2 via ContentDelivery.framework) crashes with the same signature when invoked from fastlane's upload_to_testflight under a CI LaunchDaemon:

• asiSignatures: ["API Misuse"]
• SIGTRAP at _xpc_api_misuse → xpc_connection_set_target_uid → SOServiceConnection._connectToService → AppSSOProtocol.canPerformAuthorization → CFNetwork.shouldManageURL → NSURLSessionTask.resume
• Launch → crash: ~47 ms (dies before any network activity)
• Parent: ruby (fastlane), responsible: gitlab-runner (LaunchDaemon, PID under system/ domain)

This means the root cause is not Firebase-specific. Apple's macOS 26.3.1 integrates AppSSO into CFNetwork such that any NSURLSession call triggers an AppSSO XPC lookup via xpc_connection_set_target_uid, which is disallowed in the LaunchDaemon (system) launchd domain because it lacks a full GUI/Aqua session. Any Apple tool doing a network request from that context will SIGTRAP.

Workaround that works end-to-end

Moving upload-symbols out of the Xcode Run Script build phase and invoking upload_symbols_to_crashlytics (Fastlane) from the regular shell context of the CI runner (process ancestor: fastlane/ruby, not xcodebuild subprocess) completely bypasses the crash. The binary itself is fine — the issue is purely about the launch context. Verified on the failing runner: Fastlane-invoked upload succeeds with Successfully uploaded dSYM files to Crashlytics 💯.

For setups where moving the invocation out of Xcode build phase isn't acceptable, the only known full fix is to run the CI worker as a LaunchAgent under a logged-in user session (vs. LaunchDaemon in system domain). This matches what major macOS CI services do (GitHub Actions macOS runners, MacStadium, AWS EC2 Mac, Bitrise, etc.).