[Apocryphon]

It's sort of dismaying that SwiftUI is regarded as a superior native choice as opposed to second-citizen cross-platform frameworks, then see examples like the macOS System Settings app. Though perhaps that is more of a case of poorly-executed Catalyst iOS to macOS porting, and poor design, than a lack of "nativeness" with SwiftUI.

The framework lacking consideration for navigation until recently shows that its rollout has been half-baked, though.

[jwells89]

The problems with the macOS settings app have just as much or more to do with its design as they do with SwiftUI. If they had instead built the redesign with AppKit it’d feel a bit smoother in some areas but would be just as flawed. Just making it more traditionally Mac-like would go a long way.

[Apocryphon]

I've heard a lot of disgruntlement from macOS developers about SwiftUI. I wonder if the framework has an inherent bias for iOS and maybe iPadOS? Again, it's crazy that after years of disparagement of kludgy cross-platform frameworks (albeit more from the fans than the company itself), Apple basically went ahead and built their own, with fewer supported frameworks than the third-party alternatives.

[jwells89]

SwiftUI definitely has an iOS/mobile bent to it, no doubt because iOS is its flagship platform. macOS no longer has the corporate gravity that it enjoyed prior to the iPhone, when AppKit received most of its post-NeXT development.

This problem isn’t exclusive to SwiftUI though, WinUI/Windows App SDK is also mobile-flavored likely due to its UWP heritage, lacking basic desktop widgets like a tableview/datagrid.

[DaiPlusPlus]

> This problem isn’t exclusive to SwiftUI though, WinUI/Windows App SDK is also mobile-flavored likely due to its UWP heritage, lacking basic desktop widgets like a tableview/datagrid.

Hah, it's far worse than that - Microsoft has let their desktop DX story stagnate for 15 years now (WPF was launched in 2006), since then Microsoft hasn't launched any new desktop-first UI framework for Windows, nor offered more than token improvements to User32, CommonControls, and WinForms since then.

It's no lie that everything MS has done in the UI-framework space since Windows 7 in 2009 has been a waste of time and money. It started-off with the "Metro" Windows Phone reboot, then the shoehorning of that into Windows 8, and the various XAML-derived frameworks since then - and none of them have attempted to tackle the very fundamental flaws (declarative data-binding doesn't scale, INotifyPropertyChanged breaks causality tracking and cannot be unit-tested, mutable ViewModels were carved by Lucifer himself!) - and as you said, no care or attention is paid to applications needing high information-density display.

----

...so while all this is going on, the Office org came up with its own in-house GPU-accelerated UI introduced in Office 2013 which we can all agree is slow, bloated, glitchy (y'ever used Excel with a 500Hz mouse?), but also proprietary and undocumented, so the wider Windows ecosystem can't benefit from the Office org's framework which would have otherwise (almost) neatly filled the gaps left-behind by the Windows org.

I just want Satya to hire me for the job-title of "VP of Consistent User-Experience" and I'd make it a top-priority that Windows itself comes with a reusable spreadsheet+datagrid component that all applications can use - and it wouldn't cost the company more than a year and a few million dollars - but save billions by avoiding lost developer confidence - and would serve to remind everyone that native desktop UX can always be better than browser-based UX.

---

Sorry, am ranting.

[geodel]

MS UI-framework story is essentially over. From now one they are all about converting all UI to ReactJS or some other flavor of it. This will include the whole MS Office suite.

It is all about financialization of software so art and craft wouldn't matter. End goal is simply cloud desktop with integrated AI/ChatGPT user interface which can be charged per user / per month basis.

[glhaynes]

...so while all this is going on, the Office org came up with its own in-house GPU-accelerated UI introduced in Office 2013 which we can all agree is slow, bloated, glitchy (y'ever used Excel with a 500Hz mouse?), but also proprietary and undocumented, so the wider Windows ecosystem can't benefit from the Office org's framework which would have otherwise (almost) neatly filled the gaps left-behind by the Windows org.

That's funny, just a few hours ago I was looking at some pics of Office 95 running on Windows 95 and reminiscing about how Office's menu bars and toolbars looked/worked differently than the system standard ones despite both being presumably worked on in parallel. Some things never changed.

[DaiPlusPlus]

Well, yeah - Ever since Office 95, the Office UI has always been different to the base OS in some way or another (I think Office 97 was the closest it has ever been to the "stock" Windows UI), but not outrageously-so until Office 2007 came out; Office 2010 is my personal favourite edition because it was the last edition that had a coherent visual design with a fast and snappy UI that didn't require gigabytes of RAM and a GPU to run with reasonable performance, even if Office 2010 cemented the fact that the high-degree of end-user software customization we used to enjoy was now on-the-way-out: now all we can do in Office is choose either Light vs. Dark scheme - and pick from a limited selction of tacky-looking ribbon background images as though we're picking-out a new Trapper-Keeper for the new school-year.

[Narishma]

I don't think Office 95 had a different UI than the rest of the system. The only thing I remember being different about it is the title bar where they introduced the gradient that was later picked by Windows 98 and 2000. The menus and toolbars looked and worked the same as other Windows 95 applications.

You may be thinking of Office 97, which introduced the "flat" look for the toolbars and the animated sliding menus.

[doublepg23]

It's funny the most "consistent user experience" I have day-to-day is on GNOME.

[dwaite]

The rumors I heard were that SwiftUI was originally meant to launch for watchOS first, to fill in the (sizable) gaps with the UI framework there.

I suspect even though it was always meant to be a cross-platform UI framework, the initial layout system was designed more toward composing and filling a smaller fixed space than for dealing with large resizable windows.

[cageface]

I think flutter is emerging as a compelling alternative for cross platform desktop development. I’m building a desktop app in it now and so far the experience has been quite positive.

[jwells89]

Flutter is also mobile-skewed unfortunately, putting it in the same camp as WinUI if you need more classical desktop widgets. Third party widgets can fill this hole in some cases, but for me that defeats much of the point of using a pre-existing UI toolkit…

[ShadowBanThis01]

Except it uses a language no one knows, unfortunately. I considered Flutter, but fat chance finding contractors who know Dart.

We ended up building a cross-platform desktop app in Qt and QML, and it works great.

[Apocryphon]

Dart takes like a month, if at that, to learn. Its mundanity makes it interchangeable.

[steve1977]

Might also be because Cocoa on the desktop had many problems solved already that are being solved by SwiftUI on mobile now. For example bindings to keep views in sync with a model.

[jwells89]

I’ve been writing code for Apple platforms for over 15 years at this point and I still occasionally find myself surprised with how far one can take a Mac app with little more than Interface Builder and Cocoa bindings.

[saagarjha]

Settings is not a Catalyst app; it’s a poorly designed full rewrite.

[Apocryphon]

Well that’s just inexcusable.

[superb_dev]

I agree that navigation in a pure SwiftUI app is annoying, but I don't think that was short sided. It's just iterative design.

At the start SwiftUI was something you could add to an existing UI/AppKit project, so individual parts could be rewritten. They've been building on top of that since. Refining the api and slowly letting you write more and more with just SwiftUI

[plagiarist]

The implementation seems to encourage that "leaf" views have to be aware of parent views, or what context they're in. I used to work with a guy who'd always say, "maybe I'm holding it wrong," that's how I feel about the navigation in SwiftUI. Maybe I need to see a clean example to get it.