It's still possible to ship cross-platform native software. People just pretend like it doesn't exist because it's too hard, and so I respond by pretending like their software doesn't exist.
If it's hard, people are not going to spend their attention on it unless deemed worthy. Like it or not, there is a class of IT-professionals who settled on the idea that macOS won the desktop-game, reasoning that Windows is and will remain trash, and that Linux can't deliver a comparable quality in UX. Someone who wants to focus on building a product can't dedicate the same amount of energy opting for cross-platform, and that's fair. You don't have to pretend their software doesn't exist - if you're not a mac-user, it literally doesn't exist for you, and that's okay.
Its funny that gaming industry has settled on the idea that Windows won the desktop-game, reasoning that Linux is and will remain trash, and that macOS can't deliver comparable performance.
This is not meant to show that some opinion is better just highlight that people have narrow tunnel vision on what is in front of them and tend to ignore other options without consideration.
> and that macOS can't deliver comparable performance
That's not the case at all. The problem is that, much like shipping native apps, supporting a second graphics API for Mac/Linux is a pain in the ass, so nobody does it. On MacOS, OpenGL is too slow for most modern titles and Metal is too high-level and doesn't have good language bindings. Same goes for why games run better on Linux than they do on MacOS; translating DirectX to Metal is simply too slow, even for the highest-end GPUs that Apple ships. An M1 Max will struggle to get 1050Ti-tier performance when running games through MoltenVK, and doing the same thing through OpenGL certainly doesn't improve the situation.
You just agreed with them. The M1 machines are plenty powerful, we all know that, but the OS doesn't give enough support for decent performance that even Linux can achieve.
You're making the assumption that everyone _wants_ to target as many platforms as possible, have the resources to do so, and are just too lazy to do so.
In other words, you're assuming that people don't build for your platform because they're "bad."
It’s a weird attitude. The desktop app community in particular has always had a pretty strong sub-community within it that’s coalesced around the idea of “we’re just going to focus on making the best Mac apps possible”. Which, even if you’re a staunch Windows user, seems fine? If you’re a developer who likes a platform and wants to build software for that platform, to you I’d say: go nuts. There are plenty of alternatives, and that’s particularly true in this space.
I can understand disappointment around great apps that don’t ever cross the platform threshold, totally, but I’ve never thought of that as terrible, or that the developers themselves are bad. This attitude of “you don’t like what I like so you’re just wasting my time” is super strange.
I totally understand your perspective, but I'm the opposite. I prefer native apps that utilize the great libraries provided by the OS and function in harmony with the OS (In my case, things like Scrivener, Kaleidoscope, Bear, Things, Alfred, etc.). I only fall back to using cross-platform apps if a native app isn't available, or if the cross-platform app is done really well (e.g., Logseq, VS Code, etc.).
I think it's a good thing that there are people who want to work to satisfy the desires of your niche as well as mine, so we can both be happy and productive.
For minimal compromise, you'd write it in Rust/C/C++ with a GUI toolkit that leverages the native stylesheet to render everything out. It'll be fast, it will run cross-platform, and it will take forever to build. However, this is the """right""" way to do it, and the one that people will complain least about. There's a number of tools that are distributed this way, but again, it's a pain.
For medium compromise, you'd probably end up with a runtime like Java or dotnet. These runtimes have well-established, long-running GUI projects that seek to tackle this exact issue, and for most people they balance ease of development, speed and "good enough" UI. It's not perfect, but a lot of one-man dev teams will end up choosing this when they want to get on every platform with a native-enough UI.
For maximum compromise, you can ship Electron with JS bindings to a native UI. This sucks. Please don't do this. It's an option though, and I'd be remiss if I didn't mention it. It's barely better than just putting a website in a desktop runtime, and if you aren't careful you can end up making it a whole lot worse.
It's definitely possible to do, though. If you want to charge money for your application, I should hope you're building a minimal-compromise program.
I don't think there is a single "correct" way. There are several non-C/C++ ways like Java, Electron, BeeWare, etc., but all of them tend to stand out when compared to native apps, regardless of what operating system you're using.