1. You compare dev version of linux compositor to stable versions of the other OSes
If the app fails to start or crashes when it runs under one WM or another, then following happens:
- app is using something/talking to something/assumes something in a way it is not supposed to -> bug in the app
- the WM or compositor doesn't take some message or poking in a way it is supposed to take -> bug in the WM or compositor.
The example you posted is sway, during the time it was in development. I stress again, it was in development, it was not supposed to be bug-free, and no distro shipped it. Applications do crash under dev version of macOS and Windows too; you just don't see that because the respective bug trackers are not public, and the respective dev builds of the os are not very public either. In Linux, you have access, but then you have to break something, with the implicit understanding that when that happens, you get to keep the broken pieces.
Nobody sane would consider that supporting development versions of any package on any OS is something you are supposed to do.
Related: Switching to Wayland is mostly non-issue. If your app previously used X11, it will continue run using X11 under Xwayland. If anything, the Wayland developers made it too seamless. Unlike Apple, which made XDarwin eye-sore, so the users would be aware and demand updates.
2. You compare different layers in the stacks
In Windows, you have to use MS provided UI toolkit (whether Win32 or UWP, doesn't matter). In macOS, you have to use Cocoa. Neither of these vendors would allow you to talk directly to their respective compositor, no way around it.
In Linux, just because you can - everything is transparent - doesn't mean you should. If you want to play at the same level as you do on Windows/macOS, use it at the same level: use a toolkit, that will abstract the same things for you, as the vendor supplied frameworks on the other OSes do. Gtk, Qt, Electron, doesn't matter, they do the heavy lifting for you. Do not talk to compositor directly - then you do not even have to care, whether it is X11 or Wayland, the toolkit will arrange it for you.
By inserting yourself on the different level in the stack, you assume on yourself solving all the problems that are being solved there. If you want add your workload, you are welcome, but then be honest at least to yourself and admit, that it is easily avoidable self-inflicted pain.
---
I understand, that there is no system-wide SDK with a given ABI, and that can be frustrating sometimes. I understand, that ABIs that distributions provide are semi-stable. There are solutions for that:
1. Pick a distribution you will support. Blackmagic supports RHEL/CentOS, nothing else. GoG supports Ubuntu. If it runs anywhere else, cool, but you are on your own. Similarly, you can even support several of them, but when someone decides to do X, where X breaks other apps, he is on his own. When the user is competent of breaking something on his own, surely he is competent of fixing it too. You don't support users who hex-edited their system libraries in Windows either.
2. Use flatpak. You choose the runtime, you choose when your app switches to newer runtime. Most runtimes have defined support periods and document, what can change during that support period (i.e. freedesktop one allows for security updates and updated OpenGL drivers). This has the advantage, that nobody is going to try using their self-compiled libraries as a replacement for the runtime-supplied ones.
> Pick a distribution you will support. Blackmagic supports RHEL/CentOS, nothing else. GoG supports Ubuntu. If it runs anywhere else, cool, but you are on your own.\
I'll take "reasons it still isn't the year of the Linux Desktop" for $1000 Alex.
Well, for Blackmagic products you usually need to attach hardware that is well beyond most home budgets. What distributions they do or do not support is immaterial for the linux desktop, but they were provided as an example of their approach.
For GoG, they run very well everywhere; they just explicitly support Ubuntu.
The point was, that WMs are not even a factor in the support matrix. They either manage windows or don't, but your app doesn't care, it just paints its window. How the user places it on the screen is his problem.
1. You compare dev version of linux compositor to stable versions of the other OSes
If the app fails to start or crashes when it runs under one WM or another, then following happens:
- app is using something/talking to something/assumes something in a way it is not supposed to -> bug in the app
- the WM or compositor doesn't take some message or poking in a way it is supposed to take -> bug in the WM or compositor.
The example you posted is sway, during the time it was in development. I stress again, it was in development, it was not supposed to be bug-free, and no distro shipped it. Applications do crash under dev version of macOS and Windows too; you just don't see that because the respective bug trackers are not public, and the respective dev builds of the os are not very public either. In Linux, you have access, but then you have to break something, with the implicit understanding that when that happens, you get to keep the broken pieces.
Nobody sane would consider that supporting development versions of any package on any OS is something you are supposed to do.
Related: Switching to Wayland is mostly non-issue. If your app previously used X11, it will continue run using X11 under Xwayland. If anything, the Wayland developers made it too seamless. Unlike Apple, which made XDarwin eye-sore, so the users would be aware and demand updates.
2. You compare different layers in the stacks
In Windows, you have to use MS provided UI toolkit (whether Win32 or UWP, doesn't matter). In macOS, you have to use Cocoa. Neither of these vendors would allow you to talk directly to their respective compositor, no way around it.
In Linux, just because you can - everything is transparent - doesn't mean you should. If you want to play at the same level as you do on Windows/macOS, use it at the same level: use a toolkit, that will abstract the same things for you, as the vendor supplied frameworks on the other OSes do. Gtk, Qt, Electron, doesn't matter, they do the heavy lifting for you. Do not talk to compositor directly - then you do not even have to care, whether it is X11 or Wayland, the toolkit will arrange it for you.
By inserting yourself on the different level in the stack, you assume on yourself solving all the problems that are being solved there. If you want add your workload, you are welcome, but then be honest at least to yourself and admit, that it is easily avoidable self-inflicted pain.
---
I understand, that there is no system-wide SDK with a given ABI, and that can be frustrating sometimes. I understand, that ABIs that distributions provide are semi-stable. There are solutions for that:
1. Pick a distribution you will support. Blackmagic supports RHEL/CentOS, nothing else. GoG supports Ubuntu. If it runs anywhere else, cool, but you are on your own. Similarly, you can even support several of them, but when someone decides to do X, where X breaks other apps, he is on his own. When the user is competent of breaking something on his own, surely he is competent of fixing it too. You don't support users who hex-edited their system libraries in Windows either.
2. Use flatpak. You choose the runtime, you choose when your app switches to newer runtime. Most runtimes have defined support periods and document, what can change during that support period (i.e. freedesktop one allows for security updates and updated OpenGL drivers). This has the advantage, that nobody is going to try using their self-compiled libraries as a replacement for the runtime-supplied ones.