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.
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.
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
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 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.
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.
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.
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.
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 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.
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.
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.
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.
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.
