Support Windows ARM64

[abdnh]

This adds support for Windows ARM64.

• See related PR for the Visual Studio template: Add support for ARM64 briefcase-windows-VisualStudio-template#87
• Closes Add support for Windows on ARM #1887
• More context: Support native Windows ARM64 builds for Briefcase ankitects/anki#4678

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[abdnh]

(Windows tests failing because the stub binary URL has changed to include a platform suffix)

[freakboy3742]

Broadly, this looks great - a couple of minor details flagged inline, mostly around naming (similar naming issues to the template), and property vs method use.

[freakboy3742]

I've done some initial testing of this, in conjunction with the updated Visual Studio template.

I got a VSStudio project to build, but I needed to:

• update the Visual Studio project to use the latest build tools (v145, rather than v143). That's probably a good idea regardless, so that a fresh install of Visual Studio 2026 is easier.
• Re-install Python to make sure that I had an ARM64 build, rather than an AMD64 build. py install -3.13 installs a AMD64 build by default, for the same reason that uv does.

Even with that, I get an error launching a Toga app because it can't load _cffi_backend. I haven't gotten to the bottom of this; it might be a Python.net issue.

[abdnh]

Regarding build tools, I've not updated the version because the GitHub runner still uses Visual Studio 2022. This will apparently change next month, but I'm not sure if the ARM runner will be updated at the same time: actions/partner-runner-images#150

[abdnh]

Even with that, I get an error launching a Toga app because it can't load _cffi_backend. I haven't gotten to the bottom of this; it might be a Python.net issue.

Yes, looks like a Python.net issue. I had a look and was able to modify pythonnet/clr-loader to build ARM64 DLLs but the app then failed with this:

AttributeError: function/symbol 'pyclr_initialize' not found in library '\app_packages\clr_loader\ffi\dlls\arm64\ClrLoader.dll': error 0x7f. Did you mean: 'pyclr_finalize'?

No luck figuring it out so far. Let me know if you think we should add an error if the Toga bootstrap is used for now.

[freakboy3742]

I've found the source of the problem; the issue is that .NET Framework 4.x doesn't provide ARM64 builds, even though it's installed by default on Windows on ARM machine. You have to use .NET Core 8 (or newer) on an ARM64 machine, or use an x86-64 interpreter running in emulation mode.

See beeware/toga#2782 (comment) for details; I've just pushed beeware/toga#4331 that adds ARM64 support to Toga's Winforms backend.

[freakboy3742]

Thanks for those updates. I've flagged some cosmetic details, plus one edge case with Python 3.10 and 3.11 that we'll need to handle.

We should also update the VSCode install instructions to remove the reference to VSCode 2022 (since 2026 is what you can download now), and include a reference to needing MSVS v143 VS 2022 C++ ARM64/x64 build tools.

The only other question left is exactly how to land the PR with the other dependencies. I've merged the Visual Studio template, but I can't automate tagging new binaries until we merge this PR; but this PR can't be merged until CI passes, and that won't happen until there's a Toga version that has ARM support. Obviously we'll need to test some pieces manually and add automated CI checks afterwards to break the stalemate; but I need to work out what sequence will be best for that.

[freakboy3742]

Suggested change

	"compiled for x86_64, and is running in emulation mode on ARM64"
	"compiled for x86_64, and is running in emulation mode on ARM64 "

[freakboy3742]

Suggested change

	Windows on ARM64 is now supported.
	Briefcase can now build Windows apps for ARM64 devices.

[freakboy3742]

There's an edge case here that I (re)-discovered in testing: if you're on Python 3.10 or 3.11, platform.machine() returns the architecture of the executing binary, not the underlying machine architecture.

Since host_arch underpins a lot of this logic (and host_arch is populated by platform.machine()), we will need to add some extra logic to "correct" host_arch on Py < 3.12 on Windows.