Yes, but it's very rare now a days. I live in JVM land and there are quite a few native JNA libraries that I have run into issues with. One example is vlcj [1] I just ran into yesterday. I have yet to dig deeply into the issue just yet, but it's giving me the fun "no compatible architecture found error". SWT and JavaFX both fully works with arm now though, so I am pretty happy on that front. GraalVM native-image also does not support building ARM on Mac yet either. On the C/C++ side of things I have not ran into any incompatibility issues in the last 5 months. I'd say 99% of my time is smooth sailing at this point.

[1] https://github.com/caprica/vlcj

They really need to get on and support macOS ARM for GraalVM. It's clearly not going away - it just needs doing.

While we're asking, would it really be that much trouble getting Vulkan working? It falls in the same category of 'not going away but needs doing'.

Vulkan already works ok through MoltenVK.

It's far from a complete solution though, and it's still going to have worse performance than a native implementation. Apple needs to prioritize Vulkan support on these devices if they don't want to repeat the last 15 years of Mac GPU issues.

Close to no https://isapplesiliconready.com/for/developer

I wonder about games, and sadly this website doesn't list any.

I want a new laptop and those new M1 MBPs look interesting, with low TDP high performance. I primarily use it for development and browsing when I'm not home (I have a family overseas), but I also want to play games now and then.

I know Steam has native ARM support and some games I play are ported as well, but I really wonder how much can I get from double translation layers (x86 to ARM + Wine or derivatives).

Games are decent to good, I had a good experience using CrossOver--though I was playing 2d (spelunky, omori at the time). https://www.codeweavers.com/compatibility/ Retro emulation is phenomenal, PS1 PSP DS no problem, everything earlier great. YMMV as I have separate gaming machines

Of course. Any time you try to run a non-ARM binary on an ARM CPU without some form of translation or emulation, it will fail.

This is also true for any other CPU architecture.

If you want to know about specific compatibility issues, I'm happy to try to help as I've been using an M1 Air as my daily driver for many months now.

> without some form of translation or emulation

IIRC that's why Rosetta2 exists. The question is more whether there are issues despite that

I don't think I've ever had an issue related to Rosetta2. Everything I had to run on it worked flawlessly and without any noticeable performance hit.

This is only my own anecdote though.

I also had everything working fine but performance is really bad when you go through rosetta.

For example, discord client is still x86 and while it works without any issues, the heaviness is noticeable.

Also, .NET 5 does not have an arm build (.NET 6 does but it is still in beta). The entire toolchain works but compiling a binary can be 3-4 times slower on the emulated one.

Things work without any issues though. They are just slow.

I don’t notice many performance differences comparing GUI apps. Discord’s PTB is M1 optimized and, guess what: It’s just as shit.

PTB still shows up as Intel binary: https://cln.sh/5KA9Vh

I was running the main ruby on rails app I work on via Rosetta since the first M1 MacBooks came out. The performance hit was there for sure, but not huge. Running local tests or seeding my database ranged to "about the same" to 10-20% slower than my 10 core iMac Pro, which is still a pretty fast machine.

Since I've upgraded the app to support Arm natively, almost everything runs faster on the m1 13" macbook compared to my 10 core iMac, with the exception of long running tasks that will use all the cores you can throw at them.

There have been some font rendering issues in Ultimaker Cura (which is written in Python) that ran as x86 on M1. These have been resolved in the Python library.

In fairness, I've seen font rendering in Cura on Linux as well.

I've seen font rendering issues in Cura on Intel Macs as well. Cura's GUI and UX are pretty bad in general IMO though, so I don't use it.

Did they finally get Docker working on the M1 chips?

Yes. https://docs.docker.com/desktop/mac/apple-silicon/

Native ARM containers work but there are various things that break with Docker x86 emulation, eg with Node.

Mostly. Docker for Mac's internal VM consistently kernel panics the first time I launch it after a reboot. I also have containers freeze up every now and then, something that never happened on my Intel machine.

Docker works mostly fine. ARM images are pretty common, and for those that don't have it, it runs a QEMU emulated x86 machine.

I have hit issues with it but they're rare enough that I don't care.

It’s somewhat unreliable and file system interaction is slow, but from what I’ve heard that means it’s no different from x86 Docker Desktop.

Docker has been working for months.

You’re missing the point, it’s an ecosystem question. I personally don’t experience many issues at all. If I do they’re usually solved by switching to Rosetta (but that does introduce some hairiness for command line stuff).

Full version of MS SQL Server doesn't work. The X86-64 Docker image won't start under QEMU emulation and the installer won't install it in the ARM64 insider builds of Windows 10/11 running in Parallels. You can use the ARM64 build of Azure SQL Edge, but it lacks many features that may or may not be important depending on your use.

Here's the GH issue related to the Docker issue if curious: https://github.com/microsoft/mssql-docker/issues/668

> Full version of MS SQL Server doesn't work

Stay tuned. (to avoid emulation)

> the installer won't install it in the ARM64 insider builds of Windows 10/11

Yeah, that was a bug: https://support.microsoft.com/en-us/topic/kb4530084-fix-erro...

The solution that works is running the SQLS installer, see that error, install that CU update, then restart the SQL Server installer that _then_ continues.

But that's an unreliable process, would need new install media to be fixed properly.

I have an M1, and I was unable to install tensorflow in a docker container on the M1 host (as of last time I tried, a few months ago).

I run tensorflows yolov4 no problem on m1 macbook air, cool thing is that you can fit larger models in memory than if you had a 8GB NVIDIA Card

Training or inference? How's training performance compared to 8GB NVIDIA, if you have one?

Yes, and they will never go away entirely

You can never run x86 dockers as easily and as quickly as on intel. If you have bunch of scripts in some deployment/development pipeline that depend on docker being x86, they will fail.

Other things…I’m not sure about October 2021, but last time I looked, R was still only available through Rosetta, because parts of R are in FORTRAN and that does not have native M1 support (yes FORTRAN), but honestly it’s so fast with emulation that it does not matter.

Same SciPy… or was it NumPy? One of those two have parts in FORTRAN and can only be run through Rosetta (so it can wreak havoc as you might need python pipeline parts in ARM and parts emulated). But I have not hit that personally as I don’t use Python directly

you cannot run Windows either dual boot or in virtual machine. Same with x86 linux.

There's no problem with either scipy or numpy running natively on Apple Silicon. The problem is with the 3rd-party package managers, which are all junk, and that's not new: they've always been hot garbage, especially homebrew. Just don't use homebrew, and then after you get used to that, don't use it on x86, either.

There were issues with numpy/scipy because of lapack and fortran. I guess they solved it somehow.

There were problems with homebrew finding a fortran compiler for this platform, there were not problems with fortran on macos/arm64 itself. fortran for macos/arm64 has existed since the platform was available. OpenBLAS has worked fine as far as I can tell with `make FC=gfortran`. The only problems have been with package managers.

You can run Windows ARM in emulation, as the MS Surface uses ARM and has a version of Windows available.

I have run Windows ARM in Parallels on an M1 on a client's machine.

In my experience the main issue with the M1+macOS experience is not the ISA, it's the big-little thread scheduling. I'm not sure what they were thinking but there's some heuristic that schedules background or batch work on the little cores. This includes manually-triggered software updates which unfortunately can take forever on those little cores. I waited almost 4 hours for an Xcode update to complete. All four little cores were maxed out the whole time, and these new chips only have two of them.

Doesn't an Xcode update _always_ take about 4 hours?

I haven't run into any issues. Homebrew seems to be (mostly) working, and most vendors have created universal images at this point. I think the only thing I'm personally waiting on is VMware Fusion (currently in beta).

Swift still doesn't have an Arm docker image from the official Swift.org group.

I mean, yeah. You're not going to be running anything 32-bit, and you can't use OpenGL or Vulkan, which already rules out a decent handful of workflows (including but not limited to my own). On top of that, there's legendary Docker issues that plague pretty much anything running MacOS, and there still isn't a competitive, complete package manager. eGPUs are almost completely off the table, and if they do work you won't be allowed to run an Nvidia card, you can't use CUDA, and OpenCL is fully depreciated.

So yeah, there's still quite a few holdouts on the MacOS and ARM side of things. Unless you're confident that your workflow functions perfectly on ARM, you should probably stick with a nice x86 machine for the foreseeable future. Apple will definitely improve on this model, so if you are dead-set on buying one I probably wouldn't spring for the first-gen anyways. Just my two cents though.

OpenGL still works on the M1 (Apple designed their own GL-over-Metal driver), albeit with the OpenGL version limitations from modern macOS in general. Vulkan works over MoltenVK.

Other than old games, I'm not sure why 64-bit only is an issue.

I've not hit any Docker-on-macOS issues with what I've used it for, at least.

Is MoltenVK usable right now? I was under the impression that it's a loooooooong ways behind DXVK in it's current state.

I've seen plenty of projects that use MoltenVK as a drop-in backend for macOS. It seems complete enough for general use, but I haven't used it directly so I'm not sure what's missing.

they're largely resolved--my air no longer panics and I cannot recall when it last did, though it did panic frequently the first several point-releases;

my web development is largely unaffected since around the 2nd quarter of 2021 and actively developed software either has a release for apple silicon and when that's not the case it mostly works with occasional crashes (eg inkscape); obviously this will depend on what applications you use however homebrew, node modules, deno, rust, etc all are working well in various long-lists of items that are less relevant beyond my generalization here; I intend to use applications running in windows and qemu but haven't taken time yet

Yes. Most user applications have been updated but plenty of libraries have not been.

Most of the python packages that have significant C deps often have issues compiling (e.g. Scipy, igraph, etc). It's almost always possible to work around these issues but it gets tiring since it's compounded with the usual macOS breaking changes every year. Any binary compiled with AVX-512 instructions (e.g. Tensorflow, MuJoCo, etc.) will also need to be recompiled.

So tl;dr most (but far from all) popular closed source programs have been updated/recompiled for ARM (or at least run decently with Rosetta), but many libraries/open-source projects require some painful recompiling.

youtube-dl didn't work when I tried it 3 weeks ago

I’ve used youtube-dl for the better part of a year now on M1 without issues. If it didn’t work for you, then you need to look into what’s broken on your specific machine.

YouTube dl is just python, whether or not it runs just depends on whether or not python’s interpreter runs on ARM, which it definitely does.