Running mobile tests in parallel means splitting a test suite across multiple emulator, simulator, or device instances that execute simultaneously rather than one after another, which is the single biggest lever for reducing CI wall-clock time on any suite of meaningful size. On Android, managed device configurations or a custom test orchestrator can shard tests across several emulator instances, and Espresso's test runner supports sharding flags that split a suite into numbered buckets run on separate workers. On iOS, xcodebuild's parallel testing option combined with multiple simulator destinations lets Xcode distribute test classes across parallel simulator instances on the same host, and CI systems can further split test targets across separate build jobs entirely. The main constraint on parallelism is infrastructure capacity, since each parallel emulator or simulator instance needs its own CPU and memory allocation, so scaling parallel test count really means scaling compute capacity, whether that is more CI runners, more Kubernetes nodes, or more Mac hardware for iOS. Balancing shard sizes matters too, since one slow test class in an otherwise fast shard can become the bottleneck that determines total run time. Nanobase AI's Mobile Test Lab runs parallel Android and iOS test execution across local emulator and simulator infrastructure to keep CI/CD pipelines fast.
Why naive sharding doesn't deliver the expected speedup
Splitting a suite into equal-sized shards by test count seems like the obvious approach, but it consistently fails to deliver proportional speedup because test duration varies widely: a handful of slow, complex flows can dominate one shard's runtime while other shards with more but faster tests finish early and sit idle. Total wall-clock time is set by the slowest shard, not the average shard, which makes shard balancing the actual lever that matters.
Sharding strategies compared
| Strategy | How it works | Trade-off |
|---|---|---|
| Static count-based sharding | Splits tests into N equal-count buckets | Simple, but ignores duration variance; slow tests bottleneck one shard |
| Duration-based sharding | Splits based on historical execution time per test | Better balanced shards, requires tracking historical timing data |
| ML-predicted sharding | Predicts new test duration from code similarity to known tests | Handles new tests without historical data, more complex to implement |
| Dynamic/work-stealing sharding | Workers pull the next available test from a shared queue as they finish | Best balance in practice, requires an orchestrator supporting this pattern |
Static count-based sharding is the easiest to set up and the first thing worth replacing once suite runtime becomes a bottleneck.
Platform-specific mechanics
On Android, Espresso's test orchestrator and sharding flags split a suite into numbered buckets that can run on separate emulator instances or CI workers; managed device configurations in newer Android Gradle plugin versions also support automatic sharding across multiple virtual devices. On iOS, xcodebuild's -parallel-testing-enabled YES combined with -maximum-concurrent-test-simulator-destinations distributes test classes across multiple simulator instances on a single host, and CI systems can additionally split test targets across separate build jobs entirely for a second layer of parallelism beyond what one Mac host can provide. Combine in-host parallelism with cross-job parallelism; the two stack rather than substitute for each other.
The real constraint is compute, not test framework support
Both Espresso and xcodebuild support parallelism well; the actual limit on how much you can parallelize is CPU and memory capacity, since each parallel emulator or simulator instance needs its own resource allocation. Scaling parallel test count in practice means scaling compute capacity: more CI runners, more Kubernetes nodes for containerized Android emulators, or more Mac hardware for iOS, which turns a test-sharding question into an infrastructure budgeting question past a certain suite size. Beyond a certain suite size, the sharding algorithm stops being the bottleneck and compute budget takes over.
Frequently asked questions
How do we get historical test duration data for duration-based sharding?
Most CI systems and test frameworks can export per-test execution time from prior runs; aggregate this over several recent runs (not just one, which can be noisy) to build a duration profile used for shard balancing going forward.
Does adding more shards always reduce total CI time?
Only up to the point where compute becomes the bottleneck; beyond that, adding shards without adding proportional CPU and memory capacity causes resource contention that can make individual shards slower, offsetting the parallelism gain.
Can Android and iOS test shards run in the same CI stage?
They typically run as separate parallel jobs since they need different runners, Linux or cloud instances for Android emulators, Mac hardware for iOS simulators, but both can report into the same overall pipeline stage and gate the same merge decision.
How often should shard balancing be recalculated?
Periodically, such as monthly or when the suite changes significantly, since test durations shift as code and test coverage evolve, and shard assignments based on stale timing data drift out of balance over time.
How Nanobase AI helps
Nanobase AI's Mobile Test Lab runs parallel Android and iOS test execution across local emulator and simulator infrastructure, with duration-aware shard balancing to keep CI/CD pipelines fast rather than bottlenecked by one uneven shard. For the underlying infrastructure that scales this parallelism, see our Android emulators on Kubernetes guide or explore our solutions.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.