Developing on a M1 Mac with Visual Studio for Mac
Hi! We recently posted about how Visual Studio for Mac is supporting Apple Silicon / M1 architecture through the Rosetta translation layer starting in version 8.9, and we’re working towards native support. We’ve been using and testing with M1 Macs, but it’s always great to hear how .NET and Visual Studio for Mac are working for our customers in the real world. We’ve invited Aaron LaBeau, an MVP and seasoned Mac developer, to share his experiences. Thanks, Aaron!
We’re continuing to improve the M1 development experience in Visual Studio 8.10 Preview. Please try the preview and let us know your experiences!
Apple’s recent news of switching processors from the Intel x86 family of processors to custom processors has caused a lot of talk among the development community. The M1 processor is a custom ARM 64-bit processor and is based on the popular A series processors that Apple has been designing and shipping in mobile devices for years. Apple is now shipping several models of computers all with M1 processors. I have been using an M1 Mac Mini since the launch of the M1 building software with .NET tools and my experience has been pretty good so far… for the most part. When I tell developers “Hey I’m running everything on a M1 Mac Mini,” I get a lot of questions about support of various development tools used to build .NET applications and services that run in Azure.
How does Visual Studio for Mac run on M1? First, keep in mind that I don’t work for Microsoft or Apple, and I’m just sharing my personal experience here. Visual Studio for Mac runs on M1 thanks to a translation layer called Rosetta 2 which translates x86 instructions to ARM64. It’s designed to run without end users noticing it, and “for the most part” it works like this. The performance feels the same as running on my 2019 MacBook Pro 16” with a i9 Processor fully loaded with max RAM and storage, maybe even faster at times.
You’ve seen me state “for the most part” several times so far. With any massive change in technology there will be some hiccups. Large complex tools with many dependencies will take time to get ARM64 support fully working. I’m not going to lie, there has been some small amount of pain when using a M1 Mac to develop software. Most of it is around things I’ve had not work and then had to research fixes. I would like to share with you my experiences below.
Web Developers
Out of the box Visual Studio for Mac runs great for ASP.NET development of APIs and Razor Webpages. I’ve worked on multiple projects and a few Blazor apps and I’ve been able to open them and debug without issues.
When you go to download Edge, select the “Mac with Apple chip” version if you have M1 processor and you will get an optimized version of the browser.
As you can see from my screenshot below, I have Microsoft Edge selected to use to debug with and I have the Blazing Pizza app debugging in Visual Studio for Mac without issues.
For those web developers using other open-source software and tools, Homebrew now supports the M1 processor. You can find the download for Homebrew here.
While homebrew does support the M1 processor, some tools will not install properly without changes to the way you install them. You can tell the command line which architecture to use when running commands. For example, until the Node.js v16.0.0 release (which included ARM support), I used the following syntax to tell Homebrew to install node with native M1 processor support:
arch -arm64 brew install node
This would tell brew to install the arm version of node. If you wanted to support X86 and use the Rosetta 2 translation layer you could install it with:
arch -x86_64 brew install node
Even running complex projects, like a project based on Jason Taylor’s Clean Architecture .NET Core NuGet package are possible. For this, I simply followed the directions from the GitHub repo and thanks to the awesome integrated Terminal support in Visual Studio for Mac I launched the Angular Web App which is node based right within the Terminal in Visual Studio for Mac. The terminal even supports all my custom fonts and colors I have setup in zsh. I don’t know which developer worked on the terminal plugin, but they deserve a virtual high five for this because it’s one of my favorite features in Visual Studio for Mac.
Also, did you know that you can open more than one Terminal window in Visual Studio for Mac? This is something I think most people look over and I love that I can have more than one tab open at a time. To open another Terminal tab just click the button on the right side of the window.
I can’t express how much this has helped my workflow given I still use the command line for a lot of things like git.
Mobile Developers
On the Xamarin front, life is pretty good unless you’re using Android emulators. The good news is that .NET expert, Podcast host, and internet streamer James Montemagno has a great article already up on how to work around this which you can read in his blog post on how he setup his M1 Mac for Xamarin Development
I would note I did a different work around to get my Android emulators working which involved the following:
- Installing Android Studio from the Android Developer Portal (I use this for complex profiling and debugging of mobile apps)
- Using the AVD Manager setup a new emulator using the arm64 image
Once I did this – Visual Studio for Mac saw the device and I could use it to push builds and debug without issues. It’s also very fast for an emulator – way faster than the emulators I used to use in the past and with Hot Reload working I feel like I can do very rapid mobile development.
Docker Support
The one minor pain is Docker support. The Docker Desktop client now runs on an M1 Macs, but most of the docker images have not been updated for the ARM64 architecture. Because of this, running the standard SQL Server in Docker on your local machine isn’t possible today via Docker. I do have a work around though – Azure SQL Edge has been ported to ARM64 and thus can run on Docker for M1 on your Mac.
A sample on how to get started using this Docker image is:
docker run -e "ACCEPT_EULA=1" -e 'MSSQL_SA_PASSWORD=P@ssword123' -e "MSSQL_PID=Developer" -e "MSSQL_USER=SA" -p 1433:1433 -d --name=sql mcr.microsoft.com/azure-sql-edge
Once running you can use Azure Data Studio to connect to the docker image running on localhost (127.0.0.1).
I’ve used Azure SQL Edge with Entity Framework Core and EF 5 for testing my ASP.NET Core projects and it works fine on my machine with a standard connection string.
Honorable Mention: Visual Studio Code
For those that also use Visual Studio Code – there is now support for ARM64 and the latest build should have universal support. You can read more about this in the release notes.
Summary
While the first couple of weeks trying to develop software on a M1 Mac Mini was painful, the entire Microsoft team of development tools have come together to resolve the major problems developing .NET software on a M1 processor. Visual Studio for the Mac runs great on the M1 processor, I’m able to develop using a wide range of technology stacks, and I really like that I don’t hear my fan start to run every time I start a docker image.
Light
Dark
11 comments
Thanks for the article, VS Code does work great on the M1 Mac!
I don’t think a lot of people realize it, but it’s worth noting that you can also deploy/install your Xamarin iOS app directly on an M1 Mac by repackaging the app file generated!
@Saamer Mansoor this is true and with Maui you will be able to target Catalyst properly in the build process which will make it super easy to get your .NET app running on a Mac natively.
I’ve been having a generally positive experience with my M1. As mentioned, certain Docker containers aren’t supported. A big pain point for me personally is that I cannot run Node-based Azure Functions locally with Azure Functions Core Tools.
Don’t you think VS for Mac lags on the M1? I use a MacBook Air M1
@Xin Chen
I don’t have a Macbook Air – but I have a Mac Mini M1 with 16 GB of RAM and it doesn’t lag at all. I can’t say the same thing for some of the other IDEs I use. XCode, Visual Studio Code, and Visual Studio for Mac run great for me (I do run the beta releases). On the Java and Python side of the fence – it’s not as great of a picture with one of the IDEs requiring me to remove the config files for it before launching every day. *sigh*
Compared to other development tools, it feels very sluggish. This is my experience and I have to use VS code to code
Please drop Visual Studio for Mac and only provide VS Code instead and put full focus on that instead. Either that, or provide Visual Studio for Mac also for Linux.
@Fred:
Do you know of the history of Visual Studio for Mac? It’s based on Mono Develop which was then renamed to Xamarin Studio, which was then renamed to Visual Studio for Mac. I don’t work for Microsoft but my understanding was the focus was on the Mac because of the numbers of how many people used the Mac vs Linux product. You can find Mono Develop here:
https://www.monodevelop.com/
I don’t believe it supports iOS development but I used it several years ago to do some .NET and Android development and it worked for the most part.
How do I make the iOS simulator run correctly? It seems like some parts don’t work, like selecting a photo in the Photo Picker. I’m using Xamarin.Essentials to access that in my app.
I read something about it being about the architecture that is targeted.
@Robert Sundström
With iOS it’s not an emulator, it’s a simulator so not all functionality will work correctly. For full testing I always recommend a physical device when writing mobile apps – be it Android or iOS because even the Android emulators can have differences between them and a physical device.
Hi Aaron, I decided to change my old 2015 MacBook air for a brand new MacbookPro M1, I use Vs Code and work actively developing a node js application with Serverless framework, I’ve spent my whole day just trying to set up VsCode debugger which wasn’t a problem at all in the MacBook air, the problem: /Users/user/.nvm/versions/node/v14.17.3/lib/node_modules/serverless/bin/serverless’ doesn’t contain any ‘host’ platform architectures: arm64e, arm64, x86_64, x86_64, arm64, arm64e
Have you ever experience this issue, if so how did you solve it?
Thanks in advance for any advice and the good article.