> it's super easy (I did myself alone many times) to have a single codebase in Qt

I’ve worked in Qt apps on and off through my career.

I do not want Qt apps any more than I want Electron apps.

The solution is native apps using native platform tools, or one of the mature cross-platform toolkits.

neverartful 13 hours ago | parent | next [-]

Conceptually, I agree with you. Unfortunately, the waters have been muddied with respect to native platform tools. Honest questions:

Windows - Win32 (C API) or MFC (C++) or WinForms (C#) or WPF or ...? macOS - Cocoa/AppKit in ObjC or Swift/AppKit? Linux - Qt (C++) or Gtk 2 or Gtk 3 or Gtk 4?

▲

ptx a day ago | parent | prev [-]

Which cross-platform toolkits are more mature than Qt?

▲

Aurornis a day ago | parent [-]

Mature was probably not the best word. The modern desktop UI toolkits produce a better UX to me.

Qt feels too locked in to old decisions that were the right choice at the time, but desktops and mobile have changed so much that it always feels like a clash of old and new.

▲

dagmx a day ago | parent [-]

You can make Qt look however you want. The point is that it will give you native UI by default (for the most part and excluding QML)

That native UI will be faster than Electron and most other retained UI toolkits and will be just as capable of creating whatever your subjective view of “modern UI” is.

▲

zapzupnz a day ago | parent [-]

I'm still waiting for a single Qt-based app on macOS that feels like a macOS app. They look more like some Windows 95-era app wearing the Aqua skin peeled off the carcass of some slightly older-and-definitely-not-current version of macOS.

Don't confuse UI and UX. You can make Qt have the right UI, you can't make it have the right UX.

▲

hobo123 20 hours ago | parent | next [-]

This is also why electron and other frameworks really devalue MacOS. Back in the day anything not built with Cocoa felt off, there was a difference in usability.

Now we take it for granted, and Mac apps feel as good or bad as everywhere else.

▲

dagmx 18 hours ago | parent | prev [-]

Qt will look like AppKit for the most part minus having exact the widget types as AppKit.

The person who made a Qt app may be designing it based off of cross platform UX but maybe you should follow your own advice and not conflate things.

You can quite easilymake a native UI and UX with Qt. You can also make things feel very non native via AppKit too.

Your argument has very little to do with the toolkit and more to do with the developers choices of what UX they prefer to design.

▲

dijit 17 hours ago | parent [-]

I'm with zapzupnz here.

I haven't seen what you describe, even if it's theoretically possible. I'd really love to be shown an example.

I'm not saying it can't happen, and in fact, if it existed I wouldn't have noticed (I mean, the point is that you think it's native, so I wouldn't have noticed..) but I can't think of an example and I would love to see one.

▲

dagmx 14 hours ago | parent [-]

MuseCore is Qt/QML and would look fine alongside Apple’s pro apps which are AppKit based

https://blog.landr.com/musescore-ultimate-gude/

Audacity’s new UI also looks not too far off from Logic

https://youtu.be/BTQymidLYIM?si=_zoMdjlhDNsp53zH

I’m not saying it’ll be perfect, there’s still the issue of being designed cross platform. But it’s a far cry from being a Windows 95 UI with an aqua skin.

One of the bigger issues is that they haven’t yet adopted the latest macOS 26/27 UI paradigms but the nice thing with Qt is that it’s really easy to wrap AppKit views into the mix as you need.

▲

zapzupnz 6 hours ago | parent [-]

> But it's a far cry from being a Windows 95 UI with an aqua skin

Ah, but that's the problem, macOS UI isn't skin deep. Behind the looks, there are behaviours like:

- supporting the system-wide default Cocoa menus and menu-modifying behaviours like changing the shortcuts via System Settings rather than some in-app settings window

- support the Services menu in every single right-click menu, the one that's populated by AppleScripts, Automator services, and Shortcuts provided by the system, installed apps, and the user

- heck, even without the Services menu, supporting system-wide speech, spell-checking, and translation built into every native Cocoa text field

- for those of us who like it, Siri AI suggestions in text fields

- supporting macOS' accessibility settings like Dynamic Type, Large Type, proper support for VoiceOver in all widgets, etc. which come automatically to Cocoa widgets but require extra effort that's never really seen in Qt apps on the Mac

- supporting transitioning between light and dark mode when the system setting changes and not leaving random artefacts behind after the change

There's way more than just these examples but this is the point: looking like macOS isn't enough. It's feeling like macOS that's the trick and Qt apps always stand out as just a little foreign.

So people who make apps with Qt don't design for the Mac interface because it's far too much hassle to build all of that stuff in, if they even know that they have to.

——————————

I'm not convinced by a comparison with the Pro apps, either. Those, on both sides, are custom-designed UI. Yes, Apple's Pro apps use the system toolkit but they aren't your typical Mac app; anything that looks like them has to go out of its way to look like them. It's not like Qt gives "Pro app" look for free.

(And even if it did, that still doesn't mean the app would get all those behaviours I talked about before)

But even in the first image of the Musescore interface, I spot something foreign to Mac: a toolbar with a drag handle. Mac apps don't have that. Mac apps have NSToolbar, where the items are customisable in a standard way that every app adopts.

▲

dagmx 4 hours ago | parent [-]

You’re shifting goalposts in ways that not even AppKit follows. It was originally whether it can feel native and it can.

- Yes Qt doesn’t get the default context menu items but it’s trivial to add them. Meanwhile you can also override them in AppKit to look non standard.

- The original response was about whether Qt can provide modern looking and native looking apps. You’ve now shifted your goalpost from modern looking to being exactly what AppKit or SwiftUI does.

- Qt by default has basic accessibility support on macOS the same way AppKit does. It’s not always perfect but it’s not as dire as you make it out to be.

- Qt6 also supports theme changes fine.

But again, none of this is the premise of the original argument I was replying to. Your argument is all over the place because you then also claim that AppKit can make non native looking UIs but we should just ignore those while disregarding that you can also trivially make Qt look macOS like.

The point isn’t that Qt apps will look and behave 100% identical, the point is you can make them do so. But cross platform apps will always be somewhat alien on any platform unless you’re actually designing for each platform.

That’s not really inherent to the UI framework that prevents it.

	▲	zapzupnz 2 hours ago \| parent [-]
		> You're shifting goalposts Where? > It was originally whether it can feel native Yes, and feeling native includes behaviours, not just looks. > and it can. Except it doesn't. Still waiting on a single example of a proper Mac-feeling app written with Qt, looks and behaviour included. > It's trivial to add them If you're comparing to using a native toolkit, 'trivial' should mean 'for free' given that Qt already presents the developer with the option to use the native toolkit. There's nothing trivial about integrating a proper Cocoa-provided NSToolbar into a Qt app. It's downright impossible to make a QToolBar both look and behave like NSToolbar. > The original response was about whether Qt can provide modern looking and native looking apps Yes, and then I mentioned that looking like a native app isn't the end of the story. The conversation moved on but, contrary to the assertion that the goalposts shifted (it didn't, the goalpost was always about the better UX of native toolkits), all I did was add detail as to what desktop UI toolkits provide that Qt doesn't. Even then, AppKit is as old as Mac OS X. Hardly native. And in all that time, Qt never caught up. > It's not as dire as you make it out to be No, it actually is. So much of it just straight up doesn't work, things that AppKit provides for free without any effort at all. One would expect the native styling to be able to help with it but it simply doesn't. > You've now shifted your goalpost from modern looking to being exactly what AppKit or SwiftUI does Actually, I'll quote myself: "I'm still waiting for a single Qt-based app on macOS that feels like a macOS app" — no emphasis added, I even italicised 'feels' in my first reply. Feeling native is more than just looks. It's behaviours. I'm repeating myself because even GP mentioned "better UX", not "better UI". The experience includes how things work. Your assertion was "You can make Qt look however you want. The point is that it will give you native UI by default" — it was actually you who decided the discussion was all about looks, not about experience. > Qt by default has basic accessibility support on macOS thce same way AppKit does Not a single Qt app on my system supports Large Text. Simply doesn't do anything when I hold Cmd and move my pointer over things. > It's not always perfect Agreed that no accessibility system ever is, particularly if developers don't test it, but… > but it's not as dire as you make it out to be. Spoken like somebody who doesn't rely on accessibility features. Not just use, rely. > Qt6 also supports theme changes fine. My computer would say no to that, with random bits of the UI not changing colour at all when I change the system light/dark mode. It was such a problem that one of the most-used cross-platform apps written with Qt, OBS Studio, completely disabled the native theme for its theming inconsistencies. > But none of this is the premise of the original argument I was replying to. Okay, so that just means you're having a new discussion with me, then. Besides which, GP's premise to which you replied was "Qt feels too locked in to old decisions that were the right choice at the time". I don't see that I'm contradicting that. With late-90s to early-2000s design decisions (like toolbars that tear off with drag handles, like Office 2001/2003 and Visual Studio) the cornerstone of what each widget is designed to do and how its appearance should be, how it should behave, and how these things interconnect with other aspects of the UI system, those "old decisions" really do get in the way of the "better UX" that GP described. Like I said, Qt apps feel like they're wearing a Mac skin over the bones of a Windows 95 program (okay, maybe more like 2000 or XP, but that's still almost 30 years old). Mac OS X has been out and supported all the things I've talked about in Cocoa and Carbon for as long and yet Qt still remains a poor facsimile on the Mac all this time later. The experience is just as GP said, a clash of old and new. Probably less noticeable on Windows and Linux but sticks out like a sore thumb. I continue to await any suggestion of a proper native-like app written in Qt that looks AND behaves like a modern Mac app. And look, I don't mean for this to be an argument. It's got the shape of one but I really do enjoy discussing this with you. I guess, at the end of the day, that the idea that something might look acceptable on a system is sufficient to say that its toolkit is up to the job is not one that leads to the best user experience.