4 ms·

> 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

> 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?

PaulDavisThe1st 4y ago
I don't even know that this question means. Is Photoshop a cross-platform application? Protools? Chrome?
- scarface74 4y ago
  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.
  - PaulDavisThe1st 4y ago
    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.
    - scarface74 4y ago
      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.
      - mroche 4y ago
        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.
        scarface74 4y ago
        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?

PaulDavisThe1st 4y ago

I don't even know that this question means. Is Photoshop a cross-platform application? Protools? Chrome?

scarface74 4y ago
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.
- PaulDavisThe1st 4y ago
  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.
  - scarface74 4y ago
    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.
    - mroche 4y ago
      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.
      - scarface74 4y ago
        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?