"Highest common denominator" doesn't make much sense in this context - it's functionally equivalent to lowest common denominator.
You want N different implementations, 1 per platform?
You think the cross-platform toolkits could be better? Do you have an explanation for why they are not?
I chose a platform because the platform and the apps meet my set of priorities.
As far as how that affects Linux users, even if I did prefer Linux as a developer platform, why make it my daily driver instead of running it in a VM or with something like WSL2?
When the app is not there (e.g. a DAW), I merely choose to spend a few decades of my life developing it, thus destroying my ability to do what I originally wanted to :)
As for why would you prefer Linux as the daily driver, that would depend a lot on what you were doing/needed. It is a technically superior in almost every respect (not every, but close). It has better audio latency performance, should that matter, better bandwidth for most things, is generally more customizable to your own preferences (though obviously other platforms may be customizable enough). Upgrades and maintainance is generally simpler and smoother. I like being in control of my technology in a way that Microsoft and Apple increasingly do not allow me to be.
I'm not saying that you have to care about any of that. I do, that's all.
"I chose a platform because the platform and the apps meet my set of priorities."
You listed a wonderful set of priorities which put the philosophy and a certain kind of usability at the top. GP seems to value day-to-day UI/UX within the desktop.
So question for you, with regards to cross-platform, insofar as you value it as a goal, is that to help spread the user base of libre software?
Essentially, yes. As a developer, I'd like my work to be available to as many people as possible, and I'm not dogmatic enough to insist that they choose to use Linux or another libre OS as their platform. If I want users of other platforms to be able to use my work, I need to somehow do cross-platform development. That means either creating my own cross-platform toolkit, or using an existing one.
As a side note, I'd also say that cross-platform development turns out to be great for finding bugs and design flaws in your software. Exposing it to other compilers, linkers and UI/UX design models has always been a positive experiences, even if often frustrating.
And what good is this supposed “technical superiority” if it doesn’t have any end use benefit? Does it integrate with my other hardware seamlessly like my headphones that switch automatically between my phone, computer and watch? I can start an SMS message thread on my phone and finish on my computer or if I’m sitting at my computer and my phone rings, I answer it from my computer? Does it give me 16 hours of battery life?
And the Mac is kind of known to be great for audio editing if you’re not aware and has first rate software.
I haven’t heard anyone say that the ARM based Mac are poor performers
> I like being in control of my technology in a way that Microsoft and Apple increasingly do not allow me to be.
Would I rather be “in control” of hardware that sounds like a 747 when you do something even mildly intensive with piss poor battery life by modern standards or have a laptop that I can actually work with on my lap and have 16 hour battery life?
My AMD system has better audio performance than any Apple system I could buy (and I can even run Mojave on it, with better $-per-cpu-cycle than anything Apple would sell me), despite Apple systems indeed having great audio subsystems.
I rarely use headphones, but when I do they are studio quality ones that do not use bluetooth, and are fed via my studio gear, not random consumer devices.
Look, I get that different users have different needs. I'm not trying to persuade you not to use Apple products. I just happen to think that the focus on "how good is this for my day to day needs" can obscure a more important long term truth. Farmers have been discovering this with John Deere for the last few years, another company that makes incredibly great hardware that is totally what their users need. It just turns out the Deere's model of buyer lock-in via repair control is now causing conflicts for those same users.
When releasing software, macOS is a small tertiary concern for me at best, behind Linux (for myself), Windows and mobile platforms. So if you care about app availability, you indirectly care about cross-platform toolkits.
Recently I've looked at apps for running a "flat owners' association" in the Czech Republic. The general feeling I got was that maybe one was at least approaching intuitive and good looking design. Using a cross-platform UI toolkit wouldn't hurt these apps one bit.
Besides, the only ones that supported macOS at all were web apps, the epitome of non-native. So if a non-programmer wants to manage such an association on a Mac, their only options are cross-platform apps or a spreadsheet, proving my point.
Because there aren't enough macs in the world for people to make apps just for you, it seems.
> why make it my daily driver instead of running it in a VM or with something like WSL2?
Why run a fast OS when I can run the same fast OS within a slow VM and a bunch of other limitations?
Different platforms are just slightly too different from each other to make it work well. So you end up with a bunch of cross-platform apps which are built on things like Electron. You more or less reject platform expectations for how apps should work, how they should look, or how they interact with other apps / other parts of the system.
You end up with stuff like Spotify or Discord.
Thing is--if I'm getting work done with this app, if I get paid for working with it, I'm going to pay for a better experience. Instead of using GIMP, I'll use Procreate, Photoshop, Pixelmator, whatever. Maybe I'll use Notepad++ or BBEdit. Maybe I'll buy Pro Tools despite its cost, or maybe I'll buy a Mac just so I can use Logic.
It is costly to just reimplement your UI for multiple platforms, but that's where the "closed ecosystems" come in. React Native is kind of a compromise between the Qt-style approach (cross-platform UX) and the native approach. You're given a framework which works with multiple native toolkits, and you can have a mix of cross-platform UI code and platform-specific UI code.
"Somewhere, deep down under the streets of Photoshop, down where the mole people live, is a little framework called "MacApp." It's a remnant from the very first versions, a fragment of foundation. MacApp originally let Photoshop communicate with the underlying operating system, which was then Mac OS 6.0.3."
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.
There are not multiple "native toolkits" on Windows or macOS.
> Different platforms are just slightly too different from each other to make it work well.
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.
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.
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, yesWin32 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.
https://learn.microsoft.com/en-us/cpp/text/how-to-convert-be...
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.
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.
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.
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.
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.
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.
Doesn’t that argue one of the issues with using any cross platform framework?
Can you name a single cross-platform application that is indistinguishable from a native application?
Is Photoshop a cross-platform application? Protools? Chrome?
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.
Adobe and Microsoft basically use native frameworks for most of their apps.
It’s the difference between most of Office and Teams and VSCode.
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.
> 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?
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.
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.
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.
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).
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.
If you're suggesting WebGPU, you're really suggesting a drawing technology, not a GUI toolkit.
If the Apple and MS a11y frameworks were not so distinct from one another, wrapping them in a cross-platform layer would be much easier. But they couldn't be bothered, largely because they both have enough users whose priorities match your own: are the apps on the platform good enough for them. The incentives to standardize a11y at the API level across OS platforms is a tiny fraction of the incentive to standardize e.g. WebGPU.
Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix, has a 16 hour battery life and I can get great polished native apps?
And then there are the people who spend day in, day out in programs like Photoshop, InDesign, Pro Tools, etc.
There's a lesson there, though I'm not sure what it is.
But how much of the GUI is actually cross platform? Adobe famously used Apple’s Carbon API and was very upset that it wasn’t ported to 64 bit. There is a lot of Cocoa in both products.
Microsoft use to brag that they had more Mac developers than Apple did.
I find the idea that when Photoshop or Protools wants to open a dialog with a button, the developer creates two functions, one for Windows and one for macOS, completely unbelievable.
There is almost without doubt some level of in-house cross-platform toolkit in place. It may not go as far as, say, Qt tries to, and it may differ in design philosophy from other similar toolkits, but they are not writing twice the code every time they have do something in the GUI.
If I'm wrong, HN is the place to find out.
The GUI code wants to open a dialog. The way to do that differs dramatically depending on whether you're opening a dialog on one of the (many) Windows native GUI APIs, or Cocoa (or even Linux). Are you proposing that when the, ahem, domain logic in Photoshop requires opening a dialog, that the developers write 2 or 3 or 4 different implementations at the call site?
I would bet that they do not. Adobe has wrapped "dialog creation" (along with hundreds of other GUI abstractions) in their own cross-platform layer, and their GUI code calls that. This is the same thing done by pretty much any company developing for more than one platform.
The approaches can differ a lot. For example, consider Reaper (another DAW). Its lead developer picked a tiny subset of the win32 API that he wanted to be able to use, and implemented that for macOS and Linux/X Window. Then he uses the (partial) win32 API for the entire GUI (with higher level stuff built on top of it).
This is still backwards. The domain logic doesn’t open a dialog anymore than a back end API opens a dialog on a web app or mobile app. The front end gathers whatever information it needs to call the backend code along with an event saying when it’s done “call this”.
The back end logic is usually naive to the presentation layer. Even in GUI apps it’s usually event based where the backend just sends an event saying “I’m done” and the front end registers an asynchronous function for a call back and when the function is called a dialog box shows up saying “done”.
What is the code at the call site that opens the dialog? WinUI? Cocoa? I am extremely doubtful that it is either. Ergo .. cross-platform "toolkit", albeit in-house.
The front end already knows the inputs that the backend needs (in this case tte engine). When you click on a menu, it usually brings up another view without ever talking to the backend. I’m sure some companies have a framework that can automatically generate a native view based on an API definition.
Even your standard CRUD app you usually have a set of API developers and they may publish their API using something like the OpenAPI specification and then your web developers, Android developers, iOS developers create interfaces to call the API.
> What is the code at the call site that opens the dialog? WinUI? Cocoa?
This is fundamentally opposite of how development is done in a GUI event driven architecture. The back end is never the “call site” that tells the front end to “bring up a dialog box” The front end calls the back end.
Even if it’s not a user generated action, the front end still defines the interfaces and subscribed to an event.
In your example:
1. The back end developer (the engine creator) writes code that is usually cross platform if that’s the aim and required certain inputs and raises events.
2. The front end developer creates menus and defines views that are shown when the menu item is selected. The view allows the user to enter the necessary information.
3. The front end then sends all of the information to the backend and probably some type of call back function that the back end should call when it’s done or in the case of error.
The back end is never the “call site” nor does it know anything about the front end.
This is a standard “onion architecture”
I was the 2nd employee at Amazon. For the last 23 years, I've been the lead developer of Ardour, a cross-platform DAW. I also wrote JACK, the only cross-platform inter-application audio/MIDI routing system, but since that's a system that doesn't require a GUI, it's not really relevant. It did win me an award in the early 2000s though.
What you're describing sounds to me like a process out of 1980s "application development" blended with web stuff blended with contemporary "rapid application development" aka "define the GUI with a GUI tool, and it automatically generates code".
Ardour has a fully MVC architecture, with a backend that knows nothing about any of the multiple frontends that can exist for it (GUI, MIDI, OSC/UDP, OSC/WebSocket). We do not use RAD tools, there is no generated code.
I asked you a simple question about what the code looks like in an Adobe or Microsoft app that runs on two platforms, the code that opens a dialog to collect information from the user. Nothing in my question makes any reference to tbe backend. All I can guess is that you think that all GUIs are defined via RAD-ish tools. All I can do is to try to use your language: what is it that a front-end developer is doing when they "define views that are shown when the menu item is selected" ?
In that case, you know that the call site is never “telling the front end to bring up a dialog box”
> I was the 2nd employee at Amazon
Well I’m the millionth something employee at Amazon :). But as far as generating a view. I’m thinking of something like the home grown (publicly discussed) tools that AWS has so that when the service team introduced a new API, we have tools that can automatically generate SDKs in all of the supported languages and the CLI. Why couldn’t a custom tool create native views? Hey
Again we know for a fact that Adobe has “millions of lines of native Cocoa”. Why is it so hard for you to believe that the front end is hand coded by native developers?
Even at one 200 person company I use to work for we had dedicated web, Android, IOS and desktop developers.
But even when you aren’t using RAD tools, you are still defining your views some kind of way with XML, config files or something. BTW, I’ve been a continuous hands on ”programmer” (we didn’t call ourselves developers back then) since the mid 80s when I was a hobbyist 65C02.
Photoshop was originally written using MacApp, so it must have gone through some extensive, extensive changes to get its first Windows version.
But even then the reason I prefer my Mac is that it integrates with my personal hardware. I do log in to my personal account on my work Mac But I am careful about what gets synced.
Depends on the apps you are using; what's the Mac equivalent of Emacs? How about Meld?
Yeah, this is a bit of a leading question; you can get great polished native non-xplatform apps for Macs but if you limit yourself to that category then the Mac is no longer as useful as a mid-range Windows/Linux laptop.
If you're going to insist on using only non-xplatform native apps when on Mac, you're in a niche (image/video/sound editing, maybe?)
BTW: What kind of Mac laptop do you have that you get 16 hours of battery life? My 5mo M1 barely gets 4 hours when using only video-calling, Goland, Chrome and some terminals.
In over a year of using a Mac as a daily driver, I've yet to use one non-xplatform native Mac application. so I am curious about what you non-xplatform native Mac app you are using.
Hard to say without knowing what’s running in the terminals, but I’d say Chrome/Electron (and potentially, its use of non-HW-accelerated codecs in video chat) is the likely culprit here. Not the same machine, but my M1 Pro MBP 16” can pretty easily swing a full work day flipping between Xcode and Android Studio so long as I’m using Safari for browsing.
Because your real Unix ships with certifiably ancient GNU tools that haven't been updated since they switched to GPLv3 licences, and are a massive security risk.
It doesn't even have a real package manager, which leads to things like this : https://news.ycombinator.com/item?id=35581375