[Xcode 26] Build time regression in Azure pipeline: 15 mins → 40+ mins with xcode@5

[yuzhongqi]

Description

After upgrading from Xcode 16.1 to Xcode 26.0, the build step using xcode@5 in our Azure pipeline has experienced a significant regression.

With Xcode 16.1, the build consistently completed in about 15 minutes.

With Xcode 26.0, the same build now takes at least 40 minutes under the same pipeline configuration.

This large increase in build time indicates a potential performance regression in the Xcode 26 build environment, which directly impacts our CI/CD efficiency.

The Compilation Phase is the most time-consuming stage, which corresponds to the xcode@5 step.
Here are the specific details I summarized from the build logs.

📊 Absolute Build Time Differences: Xcode 16.1 vs 26.0

Overall Time Comparison

• Xcode 16.1 total duration: 14m 14s (854s)

• Xcode 26.0 total duration: 40m 55s (2455s)

• Total difference: +26m 41s (1601s)

---

🔍 Stage-by-Stage Breakdown

1. Package Resolution

• Xcode 16.1:

  • Start: 08:09:55

  • End: 08:12:47

  • Duration: 2m 52s (172s)

• Xcode 26.0:

  • Start: 07:59:21

  • End: 08:06:52

  • Duration: 7m 31s (451s)

• Absolute difference: +4m 39s (+279s)

---

2. Compilation Phase

• Xcode 16.1:

  • Start: 08:13:22 (≈35s after package resolution)

  • End: 08:24:07

  • Duration: 10m 45s (645s)

• Xcode 26.0:

  • Estimated start: 08:07:30 (≈38s after package resolution)

  • End: 08:40:10

  • Duration (est.): 32m 40s (1960s)

• Absolute difference: +21m 55s (+1315s)

---

3. SDK Compatibility Overhead
   Based on analysis, the new SDK introduces extra processing time due to:

• Longer module precompilation

• Extended dependency adaptation

• Estimated additional time: +10m 42s (+642s)

---

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 22.04
• Ubuntu 24.04
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• macOS 26 Arm64
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

Image version and build link

Image: macos-15
Version: 20250917.1898

Is it regression?

Yes

Expected behavior

I think the overall build process should take roughly the same amount of time as it did with Xcode 16.1, with a total duration of around 15 minutes and a pure packaging time of approximately 10 minutes.

Actual behavior

total duration of around at lest 40+mins and a pure packaging time of approximately 30 minutes.

Repro steps

On a pipeline that normally builds successfully with macOS 14 arm64 and Xcode 16.1:
1.Select macOS 15
2.Select Xcode 26
3.Download the Metal tool
4.Trigger this build pipeline

[erik-bershel]

Hey @yuzhongqi!

ℹ️ We don't consider behavioral changes from version to version to be a regression without clear evidence. Almost every new Xcode release has been accompanied by longer build times or more resource-intensive simulators, and so on, which could be considered a performance issue, but is external to us.

ℹ️ We don't accept requests to increase available hardware resources on runners—the technically permissible maximum is allocated.

---

We may note an issue if the same resource-intensive project builds in relatively similar times for the specified Xcode versions in a local environment with comparable resources, but shows performance differences on our runners.

This behavior is generally consistent with the usual changes that occur with the release of a new major version.

Since I understand how frustrating such a noticeable change in runtime can be, I propose the following:

• I'll keep this issue open for a week.
• If during this time any evidence emerges that the behavior differs from the behavior in local environments, we will investigate.
• If during this time any information emerges that it's possible to safely configure Xcode 26 to speed up build times, we will investigate.

[yuzhongqi]

@erik-bershel Thank you for your clarification and understanding! 🙏
I fully understand that with new Xcode releases, build times and resource consumption may change. This is common and may also be beyond your control. I really appreciate you keeping the issue open and being willing to follow up together! I’ll also make sure to provide feedback if I discover anything further.

[pixlwave]

We may note an issue if the same resource-intensive project builds in relatively similar times for the specified Xcode versions in a local environment with comparable resources, but shows performance differences on our runners.

Would it be considered an issue if there are performance differences across multiple runs on your runners? We upgraded our workflows to Xcode 26 and early indications are that the same workflow could take 7 mins, 40 mins or just time out after 6 hours. The code being tested in those 3 examples is unchanged.