Hacker News Reader

> There are not multiple "native toolkits" on Windows or macOS.

This is just not true on Windows. What is native Windows these days? Win32? WPF? WinUI? Even if your view is that Win32 is the one true native toolkit, MS alone produces multiple abstractions over Win32 like Windows Forms or MFC.

Even when I was programming on Windows in the mid 200x’s there were 9 or 10 ways to represent a “string” depending on which framework you were using and you had to convert between them depending on the API you needed to call.

https://learn.microsoft.com/en-us/cpp/text/how-to-convert-be...

Honestly, if someone produced a book that said how to write win32 applications in a way portable enough that current distributions of wine would not have to do any special work to make them work, I would very strongly consider that option.

My definition works like this:

is there an API layer on which (a) everything else is based and (b) people sometimes use directly for app development?

  macOS: Cocoa/Quartz - yes and yes

  windows: win32 - yes and yes

  linux: X Window - yes, no (though of course Wayland is changing the "yes" a bit)
       GTK, Qt, WxWidgets, FLTK etc - no, yes

But that's my point, WPF (the Vista-7 era primary toolkit), is not based on Win32. Neither is WinUI (the 8-11 era primary toolkit) calling Win32 or WPF.

Win32 is mostly used for legacy apps, you'll find some random usages still like pre-Win11 notepad or the services configuration menu.

WPF is the primary UI framework of Windows Vista/7 and still the framework which the majority of the OS is in for Windows 8/8.1. It doesn't call Win32, it implements its own widgets, something that would most often be exposed in differences in high-dpi support. These do generally try to align with the Win32 widgets from that Windows version visually, but there's plenty of discrepencies.

WinUI is the new framework which isn't even shipped with the OS as of the latest versions, but even if you're using the built in verison it's not calling Win32 widgets or WPF widgets, it's once again implemented a new set. The lower level APIs share some similarities with WPF as it basically started as a fork of WPF modified to implement Windows 8 UI patterns, but neither WinUI or WPF are implemented in terms of the other.

Thank you for a brief update on the situation on Windows. I didn't know all that, and now I know a bit of it.

> So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position.

Can you name a single cross-platform application that is indistinguishable from a native application?

I don't even know that this question means.

Is Photoshop a cross-platform application? Protools? Chrome?

Photoshop has a shit ton of Cocoa and before that Carbon on the Mac. While the processing engine may be cross platform. The UI is mostly “native”.

And do you really want to bring up the battery killing Chrome as a great cross platform app?

Safari is much more efficient and ironically from reports, so is Microsoft’s Chromium based browser.

I wasn't trying to name "great" cross-platform apps. The question was "what is a cross platform app".

Is Chrome or Firefox a cross-platform app or not, regardless of how they shitty they may or may not be?

> Photoshop has a shit ton of Cocoa and before that Carbon on the Mac. While the processing engine may be cross platform. The UI is mostly “native”.

Every GUI application that runs on macOS has a "shit ton of Cocoa" inside it. There's essentially no other way to create a GUI app for macOS, regardless of the toolkit you use. There's a separate question like "are the buttons drawn by Cocoa, or app-specific, or toolkit specific?" but I regard that as a separate question.

The discussion is about cross platform “frameworks” versus writing apps using the native frameworks.

Adobe and Microsoft basically use native frameworks for most of their apps.

It’s the difference between most of Office and Teams and VSCode.

On the flip side, nearly all groups in the VFX industry author their apps with Qt and deliver across Linux, macOS, and Windows. The "native" side of things is where people usually end up having the most debate, typically around appearance. VFX and creative apps tend to choose to look and behave consistently across platforms within their own context, rather than trying to utilize the human interface guidelines (HIG) of each respective platform. The standard place where this differs is usually on the file picker component.

That being said, even with these toolkits you can make applications that are themed and behave similar enough to the native runtimes that most users wouldn't notice. But that's a developer's choice to do so, or to completely customize the app for themselves and the UX they're looking to deliver.

To me the concept of cross-platform desktop applications is pretty interesting, as when you include the Linux ecosystem into the fray it's not macOS, Windows, and Linux (Qt/GTK), but rather macOS, Windows, GNOME (libadwaita), KDE (KDE Frameworks), etc etc. And that is significantly more difficult to support "native" for, even if the latter are using GTK and Qt under the hood of their respective platforms. Apple can make first party applications that abide exclusively by their HIG, and the same with Microsoft, but asking vendors targetting multiple platforms to do so and essentially support multiple versions of their apps to achieve "true native" when "seemingly" or "close-to" native via the toolkits widgets, built in theming capabilities, and backend abstractions are available can be a bit of a tall ask.

So if it’s “themed” to look “native”, what happens when the vendor chooses to change the theme of the native widgets? Do the themed widgets automatically support the user’s localization and internationalization preferences? Does it support the accessibility affordances that you could get for free when you use the native toolkit?

> Apple can make first party applications that abide exclusively by their HIG, and the same with Microsoft, but asking vendors targetting multiple platforms to do so and essentially support multiple versions of their apps to achieve "true native" when "seemingly" or "close-to" native via the toolkits widgets, built in theming capabilities, and backend abstractions are available can be a bit of a tall ask.

And could that be part of the reason that Microsoft and Adobe - both with a multi decade history of writing cross platform apps that use the native frameworks of the target platform are really the only two software companies that are really still successful making desktop consumer/prosumer software?

I can only speak to the land of DAWs:

The biggest DAW of the last 20 years: Ableton Live (Windows/macOS)

The next biggest DAW of the last 20 years: Reaper (Windows/macOS/Linux)

The most rapidly expanding DAW right now: Bitwig (Windows/macOS/Linux)

The most deliriously loved DAW: FL Studio (Windows/macOS)

Most widely used DAW by paid professionals: Digidesign ProTools (Windows/macOS)

Other DAWs not made by Adobe or Microsoft (neither of whom make an actual DAW): every single other DAW, most of which run on Windows & macOS, except Logic, which was cross-platform until Apple bought it.

But I could make a guess at other worlds too:

Biggest splash in the video editing world: DaVinci Resolve (Windows/macOS/Linux)

Most widely used 3D/animation: Blender (Windows/macOS/Linux)

Not really sure what you're talking about claiming that Adobe & Microsoft are the only two software companies that are really still successfully making desktop consumer/prosumer software, unless you are deliberarely excluding actual "pro" software. In which case ... I just don't really care.

I’m considering massively successful as two companies that have literally been selling versions of the same software for Mac and PC software for over 35 years.

Another poster cited this as far as how much “native” code is in PhotoShop

> But Russell still has MacApp to contend with — it most recently flared up during the Mac Cocoa conversion. Millions of lines of code had to be changed, and for a time the entire team was engaged on the project.

And let’s talk about ProTools. It is even in a worse position than Adobe with respect to being able to use cross platform frameworks. The backend leverages Mac and Windows specific APIs

https://www.pro-tools-expert.com/production-expert-1/is-ther...

It specifically leverages Core Audio on the Mac.

> same software for Mac and PC software for over 35 years

You couldn't even do what contemporary DAWs do in a native application until the late 1990s. Even in the early 2000s, ProTools relied in a "DSP Farm" installed on the PCI bus to provide enough compute power. So the timeline for this particular sort of software only extends back 25 years or so.

CoreAudio is not a "front-end" toolkit/framework/library.

You cannot do audio or MIDI I/O on any platform without ultimately talking to the platform APIs for that (not totally dissimilar to how all GUI toolkits ultimately having to talk to some low level drawing/event API).

The backend of every DAW, audio editor, audio player etc. uses platform-specific APIs, either directly via their own platform-specific code, or via a wrapper such as JUCE, or RtAudio (JUCE is extremely popular these days, though it is also a large cross-platform GUI toolkit that is increasingly dominated startup audio software development).

None of that has anything to do with GUI toolkits, or front ends, or native experience, or UI or UX or any of the things we've been talking about.

> None of that has anything to do with GUI toolkits, or front ends, or native experience, or UI or UX or any of the things we've been talking about.

This was the basis for my comment. It's not possible escape native APIs, but what differs will be how you consume them. You can either choose to use them directly (true native) or you can use a toolkit that abstracts the various backends. This provides you a single development layer across all platforms while the toolkit itself is what handles the access to the underlying platform native APIs. So it's not on you the vendor to keep up with what's changing at the OS layer, but the toolkit.

Obviously there are trade offs with all methods, and they can be mixed and matched as needed. For example, Qt is not a GUI toolkit like GTK, but a platform toolkit providing APIs for a whole host of functionality beyond visual representation. Does that mean you need to use Qt's multimedia package to handle video or such? Absolutely not, but for the features it provides that are shared across platforms it can make things easier to develop (this is purely for example purposes, I've never authored anything with Qt Multimedia).

> CoreAudio is not a "front-end" toolkit/framework/library

What difference does it make? You still can’t have a “write once run anywhere”. You still have to have a dedicated team to develop each app.

Do web developers generally create their own audio subsystems or use platform native APIs directly? No, those aspects are handled by the browser which does the heavy lifting for them, allowing for a write-once-run-anywhere{-that's-supported} experience. The cross-platform toolkits (like Qt, JUCE, etc) do the same thing; they talk to the platform APIs on your behalf. What kind of expertise or team structure you require to build your application for various platforms really depends on what level of the stack you want to author against.

> I don't understand this claim at all. Qt (or GTK) let's you "escape out" to the "native" toolkit on Windows or macOS as needed.

You're kind of fighting against Qt or GTK when you do that. Qt and GTK have their own widgets. React Native is more of a framework that uses native toolkits to begin with, so it starts out with much better alignment with platform expectations, and has better interoperability with platform features.

> There are not multiple "native toolkits" on Windows or macOS.

I'm confused by this comment. I don't know what kind of point you are trying to make here, or what you are responding to.

> So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position.

Yeah, let's dial the "it's a position" condescension back one or two notches.

When I said, "Different platforms are just slightly too different from each other to make it work well," the "it" refers to cross-platform toolkits like GTK and Qt, which provide their own widgets. This explains why so many people use Electron and just embed a web browser (let's say "fuck it" and make one UI inside a big window), or choose to use something like React Native. Maybe I'm drawing too fine a line here--I think of Qt and GTK as cross-platform toolkits, I think of React Native as a framework without the toolkit parts, and I think of Electron as some kind of cross-platform box that you can something inside. I'd rather not talk about the definition of "toolkit" or "framework" because the definitions are not material.

Qt is a big honking mess, and GTK is worse. Speaking as someone who has written apps using both, and fixed UI problems in people's open-source Qt and GTK projects.

> This explains why so many people use Electron and just embed a web browser

I would wager there are 100x the number of Qt/GTK apps than there are electron apps. That number could go up or down by an order of magnitude, and the older widget-based toolkits would still be ahead. So ... I don't think that citing numbers of developers doing X or Y is helpful here.

> React Native is more of a framework that uses native toolkits to begin with, so it starts out with much better alignment with platform expectations

More similar to WxWidgets then, which uses native widgets but wraps them in lowest common denominator API. For one reason or another WxWidgets hasn't been as successful as one might expect.

Anyway, as I've noted elsewhere in this thread, the majority of creative apps (including Logic) barely use any of the native toolkit within their main windows. Almost all DAWs, drawing programs and image editors just treat their windows as a big 2D drawing surface, and do their thing without regard for UI/UX widgets or rules designed around productivity/business/system utility apps. The "native" aspect kicks in only when they interact with the rest of the desktop environment, and they vary quite a bit in how native they go (they also keep changing this; Logic has gone back and forth with using the native file browser vs. an app-specific one several times over its life, and in different contexts within the app).

This also has implications for the extent to which Qt/GTK/etc. toolkits impact the UX. If someone writes a widget-heavy app, then the toolkit design & implementation will have a strong impact. If the widgets are limited to some toolbar at the top, it doesn't really make a lot of difference as long as the devs get system tray/notification right, and don't screw with window management.

> I would wager there are 100x the number of Qt/GTK apps than there are electron apps. That number could go up or down by an order of magnitude, and the older widget-based toolkits would still be ahead. So ... I don't think that citing numbers of developers doing X or Y is helpful here.

If making the comparison is not helpful, then why make the comparison in the first place? I was just observing that "many" developers made the choice to use Electron; I am not trying to compare numbers of developers here.

> More similar to WxWidgets then, which uses native widgets but wraps them in lowest common denominator API. For one reason or another WxWidgets hasn't been as successful as one might expect.

Yeah, although I think WxWidgets abstracts too much.

Maybe I can frame it this way--I'm not really against cross-platform toolkits in the first place, and I'm not complaining about cross-platform toolkits on a conceptual level. I do think that apps made with cross-platform toolkits often have UX problems and I think part of the reason is because the underlying platforms are too different. Those differences are both (edit: fix) technical differences and differences of conventions / expectations.

React Native seems to have less abstraction. Maybe that's just my subjective thoughts on it.

> Anyway, as I've noted elsewhere in this thread, the majority of creative apps (including Logic) barely use any of the native toolkit within their main windows.

Sure, if you focus narrowly on the main content of the main window, you'll see less of the native toolkit being used. But that's only one part of the app, and it's still built to match platform expectations, in a way that is not easily abstracted out by cross-platform toolkits.

Logic is a bit of a funny example because Apple has a separate set of "pro" widgets they use for their creative apps, like Logic and Final Cut. You can see that, for example, Logic has a decent number of .nib files, which means that it's making use of the native toolkit, even if it's not everywhere.

> or choose to use something like React Native

Finally took a look, and this appears to be mobile only. Certainly covers one definition of cross-platform, but a little different than the other toolkits we've discussed.

Nope, React Native does support targeting Windows and macOS (and, though with less love, Linux) and even Web, tvOS, Android TV, and more. It’s just that iOS and Android are the only official Meta-maintained ones.

The macOS and Windows implementations are solid, being maintained by Microsoft, and are even used in small corners of Microsoft Word and other flagship apps.

Then their website needs some serious revision.

Some further digging does reveal the non-mobile stuff but sheesh, that is so easy to miss. Incredibly obvious to conclude that it would not be relevant. And indeed, even where they mention the macOS & Windows targets, no mention of Linux.

Are you really advocating using a cross platform framework that isn’t “maintained”?

Doesn’t that argue one of the issues with using any cross platform framework?