Same on the Mac: If you want to build a Mac application, your best bet will be AppKit or SwiftUI and using system controls. And when the OS updates your application will either update with it, or need only minor tweaks and a rebuild to look good.
Same on the Mac: If you want to build a Mac application, your best bet will be AppKit or SwiftUI and using system controls. And when the OS updates your application will either update with it, or need only minor tweaks and a rebuild to look good.
There are exceptions, for very rich dense UI, for UIs that need to be cross-platform, but if you're writing a Windows app, it should look and feel like a Windows app.
Even Microsoft struggles with that.
That’s not exceptional at all. That’s completely normal requirements that are probably in the majority.
Does Microsoft themselves build their apps this way?
You need consistency in the icons, layouts and concepts, but you don't need every widget to look exactly the same on every platform.
With the exception of games try to use the native GUI. It’s the best choice most of the time.
Is your app as large and important as the OS of the device (Chrome/facebook/etc...) you should probably have similar language across devices.
Is your app very large but not that large? (Slack/teams come to mind) I think you can go either way.
If you are smaller than that (hint: you are) then you should comply with the design language of the platform, even if that means somewhat large changes such as moving buttons from the left to the right. The likelihood that users are constantly using your app on a iphone and android is really low.
I’d still like to see them try to match a little, but they’re specialized enough I get that may be a better path.
Chrome? Facebook? Slack? Teams? No.
I’m not saying things need to look like MyFirstWin32App built with VB6 in 20 minutes.
But use the system controls and conventions. Custom colors and layouts can be fine. But if you want to make your own UI toolkit then make your own OS too and leave my computer alone.
No app is more important than the OS, and certainly not Facebook (which has no business being an app in the first place). I made a choice when I got the OS, and I like developers respecting it and not chase the fad of the day with poor approximations of the native widgets (text fields that do not support standard shortcuts, buttons that do not behave as they should, labels that do not support accessibility features, the list could go on). Even huge apps like Photoshop or Office get this wrong everywhere.
I definitely agree on the default (use the native toolkit), but there are no applications big enough to get their own behaviour. Open Source or hobby applications get a pass if the UI is a bit wonky, but that’s about it.
I'm not sure anyone could really answer this question considering how fast Microsoft's various silos pinball between UI conventions. All of them are (I would hope) based on various iterations of their own internal tooling, but looking from Windows 7 to 8, 10, and then 11, you get such stark differences in UI language that you feel like you're looking at competing products.
That being said, I would personally very much prefer apps that are built to mimic the system they are a part of. One of the worst sins of that one, IMO, being iTunes on Windows which has always been and continues to be a flaming dumpster fire for a number of reasons, but most especially it's UI. It is a Mac app that is parked in Windows. It looks like a Mac app, it operates like a Mac app, it's UI conventions are that of the Mac, with the one major difference being they stuffed the window controls in the window in an incredibly slapdash way to account for Windows not having the system bar.
But yeah, for any marketing people here, I have not once nor will I ever give a single molecule of a shit about your brand identity. Make your software good. Ideally make it mesh with the system it's in. I couldn't fucking care less what color everything is.
Gone are the days of my friend accidentally having his volume cranked when he inserted the Red Alert 2 disc, not knowing it would blast out "WARINING! Military Software Detected!"
> Documentation is poor.
This is the first I heard about SwiftUI. Maybe I am mixed up and docs are excellent for Swift, but not SwiftUI?The documentation was absolutely maddening.. Half the time the Apple docs referred to a previous version. “Do this thing in XCode” often included screenshots of UIs that don’t exist in the current version of XCode. Examples I found on Stackoverflow or random blogs were usually no longer applicable.
It felt like magic when it worked, all those VStack HStack nestings, but the annoyance of finding my way there made me seriously doubt whether I’d build a big app with SwifUI, especially if I wasn’t working alone.
> It felt like magic when it worked, all those VStack HStack nestings
I know the feeling from Qt. I think Gtk and many other GUI toolkits use the equivalent of VStack and HStack to make resizable GUIs. Some GUI toolkits try to avoid this problem by using a grid layout, but it is more rare.EDIT
> made me seriously doubt whether I’d build a big app with SwiftUI
From your experience, what GUI toolkit would you prefer? And, it would help to know what is your target UI platform.Today I was making a list of reasons/excuses for using Material Design on Mac… which I guess would make some people mad, but it might work for an enterprise product.
That said I did do a fair bit of my own theming. The Flutter Material widgets are actually pretty customizable and I'm not a big fan of vanilla Material.
I’m not in a position to give anyone advice, but I’d love to find SwiftUI but cross-platform and usable from anything other than XCode (well maybe not Ed…) and native GUI and a pony.
For my product I need to support Mac, Windows and eventually iOS/iPadOS. For prototypes iOS is enough. I don’t mind learning new languages for this, but ideally there would be some advantage in knowing the language itself. I’ve been looking at lots of frameworks over the past month.
The most tempting thing so far is Flutter, but I have nagging doubts: because it’s not native UI, I worry about that being a no-go for some large customer down the road, and also about alienating power users. I looked at React Native but it’s not very good for desktop yet as far as I could tell (and the demo app from the documentation doesn’t work, which is a bad sign). Which is too bad because I was impressed with Expo, if I just needed phones I’d probably use that. I looked at Avalonia but it has the opposite problem.
Today I’m looking at Tauri for the Nth time: at least I could improve my Rust, and it seems to have momentum. Doing the UI in a web view is kinda sad, though, after trying SwiftUI.
Just building multiple apps is not realistic, I’m a solo dev and want to get this to market in my lifetime, and it only makes sense if I have both Mac and Windows.
Very happy to hear recommendations from people who have done this!
I'm not convinced many users care that much about this though. They spend most of their day using apps that don't use native controls and I think they're all pretty used to it by now.
I prototyped a bunch of different desktop toolkits and I think that today Flutter is by far the most polished and mature. I've had overall a very positive experience using it for my music app:
The threat of Google canceling it is real though. I suppose if that happens I'll switch to Tauri or just give up on Windows and Android and do SwiftUI. My experiences with SwiftUI to this point have not been very positive though.
Kotlin Multiplatform might also be an option at some point but it doesn't seem that close today. Unfortunately it seems like none of the os vendors are making their desktop APIs a priority these days.
Yeah the Google risk... seems like they came out strong in support of Flutter at their last dev conference, but at the same time it does _not_ look like they're using it for their main apps.
And yes I’d feel more confident in Flutter if Google was dogfooding it a lot more.
> If you really want native look and feel then really your only choice is to use the native toolkits.
What about Qt?Edit: and fully static linking. Might be a meg or so.