Production of Mac mini Slowed in September: Insights Behind the Delay

Oct 23, 2026 – 4 min read

Martin Remmelgas, CEO

On September 3, a modification was implemented regarding CPU allocation for the virtual machines operating on our Mac mini systems. The intention behind this adjustment was to resolve machine availability issues, leading to greater platform stability and more consistent build times. However, it inadvertently resulted in prolonged workflows, particularly evident on the Mac mini M2 machines.

This adjustment was not initially communicated, as it was anticipated that it would not adversely impact build performance. Regrettably, its effects were not identified during pre-rollout evaluations and only became apparent subsequently.

We sincerely apologize for the slower build times many users experienced post-implementation, as rapid builds are a primary reason customers choose Codemagic.

The change has now been reversed, and we are exploring more effective solutions for the underlying issues. Below, we will detail the modifications made, the unforeseen consequences, and our forthcoming actions.

Adjustments Made and Their Rationale

Previously, our Mac mini hosts operated with two virtual machines side by side, sharing CPU resources dynamically. This arrangement allowed for more efficient use of CPU power when one VM was less active. However, peak usage during intense demand periods led to significant delays, inhibiting the initiation of new builds and causing some builds to queue longer than expected.

To mitigate these issues, we imposed a cap on CPU usage per VM on September 3, which applied to both Mac mini M2 and M4 systems.

Anticipated Outcomes

We expected not only enhanced platform stability but also a more consistent build experience. While sharing CPU resources between VMs can optimize capacity utilization, it also introduces potential variability in build times. Prior to implementation, our testing indicated no notable alterations in build durations, which contributed to our confidence that this adjustment would yield more predictable outcomes without adversely affecting performance.

Actual Results

Our pre-implementation tests failed to capture the full spectrum of impact. The consequences of the CPU cap on builds requiring additional resources were underestimated. Post-implementation, approximately 75% of workflows on Mac mini M2 machines experienced slower performance, with over half of these slowing by more than 10%. Most notably, the average build time increased by around 13%, translating to an average of one additional minute per build.

However, the degree of impact varied among workflows; while about 25% of M2 workflows remained unaffected, around 10% exhibited improvements exceeding 10% in performance after the change.

The influence was contingent on the typical duration of the workflow, as illustrated in the table below:

Within the Mac mini M4 machines, which experienced lower demand on shared resources, the adverse effect was less pronounced, with typical workflows operating around 5% slower.

Steps Being Taken

As of October 23, the CPU cap has been lifted. We recognize that the adjustment made on September 3 was not effective, and we intend to exercise greater caution with future changes. Before implementing any modifications to resource allocation, we will conduct comprehensive testing, particularly focusing on CPU-intensive builds that were overlooked in prior assessments.

For users on a metered plan who may have incurred additional build time costs due to this change, we will initiate contact to extend a credit on your upcoming invoice automatically. No further action is required from your end.

Moreover, we are in the process of upgrading our Mac pools and expanding our machine availability in response to growing demand. Investments are also being made in our platform to enhance stability and speed.

Finally, we aim to refine our monitoring systems to detect any potential declines in build speeds more promptly, as the delay in recognizing this issue was unacceptable.

Conclusion

We extend our sincerest apologies for the disruptions caused by this change. Our intent was transparency regarding the challenges encountered, despite the outcome not aligning with our objectives. For any questions or concerns, we encourage you to reach out to us.