We're way past that in the mobile world, where both Google, Facebook, and other top dogs use non-native cross platform frameworks and looks (e.g. Material UI).
- Facebook doesn't use standard share sheets or web views. So if you're viewing an article, you can't use reader mode and you lose the (considerable) power of share sheets to do things like sending an article to another app or take an action on it.
- Gsuite doesn't register left swipe as back even though 99% of apps on iOS do. Icons for common actions are subtly different and make you double-take while you understand what they do. Accessibility options like larger text do not work, so if you're vision impaired good luck trying to figure out what you're looking at. And there's a ton of other quirks that have existed over the years including scaling to new resolutions/ipads, problematic text selection, performance, etc. It's not as bad as it used to be, but it's still not a pleasure to use Gsuite or any material design on iOS.
While many apps may use cross-platform frameworks solely for saving developer/designer time, the bigs use them for an additional strategic purpose that is detrimental to users.
- Google wants you to be familiar with their apps regardless of platform, so that its easier to get you to switch to Android or Chromebooks.
- Facebook wants to keep you in the app as long as possible, limit social sharing outside of their app, and spy on your browsing activity, so they add friction and don't use modern iOS web views that prevent that.
I wouldn't take cues from the bigs and just assume because they do it, it's the best course of action.
For us, we want to use the web stack so our stuff works across all platforms. So we use Cordova. We realize that over 90% of users just want to use the main interface and not some fancy OS feature. All our effort goes into making the product rock solid stable, engaging and easy to use. We aren’t actually interested in making it feel exactly like a native iOS or Android app.
Looking at the last 30 years of software development, it's pretty clear that users don't care very much.
"My app is a snowflake and needs a custom design language and UI." You're vim or Photoshop or AutoCAD or Excel: you're targeting dedicated users who are prepared to invest in learning a specialized UI. Fair enough.
But if you're not one of these highly professional apps, then custom control just makes the app less predictable, harder to use, and often inaccessible for users with disabilities. Not good.
Nothing much. Some of the most downloaded and bought apps (desktop and mobile) have horrible custom UIs. As long as the app has the crucial functionality, few care. And I'm talking for average users.
As for pros? Well, vim and Emacs are DOS style apps (well, in that they use curses and totally un-native GUI paradigms), and they're still strong.
UI concerns of that level only matter when apps otherwise have marginal utility and small other differences with competitors.
A framework for mobile uses custom UIs and everyone loses their minds?
2. Even web apps often have similar idioms and patterns to their UI that they've settled on. It's their own patterns that are different from desktop OS, it's basically another category.
3. Most web apps are used on desktop, not mobile. On mobile, it's mostly native apps that are used. So they're not substitutes.
This needs some citation
My expectations are different with mobile apps. If I'm spending some time to find the app on the app store (and maybe pay for it) and giving the app a place and a storage on my phone, I'm expecting from the app to be polished and give me pleasant experience.
Consider the humble popup button. A user may open the menu via touch, or with a mouse click, or tab to it and open it with spacebar, or via accessibility support, or via scripting support. Once the menu is open, the user may choose to select an item via touch, or trackpad, or key equivalent, or arrow keys and return, or accessibility, or scripting...
When the control is obviously normal, all of these interaction modes are available. If it's something custom, then probably only a few work and I don't want to subject myself to the frustrations of figuring out which one.
Native UI controls allow the user to exercise their built-up vocabulary.
> I'd say that, if someone puts enough attention into it, custom design / controls are probably mostly superior to the native UI, in terms of UX.
Broadly false, but true in highly specialized apps where the investment in custom flows is worth it. (vim, Photoshop, etc). If you're building one of these apps, by all means, think deeply about a specialized interaction vocabulary. But if your app isn't designed to be absolutely central to a specialized workflow, PLEASE leverage the ecosystem and use the native stuff.
> Not to mention how often people want something different and fancy over "boring" bland look of native controls
This doesn't actually happen.
Then using the native wrappers, like wxWidgets is often cumbersome to create customized control, and if you do you end up with some platform specific version (not end of the world, but pretty much why not use the OS toolkit directly). Also any wrapper soon or later suffers from "leaky abstraction" - where you hide things behind interfaces, but can't hide different performance characteristics, and getting the current line in a log dialog might just kill you, because underneath it might be scanning all '\n', '\r' until your cursor position.
This is hinted at where I say "Google, Facebook, _and other top dogs_", and "_e.g._ Material UI" -- emphasis mine.