Fix the macOS nightly build

[dunglas]

What does this PR do?

The macOS nightly binaries on dl.static-php.dev/v3/spc-bin/nightly/ haven't been updated since spc-macos-aarch64 on 2026-09-22 and spc-macos-x86_64 on 2026-08-22. Every Build SPC Binary run on v3 since 2026-09-08 fails at the same step: shivammathur/setup-php runs for about 28 minutes on the macOS runner and then fails with Could not setup PHP 8.4. Because the matrix uses fail-fast, the other macOS job gets cancelled too. For example, https://github.com/crazywhalecc/static-php-cli/actions/runs/37640611019 failed macos-x86_64 and cancelled macos-aarch64.

Homebrew moved Intel Macs and macOS 14 to Tier 3 and no longer builds bottles for them (https://docs.brew.sh/Support-Tiers), so setup-php ends up compiling PHP's dependencies from source on those runners (shivammathur/setup-php#1125).

As a result, macOS users of the nightly don't get fixes such as #1241. This breaks FrankenPHP's macOS static build: php/frankenphp#2618.

This PR:

• builds both macOS binaries on macos-latest, which setup-php supports. The build only packs spc.phar into the micro.sfx downloaded for the target arch, so the host arch doesn't matter (linux-aarch64 and windows-x64 are already built on ubuntu-latest)
• keeps testing the x86_64 binary natively on macos-15-intel, which doesn't need setup-php
• sets fail-fast: false, so one failing platform no longer blocks uploads for the others

Checklist before merging

• If you modified *.php or *.yml, run them locally to ensure your changes are valid:
  • composer cs-fix (no PHP changes)
  • composer analyse (no PHP changes)
  • composer test (no PHP changes)
  • bin/spc dev:lint-config (no package config changes)

[henderkes]

Oh if homebrew dropped x86 maybe it's time we do the same too.

In this configuration, doesn't this run twice on aarch64 now though while still tagging a x86 binary (name)?

[crazywhalecc]

Given that the current GHA runners include rosetta2, this is entirely feasible. I guess in the future we could also fix such issues by using own static PHP, rather than relying on setup-php.

[dunglas]

To be exact, Homebrew didn't entirely remove Intel support, it moved it to "Tier 3": no new bottles but still buildable from source (https://docs.brew.sh/Support-Tiers).

The last commit drops the prebuilt x86_64 binary. Intel users can still run the platform-independent spc.phar from the nightly with their own PHP 8.4+.

[dunglas]

@crazywhalecc do you want me to add back intel support?

[henderkes]

Given that the current GHA runners include rosetta2, this is entirely feasible. I guess in the future we could also fix such issues by using own static PHP, rather than relying on setup-php.

I'm already using that for packages, because it's putting less strain on github and is just faster.

Anyway I'm sitting this one out - I still don't have a mac and it seems unlikely to change with the current moon prices.

[crazywhalecc]

@crazywhalecc do you want me to add back intel support?

Support for Intel macOS at the StaticPHP level currently falls into the "Tier 2" category already (akin to Linux aarch64, even though we haven't explicitly stated this).

And support for both the runner and Homebrew is tenuous as for now. But simply dropping Intel support immediately isn't a gradual approach. Perhaps we should first phase it out of testing and build processes before eventually dropping SPC binary builds. However, if we choose to keep it, we should also halt the process early if a critical library used by Homebrew, Runner, or SPC causes a build failure on Intel.

Alternatively, if we are determined to drop support, that decision should be clearly documented in the README and other relevant docs.

[crazywhalecc]

For me, just follow GHA. I haven't had much time lately to handle build-related matters, especially those involving Intel and I no longer have an Intel Mac, so CI passes, I consider it acceptable; CI failed and not simply fixable, drop it.

[dunglas]

CI passes with Intel, so I restored it by dropping the last commit.

@henderkes about your question: both macOS binaries are built on macos-latest, but the build only packs the platform-independent spc.phar into the micro.sfx downloaded for the target arch (php-8.4.11-micro-macos-x86_64.tar.gz). That's how linux-aarch64 and windows-x64 are already built on ubuntu-latest, so the x86_64 binary really is x86_64. The test job still runs it natively on macos-15-intel, which doesn't need setup-php: https://github.com/crazywhalecc/static-php-cli/actions/runs/38065071827 (the log shows current platform: macos-x86_64).

When GitHub retires its Intel runners, we can switch the test to Rosetta 2 on an arm64 runner or drop it.