ci: fix pre-built binaries no longer working on macOS 15 and below

[nikwen]

Overview

Fixes #26370

Fixes the pre-built ARM64 binaries no longer working on macOS 15 and below.

Additional information

Before this PR, the ARM64 macOS job did not set CMAKE_OSX_DEPLOYMENT_TARGET. Thus, the runner's SDK default was used (26.0).

Details

$ vtool -show-build llama-cli 
llama-cli:
Load command 10
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 26.0
      sdk 26.5
   ntools 1
     tool LD
  version 1267.0

#26061 introduced these lines:

llama.cpp/vendor/sheredom/subprocess.h

Lines 1208 to 1210 in 876a432

	#if defined(__APPLE__) && MAC_OS_X_VERSION_MIN_REQUIRED >= 260000
	posix_error = posix_spawn_file_actions_addchdir(&actions, process_cwd);
	#else

This symbol does not exist before macOS 26. But MAC_OS_X_VERSION_MIN_REQUIRED was inferred as macOS 26. Thus, the builds no longer ran on macOS 15 and below.

This PR sets the ARM64 macOS deployment target to the same value that is being used for the x64 macOS deployment target.

To make sure we test this build properly, I've adjusted the CI build arguments accordingly.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: NO

[nikwen]

@taronaeo I see that you've reviewed many CI PRs. Would you be so kind as to review this PR? Thank you! :)

[taronaeo]

Can you provide a link to successful runs from your forked repository? I don't have a macOS version that low.

[taronaeo]

/bot review

[ggml-gh-bot]

Automated code review

I reviewed this CI-only change. It's small, well-scoped, and consistent with the existing pattern.

Summary

The PR sets CMAKE_OSX_DEPLOYMENT_TARGET=13.3 for the two ARM64 macOS build jobs (.github/workflows/build-apple.yml and .github/workflows/release.yml), matching the value already used by the x64 job in release.yml. I verified the underlying rationale:

• vendor/sheredom/subprocess.h (lines ~1208-1210) gates posix_spawn_file_actions_addchdir (only available macOS 26+) behind MAC_OS_X_VERSION_MIN_REQUIRED >= 260000, falling back to the deprecated _np variant otherwise.
• Without an explicit deployment target, the macos-26 runner's SDK default (26.0) is used, so MAC_OS_X_VERSION_MIN_REQUIRED resolves to 260000 and the resulting binary cannot load on macOS 15 and below (the linked issue Misc. bug: Pre-built binaries no longer work on macOS 15 (arm64) #26370).
• With the deployment target set to 13.3, MAC_OS_X_VERSION_MIN_REQUIRED becomes 130300, so the _np path is selected and the binary remains compatible with macOS 13.3+.

The fix is correct and minimal.

Findings

Blocking: none.

Will slow the review: none. The change is self-contained, single-purpose, and reuses the existing convention rather than introducing new machinery.

Nits:

(point 1) In release.yml, the disabled arm64-kleidiai matrix entry (commented out) does not set CMAKE_OSX_DEPLOYMENT_TARGET. If/when that job is re-enabled (per the TODO referencing #23780), it will silently reintroduce this same regression. Consider adding -DCMAKE_OSX_DEPLOYMENT_TARGET=13.3 to that commented block now so it's correct when uncommented. This is optional since the entry is currently inactive.

(point 2) The chosen target 13.3 is reasonable (Ventura), but it's worth confirming this matches the project's intended minimum-supported macOS version for releases, since it now governs both the test build in build-apple.yml and the published arm64 artifact. No change needed if 13.3 is the intended floor.

This review was generated automatically by pi coding agent using zai-org/GLM-5.2. It may contain mistakes. Maintainers make the final call.

[nikwen]

@taronaeo Thanks for taking a look!

I also don't have a macOS version that low, but:

1. I've done a lot of macOS development and have adjusted MACOSX_DEPLOYMENT_TARGET many times to fix similar issues (e.g., as an Electron maintainer).
2. The built executable has the proper minimum OS value with the fix:

   $ vtool -show-build llama-cli 
   llama-cli:
   Load command 10
         cmd LC_BUILD_VERSION
     cmdsize 32
    platform MACOS
       minos 13.3
         sdk 26.5
      ntools 1
        tool LD
     version 1267.0
   

3. As explained in the linked issue, the crash was caused because the symbol _posix_spawn_file_actions_addchdir was used by the executable. This symbol is now no longer used (only the backwards-compatible _np version):

   $ nm -u libllama-server-impl.dylib | grep _posix_spawn_file_actions_addchdir
   _posix_spawn_file_actions_addchdir_np
   

4. According to the linked issue, the bug started occurring between b10107 and b10141. In the commit log between these versions, I found no other commits related to the error message.
5. The built executable runs on my Mac (macOS 26.6).
6. The x64 build has used the same minimum macOS version for a long time.

Thus, I'm confident in the fix.

Can you provide a link to successful runs from your forked repository?

What exactly would you like to get a link to?

[taronaeo]

Can you provide a link to successful runs from your forked repository?

What exactly would you like to get a link to?

We usually ask for a link to a successful CI run from the author's fork to see that its actually working before we review.

But no worries, it's evident to me that the changes are OK with your explanation :)

[nikwen]

We usually ask for a link to a successful CI run from the author's fork to see that it's actually working before we review.

Ah, understood! I'll keep that in mind for the future. Thank you for your review!

[CISC]

As suggested by the bot review, add it to the disabled KleidiAI build as well.

[nikwen]

As suggested by the bot review, add it to the disabled KleidiAI build as well.

Done. Thanks for the review!

If one of you could kick off CI again, that would be awesome.