# Thoughts on running Anaconda on Snapdragon/ARM64 **URL:** \ **Category:** Packages & Environments\ **Tags:** conda\ **Created:** [September 18, 2026, 1:10pm UTC](https://forum.anaconda.com/t/thoughts-on-running-anaconda-on-snapdragon-arm64/110421 "2026-09-18T13:10:12Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![rswitt](https://avatars.discourse-cdn.com/v4/letter/r/db6015/32.png) [@rswitt](https://forum.anaconda.com/u/rswitt)\ **Post date:** [September 18, 2026, 1:10pm UTC](https://forum.anaconda.com/t/thoughts-on-running-anaconda-on-snapdragon-arm64/110421/1 "2026-09-18T13:10:12Z")
After a prior topic/discussion on issues regarding Anaconda installation on Windows Snapdragon/ARM systems, it was noted that Anaconda is shooting for a Q4 release of a native Snapdragon version. Upon some thinking, while this is great, I’m wondering if it’ll probably be best to continue to run the x64 Anaconda version in emulation for a while. When conda (before it was fixed) was incorrectly identifying the platform as Win-Arm64, it was clear that there were _a lot_ of packages that were unavailable on ARM64 (presumably because they included pre-compiled binaries that were unavailable for ARM64), including _conda_. Given that, I’m thinking that, at least for a while, running Anaconda on Snapdragon natively will result in a lot of unavailable packages until the authors provide native ARM64 versions (which may take a while). Therefore, running Anaconda x64 in emulation may be initially preferable. One thought, is it possible, with the Anaconda ARM64 version to create an environment that will run in x64 emulation? On Snapdragon we don’t really have the ability to turn emulation on or off, I believe it self-identifies when it is needed, and I’m not sure how it decides that. ---
**Author:** ![Tyler\_F\_Anaconda](https://dub1.discourse-cdn.com/anaconda/user_avatar/forum.anaconda.com/tyler_f_anaconda/32/6666_2.png) [@Tyler\_F\_Anaconda](https://forum.anaconda.com/u/Tyler_F_Anaconda)\ **Post date:** [September 18, 2026, 3:47pm UTC](https://forum.anaconda.com/t/thoughts-on-running-anaconda-on-snapdragon-arm64/110421/2 "2026-09-18T15:47:55Z")
Hey @rswitt🙂 **On package availability** — one correction that changes the calculus: for conda packages, we build the win-arm64 builds ourselves. You’re not waiting on individual package authors the way you would be with PyPI wheels. `main/win-arm64` is publishing actively today across Python 3.12–3.14, and in several cases conda has win-arm64 builds where native wheels don’t exist yet — cryptography, shapely, sqlalchemy and asyncpg among them. There is a shorter list where upstream itself is the blocker and we can’t get ahead of it. We will have documentation including guidance to users here along with the emulation strategies mentioned below. We already have 70% of package coverage for win-arm64 compared to win-64. Our goal is to enable a majority of use cases to be run natively by the time we launch the Miniconda installer. However, you are correct there will be a tail of things we will continue to work on building out post the initial launch. **On emulation** — you will have a few options here, we are working on adding more information to our documentation ahead of the launch to make sure this is clear for all users. In short, 1. Stay fully emulated — the win-64 installer, as you’re doing now. 2. Go native, and flip the whole install to x64 if you need to: `conda config --set subdir win-64`. 3. Mixed, which is likely what you actually want: a native install with specific environments created as x64. For (3): ```auto conda create --platform win-64 -n legacy python=3.13 ``` This is native conda functionality, not a workaround. conda annotates the environment with that target, so later installs into it keep resolving win-64. You can’t retrofit `--platform` onto an existing environment — it’s create-time only. ---
**Author:** ![rswitt](https://avatars.discourse-cdn.com/v4/letter/r/db6015/32.png) [@rswitt](https://forum.anaconda.com/u/rswitt)\ **Post date:** [September 18, 2026, 6:43pm UTC](https://forum.anaconda.com/t/thoughts-on-running-anaconda-on-snapdragon-arm64/110421/3 "2026-09-18T18:43:35Z")
@Tyler_F_Anaconda , this is great info I’m so glad I asked! Thank you for taking the time for such a complete response! ---
**Author:** ![Tyler\_F\_Anaconda](https://dub1.discourse-cdn.com/anaconda/user_avatar/forum.anaconda.com/tyler_f_anaconda/32/6666_2.png) [@Tyler\_F\_Anaconda](https://forum.anaconda.com/u/Tyler_F_Anaconda)\ **Post date:** [October 15, 2026, 11:16pm UTC](https://forum.anaconda.com/t/thoughts-on-running-anaconda-on-snapdragon-arm64/110421/4 "2026-10-15T23:16:00Z")
Closing the loop on this one. The Windows Arm64 Miniconda installer shipped this week, and the documentation I mentioned is now live: [Migrating from win-64 to win-arm64](https://www.anaconda.com/docs/getting-started/working-with-conda/windows-arm-info). It covers the three setups we discussed (fully native, fully emulated, and native with specific x64 environments), with a pros and cons table to help you choose. On coverage: the main channel now has thousands of native Windows Arm64 packages. That includes PyTorch (CPU and CUDA), the CUDA Toolkit and llama.cpp, plus the core data science stack. [main/win-arm64](https://repo.anaconda.com/pkgs/main/win-arm64/) Your point still stands that there will be a tail of packages we’re still working through, which is why the `--platform win-64` option is documented as a supported path rather than a workaround.