Ask HN: How are you dealing with the M1/ARM migration?

Mine has been great, but it's not a fair comparison. I write native apps for Apple stuff in Swift, so I'm pretty much who the new stuff was optimized for.

I have noticed that some apps can get "hangy," including Xcode, SourceTree, and Slack. I sometimes need to force-quit the system (force-quitting apps seems to now have about a 25% success rate). SourceTree also crashes a lot. A lot of this happened after I got my MBPMax14. I don't know if it would happen with any other machine.

These are not showstoppers (I've been having to force-quit for years. Has to do with the kind of code I write), but it is quite annoying. I have faith that these issues will get addressed.

I got an M1 MacBook Pro from work last year, and expecting to pay the price for being an early adopter, I set up my previous Intel-based MBP nearby in case I ran into any problems or needed to run one of my existing virtual machines. (I do varied development projects ranging from compiling kernels to building web frontends.)

In reality I have hardly turned on the Intel MBP at all since I got it. At all.

Docker and VMware Fusion both have Apple Silicon support, and even in "tech preview" status they are both rock solid. Docker gets kudos for supporting emulated x86 containers, though I rarely use them.

I was able to easily rebuild almost all of my virtual machines; thanks to the Raspberry Pi, almost all of the packages I use were already available for arm64, though Ubuntu 16.04 was a little challenging to get running.

I also had to spend an afternoon updating my CI scripts to cross-compile my Docker containers, but this mostly involves switching to `docker buildx build`.

Rosetta is flawless, including for userland drivers for USB and Bluetooth devices, but virtually all of my apps were rebuilt native very quickly. (Curious to see what, if anything, is running under translation, I just discovered that WhatsApp, the #1 Social Networking app in the App Store, still ships Intel-only.)

Just to note. You can do `docker buildx install` to make it the default backend of `docker build`. So this precludes you from having to switch commands everywhere. I haven’t figured out how you can let it build multiple architecture by default, so without having to pass the —target flag.

On my m1 I see 16x performance differences in builds in favour of native over emulated. Even simple shell script run slow or seem to stall when emulated.

It mainly seems to be Docker causing the problems. We run node.js apps, and all we had to do was update to the latest version node and a couple of dependencies (those with native modules). No app changes.

We run macOS aarch64 locally and Linux x86 on production and have yet to have a single compatibility issue (and we run a staging environment that’s identical to prod, so if there was occasionally an issue it probably wouldn’t make it to production.

Something really annoying about this is that for some reason docker can't seem to easily switch platforms for base images. If you have an x64 base image and try to run an arm64 image on top, it'll complain. Why doesn't it just download the right version automatically instead of forcing me to solve it? Seems like there are still some rough edges here.