[DeusExMachina]

I think the opportunity is particularly on how SwiftUI has been implemented in iOS, iPadOS and macOS, by relying on the native UI of each platform and providing a common abstraction for developers.

Instead of providing the same UI that works badly on every device, SwiftUI interprets each concept differently according to the platform.

For example, a Toggle in an iOS and iPadOS app looks like a on/off switch, while on macOS it's rendered as a checkbox. A Picker has is scrolling wheel on iOS but it's shown as radio boxes or a drop-down menu on macOS.

Navigation is also the same. On iOS, a NavigationView offers the drill-down navigation common to iPhone apps, while on macOS it creates a split master-detail interface.

Each implementation does so by using the native UI framework of each platform under the hood, UIKit on iOS, and AppKit on macOS. I don't know how UI development works on Windows, but my speculation is that a SwiftUI implementation would work the same way.

[FreakyT]

I can’t comment on SwiftUI in particular, but I’ve found that a lot of things like this tend to break down in most other cross platform GUI frameworks, falling into a kind of uncanny valley, where the experience ends up being either:

1. Native feeling, but sufficiently inflexible that only very simple, common UI patterns can be implemented

2. An “uncanny valley” native ui, where things are almost native but often feel wrong in subtle ways

I think that’s why Electron has succeeded where so many cross platform UI frameworks failed: it’s so obviously not native that it doesn’t fall into that “uncanny valley” anymore

[veidr]

Yes, I totally agree with that.

The way they have implemented it for even their own "cross-platform" needs (where the "platforms" are really basically different versions of the same OS) works very well — the sickening, jaw-droppingly awful apps from Twitter, JIRA, etc that use the "Catalyst" system of porting iPad apps to Mac shows why the approach is really necessary.

(Those apps bring iPad metaphors to the Mac, so what should be a single interaction, picking something from a menu, is a jarring series of taps, swipes, and animated fuckery.)

If that "render the concept using the OS's native widgets" approach was necessary even for cross iOS-macOS apps, it will be even more necessary across Mac and Windows, where a lot of the UI conventions are wildly different, and sometimes literally the opposite (e.g. the standard placement of buttons).

And it's obviously the only way it could work for web apps.