Windows on Arm has been ready for Python development for some time. With Python 3.15, the broader ecosystem has matured significantly, with more package maintainers publishing native Arm64 wheels, allowing Windows on Arm to support mainstream Python development across a broad and growing set of workloads.
Windows on Arm is now a Tier 2 CPython platform, backed by continuous testing and CPython’s release-quality commitments. That readiness extends beyond the runtime. Widely used packages such as NumPy, SciPy, pandas, scikit-learn, Django, and FastAPI are available, while Jupyter, VS Code, Ruff, and pytest support everyday development workflows. GitHub-hosted Windows on Arm runners also let open-source maintainers build and test their projects natively.
This did not happen with a single release. Native Windows on Arm builds of CPython have been available for several versions. What changes with Python 3.15 is the maturity of the experience. Windows on Arm is now a regular CPython target; the native runtime is selected by default on Windows on Arm devices, and CPython’s Tier 2 requirements call for platform failures to be fixed or the responsible changes reverted. Package maintainers now have practical infrastructure for native Windows on Arm validation, and many widely used projects publish native Arm64 wheels. Windows on Arm is now a practical platform for many mainstream Python development scenarios. As of September 2026, a scan of the 1,000 most-downloaded PyPI projects shows about 94% of the projects’ latest releases published either a native Windows on Arm wheel or a platform-independent wheel. This measures published wheel availability, not end-to-end application compatibility. Anaconda’s main channel also includes more than 2,500 packages published for Windows on Arm.
Platform readiness does not mean every Python application is automatically ready for Windows on Arm. The runtime and a broad set of mainstream development workflows are established, but application readiness still depends on the complete dependency graph, particularly when packages rely on native extensions. Developers should confirm native Arm support for their dependencies during migration and testing.
A native Python experience by default
Windows on Arm is a PEP 11 Tier 2 platform. This designation reflects a strong support commitment; the platform has reliable continuous integration and active core developers, and platform-breaking changes must be addressed promptly. Windows on Arm CI results are considered as part of CPython’s release process. This is a clear measure of how far Windows on Arm support has progressed.
Installation is now simpler. With Python Install Manager 26.4, Windows on Arm devices default to the Arm64 platform, so requesting Python 3.15 selects the native Arm64 runtime unless configuration or an explicit architecture tag overrides it.
Python 3.15 ships a complete set of Windows on Arm component packages alongside the x64 packages. CPython runs tests on Windows on Arm, including the standard interpreter and free-threaded configuration. These jobs run as part of the normal Windows build matrix.
You can confirm the architecture of the running interpreter by launching Python and inspecting its startup banner. A native Windows on Arm interpreter includes 64-bit (ARM64) in the compiler information; an x64 interpreter includes 64-bit (AMD64).
Running Python natively keeps the interpreter and native package dependencies on the same Arm64 architecture.
Applications that still depend on x64 packages can continue to run through Windows emulation, providing a practical transition path while those dependencies add native Arm support.
An ecosystem for mainstream development
The runtime is only one part of the developer experience. A useful platform also needs packages, editors, build tools, and CI capacity. Windows on Arm now supports a broad set of Python development scenarios.
PyPI and packaging. Among the 1,000 most downloaded PyPI projects about 94% are available for Windows on Arm, either as native Arm wheels or platform-independent Python wheels that work across architectures. Much of the Python ecosystem uses platform-independent wheels, while many packages with compiled extensions now publish native Windows on Arm wheels.
pip, venv, virtualenv, setuptools, build, and modern tools such as uv are available on the platform, either as Arm native or platform-independent. Several widely used Rust-based packages publish native Windows on Arm wheels, including pydantic-core, Ruff, orjson, tokenizers, and other widely used projects. A platform-independent top-level package can still depend on a native extension, so applications should test their complete pinned dependency graph.
Scientific computing and notebooks. NumPy and SciPy now publish native Windows on Arm wheels, backed by native OpenBLAS and Fortran support. pandas, Polars, Matplotlib, scikit-learn, Pillow, h5py, statsmodels, and XGBoost have also shipped Arm64 wheels. Numba and llvmlite add native JIT compilation to the scientific and machine learning stack. These packages exercise complex compiled build systems and native numerical toolchains rather than simple platform-neutral Python code.
JupyterLab, Notebook, ipykernel, pyzmq, and psutil make the local notebook experience practical with platform-independent wheels. Developers can use browser notebooks or the Jupyter experience in VS Code with a native kernel.
Web, cloud, and database development. Django, Flask, FastAPI, Requests, and HTTPX publish platform-independent wheels compatible with Windows on Arm. Several cloud SDK packages like AWS Boto3, Azure Storage Blob, and Google Cloud Storage publish platform-independent wheels that can run under Windows on Arm subject to their dependencies. SQLAlchemy is platform-independent, while database support includes libpq packages in Anaconda main, Microsoft’s Arm64 ODBC Driver 18, and native Windows on Arm wheels for python-oracledb.
Developer tools and native builds. VS Code, Pylance, the Python and Jupyter extensions, and JetBrains PyCharm, IntelliJ, WebStorm, and Rider have support for Windows on Arm. Ruff, Black, mypy, pytest, and coverage are available. MSVC and LLVM support native compilation, while Rust with PyO3 and maturin supports the growing set of Rust-based extensions. CMake, Meson, Ninja, vcpkg, OpenSSL, SQLite, libffi, and other common foundations are available for maintainers building binary packages.
Anaconda and Conda are moving native support forward
Anaconda now publishes packages for Windows on Arm to its production main channel, which includes more than 2,500 packages for Python 3.12 through 3.14.
What’s available today: NumPy, SciPy, and pandas for numerical computing and data analysis, backed by native OpenBLAS; XGBoost for machine learning; llama.cpp for local model inference; cryptography for security; Flask and Django for web development; and PostgreSQL and ODBC connectivity through libpq, psycopg, psycopg2, and pyodbc. These packages are available as Windows on Arm builds.
Anaconda main also includes PyTorch 2.14 CPU packages and CUDA packages for Python 3.12 through 3.14, built using the Windows on Arm Clang and OpenBLAS toolchain. CUDA Toolkit 13.4.1, cuda-python 13.4.3, and CUDA 13.4 builds of llama.cpp are also available.
“Anaconda and Microsoft share a commitment to giving developers the best possible Python experience wherever they work. Bringing Windows on Arm to maturity means data scientists and AI builders can now rely on a native, trusted stack on Arm devices and our teams are proud to have built that stack together.” says Laura Sellers, Chief Product & Technology Officer, Anaconda.
Beyond Anaconda’s own channel, conda-forge has stood up a Windows on Arm repository and has begun an experimental Windows on Arm migration, initially focused on bootstrapping package-management and build tools.
Anaconda is working toward conda and a Windows on Arm Miniconda installer, giving developers a supported path to conda on Windows on Arm. Together, these efforts expand native Windows on Arm package coverage across Anaconda’s main channel and conda-forge.
Anaconda plans to add Windows on Arm support for Kilo Desktop, helping AI developers and data researchers start working in minutes with ready-to-use environments and Python packages on Windows on Arm devices, including Surface devices.
GitHub runners for Windows on Arm
The availability of Windows on Arm runners for continuous integration has been an important enabler for this progress. GitHub Actions provides the windows-11-arm and windows-11-vs2026-arm hosted runners for eligible public and private repositories. Open-source maintainers can use these runners to compile packages and run test suites on Windows on Arm.
CPython uses this runner for its own native Arm64 Windows jobs. Package projects can use the same infrastructure to produce wheels and exercise installation from a clean environment to catch architecture-specific failures before publishing. Before hosted Windows on Arm runners, projects generally needed self-hosted Arm hardware or emulation for Windows on Arm CI. GitHub-hosted runners reduce that barrier by making native build and test infrastructure available on demand.
GitHub-hosted runners are especially useful for open-source projects because maintainers can add native Windows on Arm CI without operating their own runner infrastructure. A native runner turns Windows on Arm support into a change that can fit into an existing build matrix. It also allows maintainers to test Windows on Arm continuously rather than relying on a one-time build.
“Arm is working with industry partners and community organizations such as Core Collective to expand access to native Arm infrastructure and improve upstream support. Our goal is to make Arm64 a standard part of how developers build, test, and ship software.” says Grant Likely, Fellow at Core Collective and Senior Director at Arm.
Work that continues
Our next focus is broader native wheel coverage to close gaps for PyArrow, gRPC, OpenCV, and database clients. We are working closely with maintainers to close these gaps.
Windows on Arm builds of PyTorch and NVIDIA CUDA components are publicly available for validation. Anaconda provides CUDA Toolkit 13.4.1 packages for Windows on Arm. Anaconda plans to add CUDA Toolkit 13.4.2 packages after the corresponding conda-forge release followed by CUDA-enabled packages, with llama.cpp and PyTorch among its first targets.
ONNX Runtime publishes native Windows on Arm CPU packages, and Windows ML supports Arm64 with compatible CPU, GPU, and NPU execution providers. On supported Snapdragon devices, ONNX Runtime’s QNN provider can target Qualcomm CPU, GPU, and HTP/NPU backends.
“Developers thrive when their tools just work, which is why a strong and comprehensive Python ecosystem is so important for Snapdragon X Series platforms. Working closely with Microsoft, Anaconda, and ecosystem partners, we continue to advance native support across the Python stack, making it easier for developers to build, test, and deploy applications on Windows on Snapdragon. This further enables developers to take advantage of superior performance, power efficiency, and AI capabilities of Snapdragon powered Windows devices.” says Milan Plavsich, VP, Engineering, Qualcomm Technologies, Inc.
Call to action
If you maintain a Python project, add native Windows on Arm wheel builds and tests to your GitHub Actions matrix. The GitHub Actions Windows on Arm wheel builder custom agent in awesome-copilot can help automate this work. Add the agent profile to your repository, create an issue requesting Windows on Arm support, and assign the issue to the custom agent. If you are an application developer or researcher, test your dependencies with native Python on Windows on Arm and report any gaps to the relevant package repositories.
This milestone reflects sustained work across CPython, package projects, CI infrastructure, Anaconda, Arm partners, and the Windows developer ecosystem. Our thanks to Qualcomm, Arm, Core Collective, and the many package maintainers whose work across packages, infrastructure, testing, and issue investigation helped advance native Python support on Windows Arm.