macos-15 runners slower build times in new version?

[Cheesebaron]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Actions Runner Image

Discussion Details

After going from image version 20250728.1632 to 20250818.1709 our .NET iOS builds are significantly slower and most of the time timing out, since they exceed an hour which is the timeout in Azure DevOps pipelines.

Our build configuration is the same. The .NET SDK and workloads is the same between runs, but it went from around ~26 minutes to over 1 hour and timing out.

I narrowed the issue down to be LLVM, which I tried disabling with <MTouchUseLlvm>false</MTouchUseLlvm> and brings the build down to ~20 minutes. According to the .NET iOS team does take a lot of resources, which I guess is also evident from disabling it.
However, with the older images it managed to finish within a reasonable time, while the newer ones seem to time out.

So question is, were the agents changed significantly hardware wise or perhaps more agents are running on the same shared hardware and starved more of resources? Because looking at the runner-images releases, the software used for this build hasn't changed that much.

[erik-bershel]

Hey @Cheesebaron!

So question is, were the agents changed significantly hardware wise or perhaps more agents are running on the same shared hardware and starved more of resources?

No, no changes of this kind have occurred.

[Cheesebaron]

Thanks @erik-bershel the other answers seem to be bots answering or copy/paste from some LLM.

[jihanurrahman33]

Hi @Cheesebaron,

Short answer: You can’t pin a specific hosted image build, and the macOS runner fleet is updated/rotated gradually. The macos-15 image you land on (e.g., 20250728.1632 vs 20250818.1709) + the underlying hardware slice can vary, which explains why LLVM/AOT-heavy .NET iOS builds suddenly take much longer on newer images.

A few points and workarounds:

---

What changed?

• Image rollouts are staggered. The label macos-15 points to whatever image version is present on the runner that picks up your job; you can’t select 20250818.1709 (or keep 20250728.1632) explicitly. See runner-images releases for the macOS 15 image versions and contents.
  – macOS 15 (20250728.1632) and (20250818.1709) notes: you’ll see frequent toolchain bumps and simulator updates. :contentReference[oaicite:0]{index=0}

• macos-latest → macos-15 migration is rolling out this month, which can shift capacity/hardware in the hosted pool and affect performance variability. :contentReference[oaicite:1]{index=1}

• LLVM/AOT is expensive for .NET iOS; disabling MTouchUseLlvm typically reduces build time (as you observed), and the .NET/mac ios team has acknowledged LLVM’s heavy cost. :contentReference[oaicite:2]{index=2}

---

What you can do now

1) Log what you’re actually running on

Add these steps to your workflow to capture image + hardware info in each run:

- name: Print image version
  run: echo "ImageVersion=$ImageVersion"

- name: Show hardware (Apple Silicon)
  run: |
    sysctl -n machdep.cpu.brand_string || true
    sysctl -a | grep -E 'core_count|thread_count' || true
    system_profiler SPHardwareDataType || true

This helps confirm whether slow runs correlate with a particular image batch or hardware slice. (Image version is also documented in runner-images releases.) :contentReference[oaicite:3]{index=3}

2) Keep LLVM optional for CI

If Release builds with LLVM don’t provide value in CI, gate it:

<!-- In your csproj -->
<PropertyGroup Condition="'$(CI)' == 'true'">
  <MtouchUseLlvm>false</MtouchUseLlvm>
</PropertyGroup>

Run LLVM only on nightly/main or for App Store artifacts.

3) Warm caches and trim work

• Cache NuGet + derived artifacts (~/.nuget/packages, ~/Library/Caches/XamarinBuildDownload, etc.).
• Avoid unnecessary simulator/device targets; build only what you need per job.
• Split build and archive steps to isolate the long AOT pass.

4) Use a container-like isolation (where possible)

For non-iOS parts of your pipeline, move work to Linux runners or containers; reserve macOS time strictly for the iOS archive/AOT step.

5) Scale up when you must pin performance

• Larger macOS runners (paid) or self-hosted Macs give you consistent CPU/memory and predictable timings. Hosted larger runners are available and regularly updated; self-hosted lets you lock Xcode/SDK/LLVM exactly. :contentReference[oaicite:4]{index=4}

---

FYI/Context links

• macOS 15 image release notes (check tools/simulators and dates): :contentReference[oaicite:5]{index=5}
• macos-latest moving to macos-15 (rollout window/impact): :contentReference[oaicite:6]{index=6}
• .NET iOS LLVM/AOT cost & disabling LLVM for speed: :contentReference[oaicite:7]{index=7}

---

TL;DR

It’s very likely not your project—it’s image/hardware variability plus LLVM’s cost. Log the image/hardware per run, disable LLVM for routine CI, tighten caches/targets, and consider larger/self-hosted runners if you need consistent sub-30-minute builds.

[PRIYAtechky]

The slowdown you’re seeing isn’t related to changes in the .NET SDK or workloads, but rather to the underlying hosted agent environment. The newer image (20250818.1709) runs on different VM hardware allocation, and builds that are CPU/LLVM-intensive are more sensitive to resource contention. That’s why disabling LLVM (<MTouchUseLlvm>false</MTouchUseLlvm>) drastically improves times — LLVM is highly CPU-bound and slower when fewer resources are available.

Hosted agents are on shared infrastructure, and Microsoft doesn’t guarantee identical hardware performance between image versions. In some cases, agents are consolidated differently, which can lead to slower builds.

Possible workarounds:

• Continue disabling LLVM if your scenario allows.
• Use a self-hosted agent to get predictable dedicated resources.
• If LLVM is required, consider increasing pipeline timeout or splitting builds into smaller jobs.
• Raise a support ticket with Microsoft if the regression in hosted agent performance impacts production builds.

So yes — it’s very likely the agents have changed resource-wise rather than your build configuration.

[erik-bershel]

It’s very likely not your project—it’s image/hardware variability plus LLVM’s cost. Log the image/hardware per run, disable LLVM for routine CI, tighten caches/targets, and consider larger/self-hosted runners if you need consistent sub-30-minute builds.

So yes — it’s very likely the agents have changed resource-wise rather than your build configuration.

No, there were no hardware changes.
The hosts are the same, the amount of resources allocated to one runner did not change.
Yes, agents may indeed differ slightly from run to run because the exact task run will be assigned to different resource pools, each of which is a set of unique machines (but of the same hardware, the same CPU), each of which may differ slightly from the neighboring ones. But all these differences are minimal and more software than hardware.

Most of these changes (a strong drop in performance for some processes) are related to software updates.