Having invested thousands into a new 96GB unified memory Macbook, (for other professional reasons) which is running XP12 like butter even when stacked up with plugins and on full settings, I’m getting pretty disheartened to find out that it’s near impossible to find any active or thriving virtual airlines which actually support MacOS.
This is pretty frustrating when this machine is running everything otherwise so smoothly; so investing in more redundant hardware for the sole purpose of VAs isn’t really viable. Bootcamp is also not an option on M1/M2.
Am I missing something? Are there thriving VAs out there that can support MacOS?
So, when it comes to macOS support, all the clients are typically Windows based and use FSUIPC as the connection between the simulator and the website. It’s not just a platform issue, it’s a X-Plane support issue. (No, XPUIPC is not a solution, it’s a workaround in my book because it’s Windows Only)
Personally, in the past, I have used a iMac with X-Plane on macOS… It’s really good. Since I did the software for my VA, I did do some technical demo level stuff for a native client in macOS back in 2019. The software side can be solved rather quickly if the right people are at the helm. Now that my life is changing around me, and the market is changing, there might be some space to develop or create a basic client for macOS and Linux, native for X-Plane.
In the meantime, and in general, VAs require “proof of flight” where they want proof that the effort was put in to use the system or do the flight in the simulator. For my VA, Spark (https://flyspark.org/) if you don’t use the client, as long as the flight was done on a online network, the flight is typically accepted. Can’t run smartCARS due to macOS or Linux? Perfectly fine in our book. I’d be willing to bet it’s the same for other communities.
Now, a secondary issue is liveries. If the VA is a true VA, and not one replicating a IRL counterpart, the VA is entirely on the hook for their own paints. If the staff doesn’t have the sim, they can’t go through the effort to offer repaints. That’s reflective of our situation with Spark, where we are completely fictional, and, we don’t have the resources to port our repaints to X-Plane at the moment.
It is surprisingly easy to afford to buy a Ferrari. It is surprisingly difficult to afford to own one, as it is for multi-platform development.
I already have a challenge supporting eight different simulators, but at least they’re all on Windows and Intel. Add to that MacOS across two different CPU architectures and it becomes an entirely new challenge backporting features and ensuring compatibility across releases and operating system upgrades… and that’s not considering the client, just the interface to the simulator.
I’m hopeful that .NET MAUI will help on the UI front, but it still won’t eliminate the need to significantly spend on the hardware side to ensure I have the machines to test XP on Linux and MacOS. Bottom line - one needs an easy cross-platform development ecosystem to do this, and right now there isn’t one yet.
There was a comment here which mentioned only 3% of the community use MacOS, which seems to have gone, but I wanted to note that I am wary of stats like that; in which, the lack of support itself can very well be a massive contributor. I think as mac hardware has suddenly become more and more solid for gaming, we’ll see more people who are simply frustrated like myself.
@1152158 Thanks for linking your VA, I’ll check it out. The upload mechanism is definitely infinitely better than nothing at all; and I appreciate the support of that, however it’s far from ideal and less and less VAs seem to permit it; presumably due to ‘fraud’?
I am a software dev myself, so I am honestly tempted to write a multi-platform, multi sim, FSUIPC alternative at this point and go from there.
I can certainly see the liveries thing being an issue, but I think that is probably really something that is simply solved with time, and community growth. It’s not blocked by a hard technological limit.
This will get you down a rabbit hole that you haven’t experienced since Watership Down.
The devil is in the details - each sim reports things slightly differently in certain areas so unless you are trying to merely provide lat/lng/alt/airspeed you’re going to have to normalize what each sim provides. FSUIPC uses a polling interface whereas SimConnect and X-Plane use per-frame callbacks which has implications on certain critical functions like touchdown/takeoff points; if you’re polling less often than the frame rate you’re going to get bad data.
(And FWIW the overhead of FSUIPC polling means you cannot do it at more than around 70Hz, not that your FPS will be that high!) In MSFS/P3D, time acceleration rates are integers limit to powers of 2. In X-Plane, they’re variable floating point values. It’s been a while since I’ve checked, but X-Plane won’t actually expose what year it is in the sim, whereas MSFS/P3D do.
Ask me how I know all this. And if you do manage to get some semblance of a common abstraction layer, you’ve solved exactly 5% of your problem, the easiest 5%. Then you need to build an actual client with a UI. Across three different major operating systems, two (or three, if you care about x32) different CPU architectures and untold variations of said operating systems. Every major change you make needs to be validated six or nine different ways, and you need the actual hardware and software to do so.
I’m probably 95% of the way towards building a MacOS-based FSUIPC replacement for our specific use case in X-Plane but I’ve been reluctant to do so because it will dramatically slow down development (and still requires a Windows VM for the client itself or a separate machine).
I’m not too fazed by the hardware element of it, I have hardware which can boot into various Windows, MacOS and Linux instances. Multi-platform testing is indeed a bit of a PITA.
However the multi-platform side of development continues to get simpler these days; I’m looking at https://tauri.app/ right now.
It actually sounds like that 5% you talk of, is by far the most complex part, dealing with the nuances between the sims themselves.
But if we end up with something which is effectively a general case replacement for FSUIPC, either as an app to be run; or as a set of libraries; to be used by anyone else’s client - then I see that the ecosystem is in a very strong place, otherwise we remain forever stuck in Windows, or every single VA having to figure out a way to code their own non-windows clients, which as you have finished up saying there, isn’t really viable.