Stop pinning the iPhone 16 simulator in the Makefile - #1916

Independent of the #1909 → #1915 stack — this branches from main and touches only the Makefile, so it can merge whenever.

Summary

All four make targets pinned -destination "platform=iOS Simulator,name=iPhone 16". That model is not installed everywhere, and the GitHub runner images do not always ship it, so the build fails with:

xcodebuild: error: Unable to find a device matching the provided destination specifier:
		{ platform:iOS Simulator, OS:latest, name:iPhone 16 }

This is what failed the example job on #1915. That runner had no simulator devices at all — only Any iOS Simulator Device placeholders. A re-run on a healthy runner passed with no code change.

The fix splits the destination by what each target needs

Building needs a platform, not a booted device. framework and build_example now use generic/platform=iOS Simulator, so they do not depend on any device being installed — which is exactly the case that failed.

Running tests does need a real simulator. test and test_example resolve whichever iPhone is installed and address it by identifier:

SIMULATOR_ID ?= $(shell xcrun simctl list devices available | grep -m1 "iPhone" | grep -oE "[0-9A-F-]{36}")

Override with make test SIMULATOR_ID=<udid> to pick a specific device.

A require_simulator prerequisite prints a readable message when nothing resolves, rather than letting xcodebuild fail later with its own wording.

Also dropped -sdk iphonesimulator from test, since the destination already selects the simulator SDK.

Verification

My machine has iPhone 17 and no iPhone 16, so it reproduces the CI condition. The old destination fails here with the identical error. With the change, all four targets pass:

The guard was checked too — make test SIMULATOR_ID= prints the message and exits 1.

I ran the underlying xcodebuild commands directly rather than through make, because xcpretty is not installed on this machine. The runner images ship it, and this change does not touch that part of the recipes.

Note

This branches from main while the doc and cleanup stack is still open. Both add entries to the CHANGELOG "Future release" section, so expect a small textual conflict there depending on merge order.