UI programming - and GUI toolkit programming - is all about breadth. There’s a ton of things a UI needs to do, but most of those things are straightforward to implement, and there’s usually a plethora of lower-level libraries to compose in any given area. So, it does take a lot of work to implement a UI (toolkit) but not much of it is a stumper. And, many areas of UI toolkit functionality can be ignored or have low-quality implementation for a long time. For example, a hobbyist writing their own UI toolkit can ignore accessibility, but still end up with something usable by the hobbyist. Or, the initial implementation can use only absolute layout. Or, the initial implementation can use only a single fixed-width bitmap ASCII font.

I didn't say easy, I said it's not too bad. Look at this toolkit for example https://github.com/yushroom/Fishgui. Once you have rendering (which nanovg handles), you just need some hierarchy, event handling, windowing and layout and you have a basic toolkit.

I like the control a lot, with Cocoa, I felt really constrained sometimes.

Now draw the rest of the owl!

A key point of a shared UI toolkit is that users can bring their knowledge from one app to another. A standard Cocoa table view or text view has tons of advanced behaviors: type select, keyboard shortcuts, etc. It's worth the user's time to learn these because they work in every app.

But apps where these don't work feel discordant and frustrating.

You can mimic native behaviors. But these are different between say browser and native cocoa apps anyway.

You won’t ever produce a perfect imitation. UIs based on third-party toolkits are always a pain, stuck in the uncanny valley. They look somewhat like they should, but have all sorts of quirks that break useability: text fields that don’t support standard shortcuts, weird layouts, wrong fonts, buttons that cannot be selected with the keyboard, etc.

It is much, much better to use Apple’s toolkits.

How many shortcuts are there realistically? 50?

That's not the problem, the problem is that I can define a system-wide shortcut from System Preferences and it really is system-wide... unless you don't use the native framework, in which case I'm out of luck.

There are an infinity of little things like this. macOS is powerfully integrated across the platform and you either play ball with it or you don't.

One that's pretty important is accessibility. You're leaving the blind, vision-impaired, and paralyzed users out in the cold, because macOS has a fairly complete system for all those users to make use of the operating system. But it won't work for an app that isn't native.

Probably around that by default, maybe a bit more: https://jblevins.org/log/kbd https://www.howtogeek.com/681662/35-mac-text-editing-keyboar...

But all of them need to work, along with system-wide custom ones.

Text substitution is also an issue.

This is the precise reason I hate web apps with a passion. I want every app on my machine to behave predictably and have a uniform look and feel, not for every UI designer to be able to produce their own unique snowflake without regard for consistency.

This is why many people are frustrated by web applications that do not mimic features they expect from native Cocoa apps.

A certain genre of apps, especially eg. digital audio workstations, manage to do this and also have a sizeable userbase. Ableton Live is an example here. It seems especially sensible if your design does actually have a bunch of controls you need custom rendering for.

Honestly, don't let these comments get you down. It's important to act strategically of course, so it doesn't make sense to over-invest in an idea succeeding. But it makes sense to do scoped experiments / proof-of-concepts. I don't think we're "done" with UI framework architecture design, people need to keep trying new things in the space. And I also don't think only Apple (eg. SwiftUI) and Google (eg. Flutter) are allowed to work on these things and we need to accept their gifts from above. Some times, a good quality here is almost not believing that something is too hard to do (while obviously also informing oneself about as much existing work there has been as possible to incorporate it into the experiments).

>you just need some hierarchy, event handling, windowing and layout and you have a basic toolkit.

Yeah. Once you add hierarchy, event handling, windowing, and layout to a rendering engine you pretty much have a basic toolkit.

Kind of like once you've hand built a cpu, gpu, logic board, hard drive, and so on, on top of 3d-printing a case, you have a basic PC.

This is a basic toolkit in like 3000 loc https://github.com/yushroom/Fishgui. It uses nanovg.

That sounds like an insane amount of work to me to end up with something objectively worse from a usability standpoint. But to each their own.

It's debatable how much worse usability is.

And what of accessibility?

text input (right to left, left to right, compose chars) ?

tree views (with non-textual cells)?

nested menus?

file selection dialog?

You should wrap native file dialogs. Text input direction isn't that big of a deal if your rendering supports it. Tree views are somewhat tricky but not that much harder than list views.