Hi there! This is my first time posting on the forums and wanted to share some advice on how to run and compile MonoGame projects on M1 as there is not a lot of information out there about MonoGame and Apple’s M1.
To begin, you are going to want to remove the following NuGet packages from your project: MonoGame.Content.Builder.Task, MonoGame.Framework.DesktopGL, and MonoGame.Framework.Content.Pipeline.
Then, you will want to make sure you have the Arm64 version of .NET 6 installed on your Mac, you can download it from Microsoft’s website.
Once installed, create a folder anywhere on your Mac and open a new terminal and set the directory to the created folder, and run the following commands: git clone https://github.com/MonoGame/MonoGame.git git submodule update --init
Once you have cloned the MonoGame project, open each solution pertaining to the removed NuGet packages from earlier(ex: MonoGame.Framework.DesktopGL) and do the following for each:
Make sure to change the .NET target to .NET 6 only (make sure no other targets are set).
Note: It is okay to see IDE errors, the projects should still build just fine.
Then, run the following command for each project: dotnet publish -c Release -r osx-arm64
After all projects have successfully been built, continue to the next step.
Now, find each of the framework’s DLLs and reference them in your project. These DLLs can be found in the root folder of the MonoGame clone in the Artifacts folder(go into the Release folder for each project and find the single DLL, ex: MonoGame.Framework.dll).
Now, in order to actually be able to run the ARM compiled version you need to make sure you have SDL2 and OpenAL-Soft frameworks installed on your Mac. Note: It must be compiled and installed manually on your Mac in order to work! You can follow the instructions below:
Once cloned, open a terminal in the directory and cd into the build folder. Then, follow these commands: cmake .. make sudo make install
Now OpenAL-Soft should be correctly set up as well!
Now, if all goes to plan your project should successfully compile and run on M1! You can confirm that your application is running in arm by opening Process Monitor and looking for the Kind category, where it should read Apple. If it does, you can give yourself a pat on the back because you are all set and ready to go!
Really hope this helps out other fellow M1 users since this has been annoying me for a while as I could not find any information on it online, I wanted to be able to let others know what worked for me.
Hi, thanks for the welcome! It would be great to see this on the guide since this was an extremely difficult issue to find any details about, which is why I originally decided to create this tutorial. Thanks for tagging someone who could potentially take care of that!
MonoGame 3.8.1 (which will release soon) will support targeting M1 macOS.
However, building games on M1 macOS will still require the x64 .NET 6 SDK because we are still missing some dependencies for M1 architecture. But that is only for building. Once built, M1 is supported.
There is no date set. Since MG is made by the community, we can’t reliably announce dates. So we prefer to fully finish it first, which should be relatively soon, there are only a couple outstanding issues that are being worked on before we can call it done.
I am successfuly building monogame projects on my M1 with DesktopGL target, but I have a lot of problems with the content pipeline tool. Managed to use an older version of Pipeline (184.108.40.206) and it works to build fonts and images, but can’t seem to build content with .DAE 3d model. Is there a trick or a content pipeline version somewhere that is better with M1 or Macs in general?
For now (as of 3.8.1 and prior), the only way to make MGCB (and the MGCB Editor) to work with all types of assets on M1 macs, is to install the x64 version of the .NET SDK (not the arm64).
This is due to the fact that some libraries which are used by MGCB do not have M1 binaries. When running the arm64 .NET SDK, this forces the runtime to look for arm64 binaries, which do not exist and therefore building some contents doesn’t work (like 3D models because assimp can’t load). When using the x64 .NET SDK, it forces libraries to load their x64 binaries, which are all there and therefore working. This of course means that your development environment will run through Rosetta emulation, but it should be working without significant impact or visible difference.
This only concerns the use of MGCB and the MGCB Editor, not the games you produce with it.
Once compiled, games will run on osx-x64 or osx-arm64 targets properly without emulation starting with 3.8.1 (on prior MonoGame, games targeting osx-arm64 will not run on M1; if you need 3.8.0 games to work on M1, simply distribute an osx-x64 target there).
Thank you for the answer.
Microsoft will stop xamarin updates in November 2022.
as monogamous base on xamarin
Maui supports in the same project macos, windows, ios, android
It would be cool if we could develop a single project a single program for all platforms with some adjustments for each platform.
it’s an idea is it possible to do this with Monogame.
When I started to learn Monogame I came across a Microsoft tutorial “WalkingGame” it had the same organization as Xmarin.form ie files an ios project another android and shared files.
the idea is that if Maui gives us the possibility to manage all the platforms in a single project would it be possible with Monogame?
It’s a bit misleading, but Xamarin products are not going to stop in November 2022. What is going to stop, is the support for pre-.NET 6 Xamarin products. But by now Xamarin products are fully merged into the official .NET SDK and will continue to exist within it. There is no more separation. It’s just all “the .NET SDK”.
I don’t know MAUI, so I can’t objectively speak about it, but when if we talk about UI toolkit to make in-game tools, the industry consensus is toward ImGUI (which works on absolutely all platforms, consoles included). There is a .NET binding for it and there are some integration examples around and premade components for MonoGame (I haven’t tried that one).
To come back to MAUI, I never used it so I wouldn’t know for sure, but as I understand it, it offers the possibility to render custom bitmap surfaces, which could very well be used to render anything that comes from MonoGame.
We don’t have plans to integrate an UI toolkit in MonoGame as of now, but if we had to, ImGUI is the most probable candidate.
Thanks a lot for sharing! It worked for me also, but I have an issue: It seems that I got SDL 2.0.4 installed, which seems pretty outdated (e.g. resizing of window does not work). But I have no idea why I have not the latest SDL version…perhaps somebody has an idea. I followed your instructions.
I was trying to build my game on a M1 Mac using Visual Studio 2022. Building the game itself worked fine but the mgcb build step failed every time due to missing dependencies which aren’t compiled for arm64.
Also dotnet mgcb-editor failed to the same reason.
To get the MGCB Editor (GUI) working I had to install the x64 (not arm64) version of dotnet sdk. But this didn’t work for mgcb when invoked by dotnet build or inside VS 2022/VS Code.
Adding /usr/local/share/dotnet/x64 to the $PATH fixed this issue.
Oh good grief! THANK YOU!
I’ve been bashing my head against this for ages - uninstalling and reinstalling dotnet, visual studio (stable and preview).
Yes, if you have an M1 chip - add the x64 dotnet to your $path!
Here’s an oddity that I’ve come across. To build for Intel x64, I use this: dotnet publish -c Release -r osx-x64 /p:PublishReadyToRun=false /p:TieredCompilation=false --self-contained true
If I however change the release version to osx-arm64, it builds just fine, but when I attempt to run it, I just get an immediate killed response:
 42162 killed ./MyGame
if I run it with arm dotnet, it runs perfectly fine $ dotnet MyGame.dll
and here’s the kicker - if I publish as a single file, it will then run as Apple Silicon without any issues dotnet publish -c Release -r osx-arm64 /p:PublishReadyToRun=false /p:TieredCompilation=false -p:PublishSingleFile=true --self-contained true
Is there anything I can do to test why the non-single file version actually errored? I find it odd that it just immediately died with no error message.
edit: if I run the non-single file version in the Release folder and not Publish, it runs without issue