Printable View
Apple released a tech note noting that macOS 28 will no longer support Rosetta 2, necessitating native ARM Mac support: https://developer.apple.com/document...on-environment
I hope that Fantasy Ground's native Apple Silicon support gets prioritized so that it doesn't drag out as it's 64 bit support did.
I imagine that will depend more on whether Unity supports it or not.
I don't think that's an issue, Unity has supported it for years and Smiteworks had an early ARM build with Unity a few years ago. https://www.fantasygrounds.com/forum...y-Mac-M1-usersQuote:
Originally Posted by Zacchaeus
There were stability issues and it wasn't a priority at the time.
Unity definitely supports it; but the challenge is getting native versions of all the libraries we use to work correctly, especially the older libraries.
We were already talking about this internally as something to work on long term before that announcement.
Regards,
JPG
It may or may not help, but Apple’s Game Porting Toolkit has also been updated to version 3.Quote:
Originally Posted by Moon Wizard
Just as a data point, in my current weekly game, 5 of the 7 people in the game run on Apple silicon and we're seriously considering switching to another VTT due to the lack of native support. I run it on an M4 Pro Mac mini with 64GB of RAM and the machine has been completely stable, except when running Fantasy Grounds. We have had to cancel multiple sessions over connection issues, out of memory crashes and full machine freezes. This hasn't happened to me with any other piece of software, only FGU. I would hate to switch, but it's getting to the point where we'll be forced to try another solution. I feel badly for our poor GM who puts in HUGE amounts of time to make the experience as fun as possible.
It’s been about a year or two since I ran a game where others connected, but I didn’t see that kind of instability or connection flakiness then. I and my players were all on macOS; I started with an Intel Mac and moved to an M1 Max. Others also moved from Intel to Apple Silicon Macs.
@caution, it seems like you’ve had problems and others in your group may also have, as well. To clarify, did others have problems on Macs?
Also, out of curiosity, have these problems been present, different, or even worse during the macOS 15.x timeframe (i.e. since September)?
When the Mac mini M4 was announced, I pre-ordered two of them, one for my wife and I. We migrated to them on day of release and since that day, Fantasy Grounds has been very problematic. The client clearly has a significant memory leak, it crashes, we often have issues connecting that requires us to completely wipe out our installation (including our cache, and all settings). Other people in the group use Intel-based Apple products and one has an M1 Apple silicon machine without seeing these issues. My machine is an M4 Pro with 64GB of RAM, networked via 10GBps ethernet. My wife's machine is similar but with 32GB RAM. This has been very frustrating to say the least. It has been nearly 5 years since Apple switched to their own silicon and it is overdue for FG to create & compile a native client.
I think my players at the time all had an M2 at best. I haven’t yet had the opportunity to either be a player or GM with FGU on M3 or M4.Quote:
Originally Posted by caution
I wonder if any of the other Apple chips / chip generations has presented crashing problems. If so, perhaps there’s a short-term fix.
I am certainly in solidarity in wanting a fully native Apple Silicon version of FGU in the near-term, if not sooner.
I ran a tabletop game with my M1 Max yesterday. I ran two instances of FGU (GM and player) in order to display the map to the players at the table using a second portable USB-C monitor. My laptop was warm and the fans — which are normally silent — were audible (but not loud) by the end of the session. The Mac’s power usage ranged from 22-75 W during the session, and probably averaged over 50 W. Meanwhile, the same computer can drive 2-3 4K-5K2K displays simultaneously with many other standard Mac applications running — and does it silently, quickly, and generally falling under 14 W of power (see SAP Power Monitor for one way to measure this).
The power usage when running FGU is definitely the same kind I see when running a full game like Baldur’s Gate 3. This is not unsurprising, but when most of what I’m doing in FG is displaying text and simpler graphics — and I get much higher quality text rendering natively from the OS — it’s kind-of frustrating.
My game yesterday was with younger players. This group started playing as teens/tweens in 2020-2021, and many have continued on. The primary devices they have all had access to are iPhones (with one Android), Chromebooks (primarily from school), and now iPads. As some of them start to go to college, they may be getting their first “real” computers.
Even with other adult players remotely or in person, it is not always easy to have a computer that meets or exceeds the FG system requirements.
In terms of catching up to the last 5 years, I really wish there was:
- support for connecting other kinds of devices in at least some limited / player-only sense (phones, iPads, Chromebooks)
- presenting content at the table (if live) without needing a full second FG instance (which is a pain to control, since you may not be able to see it), and
- a better solution for multi-display support (probably useful more for GMs, especially with remote games)
Within my circles of potential players, a number of these touch upon Apple platforms in a significant way. With the windowing and other changes coming in iPadOS 26, an iPad version of Fantasy Grounds would be great for opening up FG to more players. (A number of organizations I’ve heard from are considering whether an iPad on iPadOS 26 might be suitable for some employees’ devices instead of a laptop.)
If there is a change to FGU to support Apple Silicon, I would personally suggest that SmiteWorks also use this as an opportunity or stepping-stone towards supporting iPads along the way — and maybe other kinds of devices, if possible. Should this be limited to player support, it still opens up options for more people to connect and widens who can join a GM’s game.
If there are libraries or other components that are needed, can these be on the GM side only? Could they be run in a separate process or even a container (repo, video)? (Yes, I realize that the container support is ARM / Apple Silicon.) As a GM, I’d gladly trade off a bit of my CPU / network if that opened up wider client device compatibility and/or got me to an Apple Silicon native app sooner.
@jaharmi The reason Balder's Gate and FG are similar is that FG is not usually just running text and simple graphics. With FG most of the GPU power is being used to calculate LOS and what should be visibility clipped or not clipped for every creature and player on the combat tracker. The most predictive of how much calculation the GPU power needs is the pixel size, number of colors of the map and number and complexity of the LOS oculars.
Then, if you are running two instances of FG you are basically doubling the load on the GPU to run both the GM copy and Player copy at the same time.
You might see some improvements if you Disable Line-of-sight or Disable Lighting. Disabling lighting can be really viable with outdoor maps in daylight.
Negative, BG runs both of these also, both NPC and PC. What it comes down to is it's better coded in how it handles these things. It's able to limit down better what needs to be loaded and what doesn't. What needs to be processed and what doesn't.Quote:
Originally Posted by Griogre
Mostly this comes from well written maps. Whereas FG has to use different calcs because each map is a custom map.
Yes a lot of GPU in FG VTT is being used on LOS and Lighting, but it's not the reason you are stating.
I thought I said most of FG GPU's use was LOS and lighting? And running two copies of the program? What reason am I missing?
Hi all and I apologize for barging in the discussion without any technical suggestion to solve the issue at hand.
I'm planning on switching to a M4 MacBook Air in the next few months. And what I just read is worring me a bit (more than a bit actually).
Since I'm DMing a couple of D&D campaign with FGU, am I safe in switching to an Apple M4 laptop?
Fairly sure that John works on a Mac, so the problem would eventually get solved.
Apple native silicon support is available in FG v4.8.0.
Regards,
JPG
OMG! Thank you! This is great. Just launched it and it's taking up 15%...of ONE CPU core and less than 1GB RAM! *MASSIVE* improvement for those of us on MacOS!
Quote:
Originally Posted by Moon Wizard
�� Wow! I didn't expect a release this soon. Thank you!
Quote:
Originally Posted by Moon Wizard
I just tried to install Fantasy Grounds in a Mac VM (running on my Mac) for $reasons. I still needed Rosetta in order to install and update the game.
The FGUWebInstall.pkg needed it. I’m not sure if this was due to something declared — or not declared, as I believe that can make a difference — in the .pkg installer, or due to something that tries to run during the installation (the updater app).
It’s still updating for me in the VM, but I can see the FantasyGroundsUpdater is _definitely_ showing up as Intel, rather than Universal. On the more updated install on the host Mac, the FantasyGroundsUpdater is also still an Intel executable.
For a better first-run experience on macOS with Apple Silicon, the installer .pkg and the FantasyGroundsUpdater should be verified on Apple Silicon and updated as necessary.
The .pkg installer may just need some updated metadata. I haven’t looked further into the installer to see if it suffers from this.
The FantasyGroundsUpdater would need to be compiled as a Universal Binary to support Intel and Apple Silicon; this would help with current Mac support and is absolutely necessary for future support (by this fall). Since the updater is needed for all update actions — along with the initial install — I would suggest that compiling/distributing it as Universal as soon as possible should be a priority for Smiteworks for continued Mac support. (That said, I personally wish the initial installation would install the latest build of Fantasy Grounds directly to disk using the .pkg payload, rather than running the updater app.)
Note that Apple already announced that macOS 27 won’t run on Intel Macs and that Rosetta 2 will have limited availability (and only for certain games, which is not likely to include FGU’s updater). I’m sure there will be more details regarding those existing announcements coming next week at Apple WWDC 2026. However, the situation is already quite clear in that apps need to support Apple Silicon fully to continue to work on macOS.
The FantasyGroundsUpdater binary is a very small program that just launches other programs (main updater engine); so it's not necessary to port at this time.
We will resolve any issues as they arise to make sure everything is still working.
The main client and updater applications are already universal MacOS binaries.
Regards,
JPG
Replied in the other thread I started, since that was more relevant.
That thread also tried to explain that if FantasyGroundsUpdater is in any critical path, it is important now and will probably be increasingly important for FG on Mac starting on Monday (Apple WWDC 26, with beta OSes for developers expected) and especially this fall.
On macOS 27 beta, the FG Steam launcher now wants to install Rosetta (which has been removed in this macOS version). For macOS 27, this can still be reinstalled, but macOS 28 will no longer support Rosetta next year. The FG application itself launches without problem, it's just the Steam launcher that doesn't work now. Is it possible to adapt this launcher to Silicon?
Edit: The Updater has the same problem.
I can also report that FG performance on a Mac mini M4 under macOS 27 is abysmal. The load average goes up to 250+, and the whole system comes to a crawl until FG is closed. On macOS 26, FG runs very smoothly.
The Updater is built as a universal build for Mac and shouldn't be requiring Rosetta. There may be a legacy library used. I'll have to check on that.Quote:
Originally Posted by Zaister
I hope for the macOS 27 performance is resolved by Apple. Since it is performing well in macOS 26, it suggests that it will likely be issues we can't resolve.
I was not referring to the updater itself, but the wrapper script that is called from the main application to start the updater. Both these wrapper scripts require Rosetta.
I have now installed Rosetta, and this also fixes the proformance inssues I reported earlier.
Thanks for the follow-up. The wrapper does still need to be re-compiled as a universal app.Quote:
Originally Posted by Zaister