Welcome to the Forums @StrugglingDoge
Happy Coding!
While I do not yet code for Apple, this is a great addition to the guides, hopefully @Jjagg ? Can add it to the official pages as a link or something…
Keep it up!
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!
4 Likes
Awesome! Will have to try it!
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.
3 Likes
Hi,
Thank you good job 
when is the release date for 3.8.1?
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.
3 Likes
Hi,
thank you and good luck
another question will 3.8.1 be compatible with MAUI dotnet6?
We never checked if MonoGame can be embedded into an MAUI app. If MAUI always to set the backbuffer of a component, I would assume it to work.
What would be the intended use for integrating MonoGame into an MAUI app?
1 Like
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 (3.7.1.189) 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).
1 Like
Hi,
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?
Thank you
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.
1 Like
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.
Edit: was on the wrong branch (SDL)
Hi,
where do you initialize the resizing?
No, I just used the master branch of the SDL repo and was not aware of that the current 2.0.20 version is in a dedicated branch. All is fine now 
Hi,
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.
@mrhelmut This should be added to the docs.
1 Like
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!
export PATH="/usr/local/share/dotnet/x64:$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:
$ ./MyGame
[1] 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
In case of people getting stuck with MonoGame while using a Mac running against Apple Silicon.
I have given up with Visual Studio extension working properly due to Intel specific components needed with MGCB.
As such, I’ve moved over to using Visual Studio Code, and the CLI approach to creating projects, as per the documentation, and the handy terminal built in to Code for extending my workflow.
With each project, I now have these 3 scripts in the root of every MonoGame project.
To edit the content with mgcb-editor: edit-content.sh
#!/bin/sh
# make sure that dotnet runs the Intel x64 version only
export PATH="/usr/local/share/dotnet/x64:$PATH"
# use the x64 version of dotnet to run mgcb-editor
dotnet mgcb-editor Content/Content.mgcb
From adding and updating the content, I then need the project to run mgcb to build the content, which kicks off through a normal build automatically: build.sh
#!/bin/sh
# make sure that dotnet runs the Intel x64 version only
export PATH="/usr/local/share/dotnet/x64:$PATH"
# build and automtically make ready the mgcb pipeline toolkit
dotnet build
Using the combo of edit-content.sh and build.sh, that’s the majority of my development needs met.
The final part is to use publish.sh
#!/bin/sh
# make sure that dotnet runs the Intel x64 version only
export PATH="/usr/local/share/dotnet/x64:$PATH"
# build and automtically make ready the mgcb pipeline toolkit
dotnet publish -c Release -r osx-arm64 /p:PublishReadyToRun=false /p:TieredCompilation=false --self-contained true
dotnet publish -c Release -r osx-x64 /p:PublishReadyToRun=false /p:TieredCompilation=false --self-contained true
Although the self-contained flag is advised to be false, there is an issue on mine where if it is not self-contained, it just refuses to run as an executable. This seems to be part of the codesign with dotnet, and self-contained executables are signed.
Also, I have it generating both Intel and Arm executables, so it can be reorganised and set up as a universal app for deployment.
With these in place, I can then use VS Code, press F5 and it will then compile, debug and run my projects all in Apple Silicon.
2 Likes