Enable building for metal with macOS SDK < 15

[mattjcly]

Summary

Fixes compilation errors on macOS w/ SDK < 15 due to non-existent properties:

executorch/backends/apple/metal/runtime/shims/et_metal.mm:239:21: error: property 'mathMode' not found on object of type 'MTLCompileOptions *'
            options.mathMode = MTLMathModeSafe;
                    ^
executorch/backends/apple/metal/runtime/shims/et_metal.mm:239:32: error: use of undeclared identifier 'MTLMathModeSafe'
            options.mathMode = MTLMathModeSafe;
                               ^
executorch/backends/apple/metal/runtime/shims/et_metal.mm:240:21: error: property 'mathFloatingPointFunctions' not found on object of type 'MTLCompileOptions *'
            options.mathFloatingPointFunctions = MTLMathFloatingPointFunctionsPrecise;
                    ^
executorch/backends/apple/metal/runtime/shims/et_metal.mm:240:50: error: use of undeclared identifier 'MTLMathFloatingPointFunctionsPrecise'
            options.mathFloatingPointFunctions = MTLMathFloatingPointFunctionsPrecise;

Keep runtime check

Test plan

Confirmed working build on machine with:

-> % xcodebuild -version
Xcode 15.2
Build version 15C500b
-> % xcrun --sdk macosx --show-sdk-version
14.2

That did not work before.

Also confirmed to still work on 26.1:

-> % xcodebuild -version
Xcode 26.1.1
Build version 17B100
-> % xcrun --sdk macosx --show-sdk-version
26.1

Including verification that inside of if/else def was triggered with a #warning (since removed) to see:

executorch/backends/apple/metal/runtime/shims/et_metal.mm:249:2: warning: "Compiling with MTLMathModeSafe and MTLMathFloatingPointFunctionsPrecise for improved precision (requires macOS 15/iOS 18 or later)" [-W#warnings]
  249 | #warning "Compiling with MTLMathModeSafe and MTLMathFloatingPointFunctionsPrecise for improved precision (requires macOS 15/iOS 18 or later)"
      |  ^
1 warning generated.

Confirmed Parakeet inference to still work on both machines.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/17435

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

⚠️ 9 Awaiting Approval

As of commit c932509 with merge base dcfd12d ():

AWAITING APPROVAL - The following workflows need approval before CI can run:

• Apple (gh)
• Build documentation (gh)
• Build Presets (gh)
• Lint (gh)
• periodic (gh)
• pull (gh)
• Test CUDA Builds (gh)
• Test CUDA Windows Export (gh)
• Test Metal Backend (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[mattjcly]

Only failing test that seems potentially relevant is pull / unittest-editable / macos / macos-job ... will try to understand exactly what this is testing and if this is a true failure/breakage or not

[mergennachin]

@mattjcly Let me rerun the failing test again. It might some tolerance issue

[malfet]

One more example where we could have shared code better between PT and ET, as we've solved this problem a while back :)

[malfet]

IMO it'll be better to do it other way around:
define new enums if you compiling with the older SDK, and then indeed rely on @available...
See https://github.com/pytorch/pytorch/blob/4504c3dcee3c02886fae3340a8ee268717c6cb32/aten/src/ATen/native/mps/MPSGraphSequoiaOps.h as an example of accomplishing that

[malfet]

IMO this is wrong, because it will require one to have two binaries, one for older and another one for newer SDK

[mattjcly]

IMO it'll be better to do it other way around: define new enums if you compiling with the older SDK, and then indeed rely on @available... See https://github.com/pytorch/pytorch/blob/4504c3dcee3c02886fae3340a8ee268717c6cb32/aten/src/ATen/native/mps/MPSGraphSequoiaOps.h as an example of accomplishing that

Very smart! Thanks for taking a look. Just made the change and re-confirmed can still build and run parakeet metal on both SDK 14.2 and 26.1