I don't even fully understand why "cross-platform UI development" is such a holy grail. Is it that expensive to separate your business logic from UI and write the small UI layer in whatever the platform's "best practice" native language is? Is it that hard to find developers who know more than one programming language? With a lot of these frameworks and higher level abstractions, if you go off the toy-app happy path, you end up fighting the framework and tools more than you're writing your app anyway.
> Is it that expensive to separate your business logic from UI and write the small UI layer in whatever the platform's "best practice" native language is?
I mean... yes? There is a ton of incidental complexity (i.e. unrelated to the business domain) involved in creating nice user experiences. If dev salaries weren’t so high then sure, more companies would probably spend the money to repeat the same work across several platforms, but right now? No way.
That said, I still think I agree that you give up more than you gain by going cross platform, at least for now, but I totally get how companies look at how much it’s costs to hire and says “you know what? I’ll take a cross-platform compromise”
Not to mention the LARGE realm of internal tools where you need something functional as conveniently as possible and aren't trying to drive a consumer-product-level market-differentiated experience.
It also takes time to ensure the feature is developed for all platforms. Due to low usage you may not bother developing for that platform. Thus feature in one platform lag other.
I worked for a company where we did iOS release after very 3 android release coz android was 80% users and iOS 20%. Mind you this was a cross platform Iconic/Cordova app. Now think if we did native. iOS users would have to wait even longer
Companies are too efficient for that, even if dev salaries were cheaper they would still want to fund just one version and pocket the difference, and eventually market competition will make that the norm.
Not only that, but corporations are not everything. What about one and two person shops? It would really be nice to be able to develop a product without first having to invent the universe.
Counterexample: banks started with shitty cross-platform UI type apps, but those received low customer satisfaction figures so most of them have now switched over to native apps. A similar thing happened with Facebook.
Users are not knowledgable enough to know what technology was used to build a product, but many have repeatedly complained about non-native UIs.
Heck, Lotus Notes went from being a market leader to an also-ran and user complaints about UX to corporate IT departments definitely played a role in convincing those departments in switching away.
More recently, this also happened with many mobile apps made with cross platform/HTML5 toolkits. They got low review scores and low user engagement across many firms, prompting a switch to native.
It’s not just a “small UI layer” — there’s an entire stack that goes with it. Want to build iOS apps? Can’t do it on Windows or Linux; you have to buy a Mac, run macOS, learn that whole stack, install Xcode, figure that whole thing out, learn how the App Store works, including all of its rules and regulations. But that’s not all—you also have to figure a CI pipeline for that whole thing too.
Rinse and repeat for every platform.
That’s what makes the web beautiful: you write the app once and it mostly runs everywhere. You have to figure out the infrastructure I described above once and you’re done.
Or at least that’s how it use to be before the major platform players realized how lucrative it is to charge developers App Store fees.
> Is it that expensive to separate your business logic from UI and write the small UI layer
Not sure what apps you've built, but usually that business logic is the minority of the codebase. The rest of the stuff is boilerplate, like drawing boxes, describing layouts, handling events, managing state. All this has nothing to do with business logic.
Ideally, I want to write it once that I want a row of buttons what colors they have and what function should be called when the user clicks on it.
I did what you describe and extracted all the logic in a small component I manage and the result was very banal, extremely straight forward code with was essentially "business logic". The 90% rest was building the UI based on it.
Last major one I worked on that needed to be cross platform was a GPS navigator, which had massive functionality in C and C++ under the hood, called from the platform-specific UI/event handling code through Objective-C-to-C++ on iOS, through JNI on Android, and directly on PC native platforms. It worked pretty well. The ratio of platform-specific to platform-independent code was very small, so it was not like writing the app N separate times. Major engineering savings AND each platform's build had its own UI idioms that users of those platforms were accustomed to. Guess I never realized this was a controversial approach to take!
And write your shared business logic in what language? If it's a C library perhaps you could do this on iOS and Android, but how is that going to run in a browser?
I'm aware of things like the LLVM based C to JS compilers, but they're not really viable for anything non-trivial.
That's why a lot of shops are writing the same logic N times in N languages and frameworks. It can actually be easier than having to target something these wildly different platforms share.
If your business logic is in C - well you are in luck! Use emscripten to compile this to WASM and you can use it in the browser. This approach is very much viable. Large scale commercial web-applications like Figma are written in C++.
Well, if “viable” means “doable but really fiddly”.
C/C++ is fine on iOS (at least when interoperating with Obj-C, Swift is trickier).
C/C++ is “doable but really fiddly” on Android, same as web. There’s a compiler toolchain but not much IDE support, and you have to do all the JNI marshaling yourself.
So C/C++ is only barely usable for common cross-platform code, and yet it’s the best option. What other language are you going to use?
It’s kind of ridiculous, but that’s the way it is. Programming languages are all the same in principle, but in practice they don’t interoperate well and they can’t easily be used everywhere.
> and you have to do all the JNI marshaling yourself.
After 10 years of Android, while I understand the goal is to force developers not to write unsafe native code, Android team could have already provide better tooling.
However they have always behaved as the NDK was something they had to offer, not something they actually wanted us to use.
> but in practice they don’t interoperate well and they can’t easily be used everywhere.
...and yet, it's still much better than replicating the same code in different languages just to support different platforms.
The idea that a platform dictates the language to be used for creating applications on that platform has always been ridiculous, just because it was the status quo on the web for a bit over a decade doesn't mean it's a good idea that should be copied :/
I at least agree with this! It’s a big shame that the major mobile OS platforms bless only one or two languages for targeting their devices, and are at best neutral, at worst hostile to developing in other languages.
I'm not commenting on any other platforms, but I maintain a few C/WebAssembly libraries and they work exactly as expected without being unreasonably large. C-in-JS has been viable for a number of years now.
I realise it works, I just don’t think it’s really useful for what was asked for, a way to write common cross-platform business logic for a platform-specific UI.
Unless there are some great new tools I’m not aware of, C on WebAssembly seems about the same as C on Android. You can compile stuff just fine, and run it, but actually connecting it up to any substantial UI written in JS/Java is going to be incredibly tedious.
For a computation library with well-defined inputs and outputs, and that “just works” and doesn’t need any debugging in situ, it makes a lot of sense. But I think business logic by definition is going to need a much richer interaction with the UI, and that’s what makes it hard.
The interaction between C and Javascript offered by Emscripten is a lot better than JNI on Android. I wish the Android NDK would steal a few ideas from Emscripten, but all the Android teams at Google don't seem to be able to look outside the nice comfy bubble they've created for themselves.
With Emscripten, you can embed Javascript source code directly into the C code and then call the embedded JS function from the C side as well as C functions from inside Javascript.
In my case I usually debug the platform-agnostic code compiled natively in IDEs like Visual Studio or Xcode, and for the HTML5 specific code (which is just a few hundred lines) traditional "printf-debugging".
Fair enough, and I strongly agree with the general point about the need for a solid cross-platform framework either way.
I don't see why you couldn't write your entire business logic, state management, etc. in C or Rust and treat it effectively like a client-side server, but I've never used wasm in that way so I can't speak from experience there. Either way, I can certainly see how that would require some extra effort, and of course it would only really be useful for applications that don't offload most of their work to a server.
Generally speaking the "connecting it up" between c/wasm + js or C + java/kotlin on android can be completely automated with codegen. It's really not tedious at all.
you release feature X. The first person writes it for the web. The web version was easy, because the feature relied on URL deeplinking, which is nice and easy with browsers.
You then realize that Windows doesn't really offer such a concept as easily. You think about application URLs. That mostly works, but it takes a couple weeks for the Windows team to get it working.
You implement the feature over on Macs as well copying the Win strategy. But a recent Mac OS update causes a bunch of permission popups that mess with another thing. Now you're messing around with that, and your internal users are pissed (cuz they're all on Macbooks).
There is no Linux version, luckily.
I mean... OK, yeah, you still have to deal with platform differences even when using Electron. But you are in the same boat with like.... Slack, Discord, etc etc. You get _all_ that shared knowledge, a unified code base. And in theory you throw any of your engineers at the problem and they can try very hard googling "Electron [issue] windows".
I also bemoan the fact that _even Slack_, with its billions of dollars, didn't feel the need to have a native application. But I do get it, especially when there's a lot of pressure to ship.
While I realise you’re just providing an example, Windows has supported deep linking in one form or another since Windows 3.1 (DDE, specifically topics), but also HTTP-style application URLs (eg app://command?options=opts) ever since ActiveDesktop and WebView.
Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality.
By unifying the codebase, the team removed feature disparity between platforms and eliminated over half a million lines of code.
Google Pay also reports that their engineers are far more efficient, with a huge reduction in technical debt and unified release processes such as security reviews and experimentation across both iOS and Android.
That's very interesting in light of the facts that
1) This announcement seems to claim that Flutter 2 apps can be deployed as web apps as well as mobile apps, yet
2) This very morning I received an email from Google stating that pay.google.com is going away and the service can only be used via the mobile app going forward.
>Is it that expensive to separate your business logic from UI and write the small UI layer in whatever the platform's "best practice" native language is?
Yes.
>Is it that hard to find developers who know more than one programming language?
Working on an app that's running on... 6 different OSs/UI toolkits on last count, yeah, that "small UI layer" is costly. And yes, finding devs that know more than one language/one UI toolkit is hard. (Heck, for some UI toolkits, finding developers is hard period)
