fix: wait for current dSYM before uploading symbols

[marandaneto]

💡 Motivation and Context

Xcode can start the symbol upload phase while dsymutil is still producing the app dSYM. Uploading at that point can fail or send incomplete symbols. Declaring the dSYM as an Xcode input is not safe because it can create dependency cycles in apps with embedded extensions.

The upload script can also use MARKETING_VERSION and CURRENT_PROJECT_VERSION even when EAS remote versioning writes the shipped values directly to the source Info.plist.

This moves the native part of PostHog/posthog-js#4602 into the shared iOS upload script. It addresses PostHog/posthog-js#4574 for native iOS and React Native integrations.

The script now waits until the app executable and main dSYM have matching UUIDs and no process has the dSYM open for writing. It fails after 60 seconds by default so a release cannot succeed without its native symbols. POSTHOG_DSYM_TIMEOUT can change that timeout.

It also resolves literal, custom, and compound Xcode build settings from the source Info.plist. Existing Xcode version settings remain the fallback for missing, unresolved, or C-preprocessed plist values.

💚 How did you test it?

• Added shell tests for delayed and actively written dSYMs, timeout failure, CLI preflight ordering, Info.plist versions, custom and compound build settings, preprocessing fallback, and missing values.
• Built the PostHogExampleWithSPM sample for a Release iOS device with XcodeBuildMCP and posthog-cli 0.14.1. The real CLI uploaded the generated dSYM successfully.
• Rebuilt the sample with source plist values $(APP_VERSION) and ${BUILD_NUMBER} while MARKETING_VERSION and CURRENT_PROJECT_VERSION remained 1.0 and 1. The app, dSYM, and uploaded release all used 2.10.0+154.
• Ran make test. All 763 SDK tests passed.
• Ran ShellCheck and Bash syntax validation for the upload scripts.

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

If releasing new changes

• Ran pnpm changeset to generate a changeset file

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Pi implemented and tested the change. The dSYM input-path approach was rejected because it can create Xcode dependency cycles. The upload script uses UUID, writer, and timeout checks instead. Shared Info.plist handling in posthog-cli is tracked in PostHog/posthog#87775.

[greptile-apps]

Prompt To Fix All With AI

### Issue 1
build-tools/upload-symbols.sh:153-157
**Unexpanded Info.plist path variables**

If a target defines `INFOPLIST_FILE` with an Xcode build-setting expression such as `$(TARGET_NAME)/Info.plist`, this code checks a path containing the literal expression and silently falls back to `MARKETING_VERSION` and `CURRENT_PROJECT_VERSION`, causing symbols to be uploaded under stale release and build identifiers.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix: wait for current dSYM before upload..." | Re-trigger Greptile}

[marandaneto]

Tested this with two real Release iOS device builds of PostHogExampleWithSPM using posthog-cli 0.14.1.

1. Built the unmodified sample using its generated Info.plist. Xcode exported DEBUG_INFORMATION_FORMAT=dwarf-with-dsym, the readiness checks passed, and the CLI uploaded the dSYM successfully as 1.0+1.
2. Rebuilt with source Info.plist values $(APP_VERSION) and ${BUILD_NUMBER}, custom settings 2.10.0 and 154, and unchanged Xcode defaults 1.0 and 1. The built app, dSYM, CLI release attribution, and uploaded release all used 2.10.0+154.

Both builds and real symbol uploads completed successfully. The temporary sample changes were removed afterward.