> By writing code in a non-standard fashion, we took on overhead that we would have not had to worry about had we stayed with the widely used platform defaults. This overhead ended up being more expensive than just writing the code twice.
https://dropbox.tech/mobile/the-not-so-hidden-cost-of-sharin...
Plus what you're talking about there is the opposite of what I'm suggesting, you wrote 2 UIs with a shared C++ logic, I'm suggesting two native platform layers with hosted webviews.
Sadly I agree. However the blog post I linked describes their mobile strategy. Sorry about the confusion.
FWIW The desktop app now uses the strategy you suggest: native with many hosted webviews.
> what you're talking about there is the opposite of what I’m talking about
Sorry, skim read and missed that! See above comment re Dropbox desktop using your approach though.
You could make a minimal native app shell for each platform, with the most relevant integration points, and then host a native webview within that shell that shares its UI across platforms.
Not quite as nice as true native, not quite as fire-and-forget as Electron, but certainly more efficient and integrated than the latter and a lot more cross-platform than the former.
Would have been nice to have a real, cross-platform UI library that uses the native controls everywhere, kinda like what WxWidgets hoped to be. Unfortunately Microsoft in their push to make Windows desktop development into a Lovecraftian nightmare, made that all but impossible.