Native or Consistent

Avalonia, Java, Juce and others provide the “same” UI across platforms. (UI looks the same on every platform because the controls are drawn)

Xamarin, UNO, Xojo (in some cases) use native controls so the UI looks more “native”.

I can see pluses and minuses for both, what do you prefer for X-Plat apps?

1 Like

Always NATIVE… because that way you get consistent… nothing worse than having one app on your phone/pad/computer that looks alien compared to any others

plus, with NATIVE controls… should the OS change or the user updates their theme/skin, you app follows suit automagically

4 Likes

I’m with Dave here

IF I get to be THE ONLY APP that a device shows then I dont care - because my app IS the “standard” (and usually I’m also in charge of when / what OS updates etc happen)

But, at least on my mac, I have several java apps with UI’s and they stand out because they used older non-native UI toolkits
Now with JavaFX this is much better since it DOES use native controls way down deep
However side by side its still usually possible to tell which is a java app and which isnt
Sometimes the giveaway is behavioural and not cosmetics (Electron apps often have this characteristic)

1 Like

I know some people go to great lengths to make sure the “look” of their interface is consistent across all platforms, and TBH, most of the X-Plat software I buy and use seems to be done that way. I think it’s probably easier for instructions too if everything works the same way no matter what version you’re using.

You’re probably not familiar with these pieces of software, but they’re very popular in my world…
Reaper, Digital Mixing console Editors, Fractal Audio Editors, all look the same in Mac or Windows.

However, I tend to agree that folks that like one platform appreciate software that looks and works the same as they are used to.

No doubt there are specialty pieces of software that need very custom UI’s (ie/ a mixing board ) where there is not likely any “common” standard in other apps on that same platform to compare to

And those often do get to set their own standard as to how they should look and feel since its not Word, Excel or some other app that uses default standard control elements for the majority of its UI

But there are still things people “expect”
If you switch your mac to Dark Mode then the UI should switch accordingly (at least I’d expect that) So even though the entire UI might be quite unique there are behaviours people will expect - sometimes those can be hard to mimic properly

Since they do cater to users on both sides it makes sense they look similar regardless

I am going for “the same” (as you know :smile:)

Reason for this: development time (only one UI to develop), maintainability (again, only one UI to maintain) and costs (less time / less maintenance means less costs for the customer).

Note: I develop business software. In this area, the only thing that counts is functionality; the software should just do the job that it is designed for. Looks are not important.

2 Likes

‘Same’ here too. For our business apps, using native controls has no value at all. On the contrary, our users work on Windows at work and sometimes use Mac or Linux at home so they prefer that the software looks exactly the same, no matter their platform. For us, it has the added value to only have to make our video tutorials once and much easier for our support people too as everything behaves exactly the same. For bigger companies using our software, their in-house support people prefer this too.

For an ‘off-the-shelf’ product I can see why you would make the effort to use native controls but not for our business oriented software.

3 Likes

While I would say looks are definitely not AS important, IMO looks are still part of the perceived quality of the software.

In addition, IMO it matters if the app exhibits most of the expected UI behaviors for the platform or not (that is a training/expectations issue)

While both things matter significantly less for business software than for consumer software, they are not totally unimportant IMO.

(I have been writing apps for in-house use since the mid 80s)

  • Karen

I agree with Karen. functionality is #1… but if it looks like crap, it will be percieved as crap. So it if doesn’t look somewhat native to the platform, it won’t survive two minutes installed on my computer…

1 Like

Most inhouse software those days is web based …
(I build inhouse and general business software since mid nineties)

Of course.
But a unified or Web GUI doesn’t have to look like crap :wink:

1 Like

but web based software doesn’t count… as there is no “native” platform… since the platform is agnostic . I expect something in a brower to not match my native platform, but a desktop or mobile app designed for that platform should match that platform

Well, it looks like you prefer native (as you mentioned earlier).
Our opinions differ. No problem at all, as my customers agree with me (and they pay my bills).

If a customer wants native I tell him it costs more if he wants it to be cross platform. Normally that is enough to convince the customer. And if not, they pay more for native or we agree to make it native single platform.

2 Likes

Most inhouse software those days is web based …

Maybe in larger companies, and by those in the IT group that control the server (if the company even has one).

But that is a lot less so in small and or startup companies like the ones I worked at and do work in now. And certainly a lot less so for “citizen developers” like me…

My job description is and has always been as a chemist.
That said I written some LIMS and MRP type software as well data reduction/reporting for data being generated in the lab and even product labels and data sheets that go to customers. Software all used by others in the company and not just myself.

-Karen

In the ancient world of the first GUI OSes, when there were very few apps in the market and almost no tools to meke apps, the “native” feel was a thing.

This days is a completely different thing, most people are used to the drawn apps, for example, almost all the comercial antivirus software is in this category. Most of the apps that are part of the drivers, (gaminkg keyboards, mouses, video cards, sound cards, etc.) Most of the popular graphics apps like GIMP, Inkscape, the adobe suite, etc, etc.

for X-Plat apps I am with “the Same”, those can be themed to look more similar to the native ones or to be unique. Also you get rid of the “lowest common denominator” limitation that you have with “native” controls.

2 Likes

AFAIK, JavaFX controls are not native, even way down deep; they’re simply drawn to a scene graph in a way that simulates native controls (similarly to Qt) and can be styled via CSS and themes to resemble native controls (or not).

I think you’re thinking of SWT, which does wrap native controls. It might be a viable option, but it’s an open source project with no official connection to Java, and it’s been around for awhile and doesn’t seem to have much momentum.

The mere fact the controls are drawn doesn’t necessarily mean the UI has to look the same across platforms. Qt, Flutter, and others draw controls and yet they go to great lengths to style the controls, and in some cases customize their behavior, so they look and feel native, i.e., a MacOS or iOS app will look native, different from the native-looking Windows or Android version of the same app. (They also give you the option of using a standard look-and-feel that will be basically the same on every platform.)

Why not both?

Both would be the ideal choice
That way folks who want native controls can have them
Folks who want a UI that is identical across platforms can do that

I think the key here is that native should not require you develop the UI ins some other tool then wire it to your code in whatever fashion

TBH that is one of the big attractions that a tool like Xojo has
You develop the code & the UI in one tool
Is it perfect ? No
Does it expose every last detail of the native controls ? No - but there are ways to access the native control at runtime to tweak it IF needed
It often does opt for “lowest common denominator” in terms of whats exposed but it seems, in many ways, to be sufficient for a LOT of purposes

would it be possible for xojo to have indicator when compile or build to set native or consistent ??

our problem is when we show client the demostration on mac book and then install on windows machines and it does not look as nice