[build-tools] add parseXcactivitylogFunction

[hSATAC]

Why

iOS builds currently have no visibility into per-module compile timing. Developers can't easily identify which targets are slow. Xcode generates .xcactivitylog files with detailed build timing data, but since Xcode 11 the CLI (xcodebuild) only produces them when -resultBundlePath is provided — which our Fastlane templates didn't include.

Linear: ENG-20491

How

• Add result_bundle(true) and result_bundle_path to both Gymfile templates (archive + simulator) to trigger xcactivitylog generation. Also add derived_data_path to the archive template so the xcactivitylog lands in a known location (ios/build).
• Add parseAndReportXcactivitylog() utility that downloads a pre-built XCLogParser binary, parses the xcactivitylog into JSON, and logs a per-module compile metrics table. Never fails the build — all errors are caught and logged as warnings.
• Register eas/parse_xcactivitylog as a built-in step function (opt-in for custom workflows).
• Also call parseAndReportXcactivitylog() in the traditional iOS builder flow under a new PARSE_XCACTIVITYLOG build phase, gated behind EXPERIMENTAL_EAS_XCACTIVITYLOG=1 env var.
• Add PARSE_XCACTIVITYLOG to the BuildPhase enum in @expo/eas-build-job (requires publishing a new version and updating the dependency in universe for the display name to render correctly on the website).

Test Plan

• Automation tests
• Tested locally
• To enable in traditional builds, set EXPERIMENTAL_EAS_XCACTIVITYLOG=1 in build profile env

[linear]

ENG-20491 Integrate xcactivitylog parsing into iOS build steps

[codecov]

Codecov Report

❌ Patch coverage is 91.86047% with 14 lines in your changes missing coverage. Please review.
✅ Project coverage is 55.04%. Comparing base (3a70a5d) to head (8cbd305).

Files with missing lines	Patch %	Lines
...s/build-tools/src/steps/utils/ios/xcactivitylog.ts	94.34%	9 Missing ⚠️
...ld-tools/src/steps/functions/parseXcactivitylog.ts	50.00%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3578      +/-   ##
==========================================
+ Coverage   54.86%   55.04%   +0.18%     
==========================================
  Files         836      838       +2     
  Lines       35901    36073     +172     
  Branches     7492     7518      +26     
==========================================
+ Hits        19694    19852     +158     
- Misses      16112    16126      +14     
  Partials       95       95              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

Subscribed to pull request

File Patterns	Mentions
**/*	@douglowder

Generated by CodeMention

[sjchmiela]

Love it!!

[sjchmiela]

Do we want to report stuff to Datadog too?

[hSATAC]

I think this is out of scope for this PR. For now I want to focus on getting the architecture in place and validating the end-to-end flow. Metrics / telemetry integration seems useful, but I’d rather handle that in a follow-up once we’ve aligned on the shape and destination of the data.

[sjchmiela]

Would it make sense to write a Zod schema and parse the output here? Then we don't rely on "interface"s we "expect" but have the actual parsed objects. I think theoretically you could also filter out steps you're not interested in (like in an array they may fail validation and get removed? not sure)

[hSATAC]

Let me rethink this part a bit. After taking another look, I realized the current approach (reading stdout into memory and doing a JSON.parse) could be problematic.

The JSON can get quite large (hundreds of MB), which would put significant pressure on memory.

I’m thinking I may need to switch to writing it to disk and then reading it in a buffered/streaming way instead.

I’m not sure if Zod would still fit well under these constraints — I’ll need to look into it — but I think performance should probably be the primary concern here.

[sjchmiela]

Hmm interesting. Maybe there's a way to tell xclogparser to be smaller about the output? Also, I think computers are good at computering so maybe hundreds of MBs isn't a problem?

[hSATAC]

I tried locally with flatJson reporter it only reduces from 250MB -> 248 MB, it's not helping.

[sjchmiela]

I presume putting derivedDataPath in the same directory as outputDirectory is not going to be a problem?

[hSATAC]

I tested both simulator and archive builds with this setup and did not run into any issues, so I’m planning to keep it as-is for now.

[github-actions]

⏩ The changelog entry check has been skipped since the "no changelog" label is present.