In a lot of cases the answer is “who is the intended audience”
If it includes people who rely on assistive technologies then you may need to worry about native UI as that is often part of what they support where non-native UI’s may not
So if you’re writing software for the US government or agencies that rely on funding you may be subject to the Americans with Disabilities Act that puts certain requirements on you for supporting assistive tech
Native isnt JUST about how it looks
No
Since they dont create a fully native UI on any platform - there are controls that a user might use that are naive only on some platforms and dont exist on others
And then you get “Listbox” which isnt native on any
And, as I noted above, their implementations dont support any assistive tech regardless of what the underlying OS supports
I have a Windows machine with only a 43” touch screen attached and Windows & the apps on it are all very usable on it
All native UI’s
There are also Xojo apps that run on it and they are deliberately NOT all native controls for presentation purposes
But the components that are native controls work just fine on a touch screen
I know that Xojo has not really native controls. And also that native isn’t only how it looks. Native is also the functionalit behind. FileChooser is one of the best examples. The fundamental reason while I was always believing it’s better to use the native control.
But on the other side there is many potential also in not native controls. Never mind, I wanted to know how the others are handling this
I have iPAD Pro 12.9 and IPAD Air 13” and wrote native Apps. They are in function with the native GUI. I have also Apps written with CN1. They are also running. Means: the GUI is running and the native stuff seams also to run. This under Windows, Linux, macOS, Android and iOS. So I woud also disagree.
Visually you and I, as sighted persons, probably wont notice much as long as things function the way WE expect because we can see
For a blind user that might not be the case and any reliance on a screen reader etc might not work with a non-native UI (some might actually have alternative means to hook into such assistive technologies - some do not)
Web apps for instance tend to NOT support much in terms of assistive tech
But it IS getting better
Whether Electron & other such frameworks enable this I cant say
Java does it and CN1 too. Don’t forget that CN1 is native compiled with X-Code for iOS. It is no problem. The next part is: there are Braille Drivers for Java Swing and JavaFX, partially for Seift UI and partially for Windows UI. Means; especially for blind people support is there.
The other side is: people which are blind are not able to handle a UI like the windows one or iOS one. They need much more assistance. Therefore Braille interfaces are a good way to open the world for them. But that’s a total different story.
JavaScript based Systems are mostly also able to get readed. While all of them ore based on text and not on bitmaps the techical possibility is there at least.
But I don’t want a flaming discussion about it. I wanna know how others thinking about.I know what Java GUI can do or not. I want to know thy people use only native GUI or why not. There are reasons for it I want to understand. I want to know if it is worth of it to build a native GUI package for JavaFX for example.
And yes, there is anyhow a chance using SWT technology to have native UI interface under Windows, Mac and Linux OS. Eclipse SWT uses native components fopr the GUI and looks so not only native but uses native UI elements.
If people want to have this as standard for example I have to look for my own experience if it is worth of it to implement. Not more and not less.
If they get cross compiled in a way they DO - great !
But then its NOT a non-native UI is it ?
Its compiled INTO native controls via whatever build mechanism they have
Screen readers for instance may rely on the native control support for assistive tech
That way you only need ONE reader and not something built into EVERY app
Thats one area where native may be a better option
Another can be that using the native SDK you immediately get whatever UI changes are introduced - like Liquid Glass support (or moving from one version of macOS to another, or the same for Windows)
Again a non-native UI might not adapt
Although Apple sometimes makes that a pain in the rear but in the past you certainly have not had to do anything & your app just adopted the new UI look
LG requires a recompile against the newer SDK - but not a rewrite
And IF you are making apps where any/all of these considerations don’t matter then sure make whatever you want and use whatever UI SDK you want
Sometimes I am happy that I do not have so many Customers which want native UI. I would not want to get that jobs. Programming native means: Swift UI and Swift for macOS. Windows with its native GUI on C++ would be a good option. And for Linux….GTK has no native but there are solutions builded on GTK bindings. Android with Kotlin and iOS with Swift and SwiftUI. But then there would not be any kind of cross platform.
For one of our packages I asked the customers if they would pay more if we would provide native GUI? The answer was simply on all sites: No, there is no interest. Cause that are many customers and many of them are apple users I thought there will be the chance that they would say: okay, it is more expensive cause it needs more hours in development so we would pay that (example was per Workplace license 99,- Euro with a Software price of 2990,- Euro per seat). But there was simply no interest. The other question I was asking: if I am adding new functionality and the software would be +99,- Euro per seat. They said yes (96%). That was a statement. So I would say that there is an interest may be but…And this but I want to learn why it is there. That’s the reason for this Thread.
Native UI may work nicely on a touchscreen but would you want a car infotainment screen or ATM screen look like a Windows or macOS application? Usually you would need to run on a kiosk mode anyway and hardware accelerated Weston/kmsdrm is a lot nicer alternative.
No
Single purpose devices can have their own UI because they dont have to fit into any ecosystem
Which is kind of my clients case - its not a general Windows app that anyone can download & install & use
So its mostly custom UI
But there are aspects of it for administrative users that are a simple Windows UI using native controls
Kotlin Multiplatform mobile does this. You write the UI for iOS and one for Android as native UI. So you have the guarantee that you can use all functionalities of the native gui.
Back in the old days when Jobs was around and Apple was known for it’s attention to detail, I would have said that a Native GUI helps your app stick out from the quick, poor Windows ports, which results in more confidence and more sales.
However since the macOS started its downhill trend of looking like garbage and the Mac App Store became the place for the clone armies, Native GUI doesn’t matter so much any more in sales.
I agree with Norman that using a Native GUI gives your app more accessibility and other bells and whistles, but as we’ve seen with Tahoe, it can actually make your application harder to use and more ugly. I’ve seen a number of developers who’re deliberately not adding Liquid Glass UI support because they feel it is detrimental to usability.
Liquid glass is something apple wants so nobody has the usability in his apps. But that this makes apps a bit ugly: they did not realized. In my eyes liquid glass makes it not better than it was. But it was the “BIG THING” for their release.
both carplay and android auto are designed around the respective mobile platforms, but…many of the apps are awful to use, while the vehicle is in motion. this was actually one of the things i was specifically thinking about in my OP. the HIG for both AA and CP are written like the apps are only supposed to be used while the vehicle is stationary:
the controls are too small for a vehicle that is in motion, jostling the driver’s fingers as the driver is trying to manipulate the display.
the controls are in dumb positions, relative to the driver.
manipulating the controls or navigating between apps forces the driver to become distracted because it takes so many touches, all over the screen, to make anything happen.
@npalardy hit on something that i had not thought about - disabled users. that’s a great point, but i tend to already lean in that direction in my designs, anyway, with larger controls, fewer controls, larger text, more contrast. - but screen readers are something i had not considered.
no matter which way you lean, no matter which tools you use, make great design great again.
Actually car play is one thing I prefer to the built in Sync system - at least in my Bronco Sport
Not that the UI in the Bronco Sport is horrid
Just the UI in CarPlay is that bit nicer
The controls are a bit larger in CP than in the Sync system so they are easier to hit when the vehicle is in motion
Now I dont know WHAT sync is written in but the UI I could easily see being WPF or something like that. It certainly looks like that.
And both are WAY nicer than whats in my wife’s Durango
I want my buttons and dials back. I can use them without looking at a screen. These screens are a real danger, and just as bad as/ equal to using a phone while driving.
I think it was the insurance institute of America or something like that did a study between touch screens & real buttons and indeed people are more accurate while operating a vehicle with real buttons
The Sync set up is a hybrid - some things like volume still have physical buttons as do temperature controls & venting
And some things are only accessible on the touch screen - some only while the ca Is stationary
In those cases IF the car is moving the function is either disabled or only via voice commands
In our medical device usability studies we found out that it is only possible with real buttons. They are the most effective situation for the user. This black text on white screen as a button is not clear enough. And so automotive industry will have the same results. As you can see they act also so.
