Most apps that try to be cross platform just use a UI toolkit that acts as a cross platform compatability layer. Qt, GTK, Swing, WxWidgets and Tk all fit the bill. The result is that the app doesn't look good or integrate especially deeply into any platform, except sometimes with the platform the the developers personally use.
There are few exceptions to this rule. One is Sublime Text 2+ which is built on Qt. Without any customization, its theme looks OK, but doesn't match the design language of any platform, and its integration with its host platform is non-existant, everything happens within the sublime text window (no notifications or system tray/menubar widgets, no quick-view previews in Finder or Nautilus, etc). It's possible to improve integration by intstalling a custom theme which lets the user override a lot of the UI design, including the margins and padding, and plugins are written in python and can access a lot of host platform features.
If you want a native experience, you have to write a native app. You can share your business logic by linking to the same C++ code or in the future maybe by using react native and sharing the same non-view code. But your UI-layer has to be tailored specifically to the host platform in order to look good.
It's not that there's not yet a sufficiently good cross-platform library; it's that an Android app and an iOS app are different! They're structured differently! And if you try to use an x-platform library, you're going to end up with an iOS-app-that-runs-on-Android, or an Android-app-that-runs-on-iOS, or a this-app-doesn't-feel-right-anywhere.
My approach varies based on the application, but in general one of two things end up happening: either the majority of the processing gets pushed onto a server with a well-defined REST API, or the processing gets put in a C++ library that gets linked everywhere (with JNI shims, ctypes shims, whatever's needed to load it in the appropriate environment).
This approach does a few things: it ensures that you've got a UI that fits every platform, it improves code quality (you can't add a chunk of business logic in your view handler), and it makes porting so much easier.
I also think that standing on the shoulders of bootstrap and material design (like materializecss) is a better place to start where users will be cross platform than trying to look native everywhere... not to mention that native looks different every other OS release. Hell, look at MS Office from version to version, they break most of their own rules. A relatively clean, usable design is more important than getting everything precisely native looking everywhere.
As primarily a user of mobile apps I would mind. A web app experience is at the mercy of the network I happen to be connected to. In addition, as a user, the "build once, run anywhere" feature of web apps is a disadvantage since it often means that apps are written with the lowest common denominator in mind and don't quite blend in with the look and feel of either major mobile OS.
That's one of many things that web apps have been fixing. It's entirely possible to write an offline-capable web app.
> In addition, as a user, the "build once, run anywhere" feature of web apps is a disadvantage since it often means that apps are written with the lowest common denominator in mind and don't quite blend in with the look and feel of either major mobile OS.
They do, however, look like web apps everywhere, and if you primarily use web apps, you'll feel right at home.
> It's entirely possible to write an offline-capable web app.
Then we need a means of letting it have just enough network access to be useful but not enough to exploit the rest of your system, bearing in mind the discussion of WebRTC going on at the moment.
However, web apps also allow organizations to write once for many platforms in a much more seamless way than most cross-platform native toolkits I've seen. It's the same reason that desktop Java was in vogue for a little while: you only have to write one UI, and you can run it from a HTTP connection with almost no local permissions. Of course, this was (and still is) a security nightmare, but browsers now do a pretty good job of sandboxing individual code blobs, and also do a pretty good job of abstracting away the native UI. Web apps also provide low or zero installation overhead (low friction to getting a user onboarded/working/monetized/whatever).
It would be nice to see some progressive enhancement folks address how to resolve these pain points on the native side, rather than just saying web shouldn't be like native.