> I recommend actually posting your full comment, so that it becomes longer-lived.
Alright, here goes...
PART 1:
> basically every platform has a much better way to create an app for it
Yes and no.
On macOS and iOS, using Apple's first-party, in-box UI frameworks/libraries like Cocoa, Cocoa Touch, SwiftUI is the best, and only, way to make a lovable user-experience on macOS and iOS. The downside is that if your application needs some ultra-specific widget that Apple hasn't already made in Cocoa then you've got a lot of legwork to do, especially w.r.t. painting in your NSView subclass. Despite Cocoa's very modern and sophisticated aesthetics, it's still fundamentally a very 1990s OOP widget library based around composing and subclassing opaque view objects.
On Linux (and in ancient-times: UNIX environments like CDE): the native desktop app UX story has always been a hot-mess simply due to UNIX specs like POSIX not getting involved in the GUI side, and despite some OS vendors trying to be consistent (rip SGI) the widget/library vendors never had any incentive for consistency. While GTK is considered Linux's "default" widget set today, there are still other equally-native but entirely separate widget toolkits (Motif, Xaw, etc) that developers are free to use - so there is no one true way to build a native GUI for Linux today, or at least, not one readily suitable for 1990s-style RAD, in my experience.
On Windows... well, that's where Microsoft has somehow taken Windows from being its (imo) Windows XP heydays: a platform with a (relatively nice) coherent and single widget set (i.e. USER32 and ComCtl32) - with occasional third-party libs like Delphi's VCL. (Other things, like MFC, ActiveX, .NET's WinForms, and so, were just slightly-more-usable wrapper libraries over Win32/USER32/ComCtl. The fundamental unit of a GUI in Win32 is the hWnd (Window Handle), which represents some rectangle on the screen managed by Windows' window-manager (which can be a top-level window with a titlebar etc, or a composed arbitrary rectangle for a composed widget, such as a button or checkbox: Windows has always supported this high-level composition of hWnds, but with severe limitations tied to its dependence on GDI (e.g. when you're using separate hWnds for separate controls then those controls can't have z-axis alpha-blending when overlapping - and you can't do deep-color painting as GDI is fundamentally limited to 32-bit ARGB). By the early 2000s it was to clear to everyone, including Microsoft, that a modern replacement was needed - which we saw in the original Windows Longhorn demos of 2003: Windows Longhorn (then Vista) now had a true compositing window-manager[1] which allowed applications to get top-level hWnds (and without any of GDI's legacy tentacles around them) which then could be used as a render-target directly from Direct3D for high-performance, yet windowed, 3D applications[2] (OpenGL support came later). This was crucial for the design of WPF (Avalon)...
Alright, here goes...
PART 1:
> basically every platform has a much better way to create an app for it
Yes and no.
On macOS and iOS, using Apple's first-party, in-box UI frameworks/libraries like Cocoa, Cocoa Touch, SwiftUI is the best, and only, way to make a lovable user-experience on macOS and iOS. The downside is that if your application needs some ultra-specific widget that Apple hasn't already made in Cocoa then you've got a lot of legwork to do, especially w.r.t. painting in your NSView subclass. Despite Cocoa's very modern and sophisticated aesthetics, it's still fundamentally a very 1990s OOP widget library based around composing and subclassing opaque view objects.
On Linux (and in ancient-times: UNIX environments like CDE): the native desktop app UX story has always been a hot-mess simply due to UNIX specs like POSIX not getting involved in the GUI side, and despite some OS vendors trying to be consistent (rip SGI) the widget/library vendors never had any incentive for consistency. While GTK is considered Linux's "default" widget set today, there are still other equally-native but entirely separate widget toolkits (Motif, Xaw, etc) that developers are free to use - so there is no one true way to build a native GUI for Linux today, or at least, not one readily suitable for 1990s-style RAD, in my experience.
On Windows... well, that's where Microsoft has somehow taken Windows from being its (imo) Windows XP heydays: a platform with a (relatively nice) coherent and single widget set (i.e. USER32 and ComCtl32) - with occasional third-party libs like Delphi's VCL. (Other things, like MFC, ActiveX, .NET's WinForms, and so, were just slightly-more-usable wrapper libraries over Win32/USER32/ComCtl. The fundamental unit of a GUI in Win32 is the hWnd (Window Handle), which represents some rectangle on the screen managed by Windows' window-manager (which can be a top-level window with a titlebar etc, or a composed arbitrary rectangle for a composed widget, such as a button or checkbox: Windows has always supported this high-level composition of hWnds, but with severe limitations tied to its dependence on GDI (e.g. when you're using separate hWnds for separate controls then those controls can't have z-axis alpha-blending when overlapping - and you can't do deep-color painting as GDI is fundamentally limited to 32-bit ARGB). By the early 2000s it was to clear to everyone, including Microsoft, that a modern replacement was needed - which we saw in the original Windows Longhorn demos of 2003: Windows Longhorn (then Vista) now had a true compositing window-manager[1] which allowed applications to get top-level hWnds (and without any of GDI's legacy tentacles around them) which then could be used as a render-target directly from Direct3D for high-performance, yet windowed, 3D applications[2] (OpenGL support came later). This was crucial for the design of WPF (Avalon)...