Investigate arm64e and arm64e.x1 support #27075

Apple platform

iOS, macOS, Mac Catalyst, tvOS

Framework version

net11.0-*; future versions as appropriate.

Affected platform version

Investigation across supported Apple deployment targets. The initial research used Xcode 26.3 with iOS/macOS SDK 26.2; newer features need their own toolchain, OS, hardware, and distribution requirements verified.

Description

Follow-up to #23025: investigate the feasibility and design of supporting Apple's arm64e pointer-authentication ABI and the newer arm64e.x1 slice. This is an investigation, not a commitment to enable either by default.

Scope:

• Establish the supported hardware, OS, toolchain, signing, and distribution matrix for each slice on our platforms. Distinguish hardware capability from supported deployment, and physical-device execution from simulator testing.
• Determine what native-only compilation and execution tests we can run in macios before full managed-runtime support. Native C/Objective-C harnesses can exercise selected code without first running CoreCLR, but compiling successfully is not evidence that managed execution works.
• Coordinate with dotnet/runtime on CoreCLR and NativeAOT support: generated code, native runtime binaries, interop function pointers/callbacks, assembly stubs, exception handling, stack walking/unwinding, debugging, and diagnostics. Existing PAC primitives and Mono arm64e code do not establish end-to-end support for our current runtime configurations.
• Audit macios runtime glue, assembly trampolines, generated registrar code, native entry points, and dependency selection for ABI assumptions.
• Investigate universal arm64 + arm64e builds and optional arm64e.x1 slices, including compatible slices for every native dependency. Apple's ENABLE_POINTER_AUTHENTICATION setting adds an arm64e slice to ARCHS_STANDARD; it does not simply replace arm64.
• Decide with dotnet/runtime and the SDK whether these need distinct RIDs/runtime packs or can be additional slices behind an explicit option for an existing RID. Preserve multi-slice build/merge capability even if x64 support is eventually dropped.

Expected outcome: a compatibility matrix, a native-only testing plan, identified runtime/SDK prerequisites, and a proposed build/packaging model. Verify the current requirements for arm64e.x1 rather than extrapolating from ordinary arm64e.

References:

• Preparing your app to work with pointer authentication
• Improving control flow integrity with pointer authentication
• Xcode build settings
• dotnet/runtime#109457 (PAC-RET work; not equivalent to Apple arm64e ABI support)

Steps to Reproduce

N/A: feature-support investigation, not a reported regression.

Did you find any workaround?

Continue using the existing arm64 targets. Isolated native harnesses may allow preliminary arm64e testing without full managed-runtime support.

Relevant log output

N/A.