Infra: drop the 10.0.107 workload set pin and move iOS/Mac Catalyst sample CI to Xcode 26.5+ #627

Summary

Remove the WorkloadSetVersion: '10.0.107' pin from the iOS / Mac Catalyst sample build workflows and move the Xcode selection from 26.3 to 26.5 (or newer), so the samples build against the current .NET iOS SDK pack and a current Apple toolchain.

Background

#622 (PR #626) moved the macOS sample jobs from macos-15 to macos-26, and kept the existing pins to limit the change to the runner. All three jobs pass on macos-26-arm64 (image 20261102.0473.1, macOS 26.7.2).

The pins only existed because of macos-15 (see #529 and #559):

• WorkloadSetVersion: '10.0.107' avoids workload set 10.0.108+, whose iOS SDK pack (26.5.10284) needs Xcode 26.5. macos-15 did not have Xcode 26.5.
• RequiredXcodeVersion: '26.3' plus a sudo xcode-select -s step selected the newest Xcode available on macos-15.

macos-26 installs Xcode 26.5 and 26.6 (the default), so the constraint is gone. As it stands, the samples build against the iOS 26.2 SDK (manifest 26.2.10233) with Xcode 26.3, which is behind the current toolchain.

Affected workflows

• .github/workflows/build-samples-todoapp-maui.yml (ios)
• .github/workflows/build-samples-todoapp-avalonia.yml (ios)
• .github/workflows/build-samples-todoapp-uno.yml (ios-maccatalyst)

Proposed change

1. Remove WorkloadSetVersion from the job env blocks and drop --version ${{ env.WorkloadSetVersion }} from the dotnet workload install steps.
2. Choose the Xcode strategy:
   • Set RequiredXcodeVersion to 26.5 (or 26.6) and keep the Select Xcode step, or
   • Remove the Select Xcode step and use the image default (currently 26.6).
3. Update the explanatory comments in each workflow so they describe the workload and Xcode choices accurately, and remove the notes about the 10.0.107 pin and the macos-15 limitation.
4. Check that the MAUI, Avalonia and Uno package versions in the samples are compatible with the newer iOS SDK pack, and bump them only where a build fails.

Validation

Validate through CI on the pull request. Triggering build-samples.yml with workflow_dispatch on the fork has not been reliable for the macOS jobs (jobs stay queued and never start). Runs triggered by a pull request do start and complete, so open the PR and use its checks.

All of these must pass on the PR's Build Samples run:

• todoapp-maui / ios
• todoapp-avalonia / ios
• todoapp-uno / ios-maccatalyst (builds both iOS and Mac Catalyst)

Check the logs to confirm that the workload set installed is the newest one, and that the selected Xcode matches the one the iOS SDK pack requires.

Acceptance criteria

• No WorkloadSetVersion pin remains in the sample workflows.
• The sample iOS and Mac Catalyst builds use Xcode 26.5 or newer and the iOS SDK pack that matches it.
• All three macOS jobs pass on the PR's Build Samples run.
• Workflow comments describe the current choices.

Risks

• The newest workload set may bring a new MAUI, Avalonia or Uno incompatibility. The Uno job is the most likely to be affected because it builds both iOS and Mac Catalyst.
• With no pin, dotnet workload install resolves the newest set on every run, so builds are less reproducible. If this causes churn, consider keeping an explicit but current pin, or a scheduled canary build.

Out of scope

• Xcode 27 and the xcode-27-arm64 image (public preview, not a standard runs-on label yet).
• Changing the minimum deployment target. That is tracked separately.