perf(platform-ios): adapt startup to host capabilities - #174
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
V3RON
marked this pull request as ready for review
July 30, 2026 17:14
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this?
Harness now chooses how to prepare the iOS XCTest permission agent according to host memory and CPU capacity. Constrained machines build the agent before starting simulator preparation, while capable machines overlap the two operations. This replaces the unconditional overlap proposed in #171 and adds a reusable host-capabilities helper for future resource-aware behavior.
The PR also makes the Metro block list consume the canonical cache root produced by
createHarnessCacheinstead of duplicating the cache directory layout.How does it work?
getHostCapabilities()reports total memory and available CPU parallelism from Node. An internal, argument-free startup policy enables overlap only when the host has strictly more than 8 GiB of memory and more than 6 available CPUs. The selected sequential or parallel strategy is logged at debug level.Sequential startup awaits the XCTest build before checking, booting, and preparing the simulator. Parallel startup begins the build immediately, prepares the simulator concurrently, then waits for both before starting the agent. Both parallel branches are settled before cleanup so build and simulator failures propagate without leaving the controller, simulator override, or Harness-started simulator behind.
Metro receives
harnessCache.paths.rootwhen constructing its block list and derives a cross-platform, exact-root exclusion from that value. Cache-path construction therefore remains owned by@react-native-harness/cache, and the cache boundary check stays strict without an allowlist.Why is this useful?
Resource-constrained macOS runners avoid making
xcodebuildand the simulator compete for limited RAM and CPU, preserving a build-first startup path when contention would likely make startup slower. More powerful hosts retain the cold-start speedup from overlapping independent work. Reusing the canonical cache root also prevents Metro and the cache package from drifting onto different directory layouts.