Agreed. Mixing business logic and UI works in simple applications, prototypes, or applications intended to ever work with one platform and UI paradigm. Outside of that, you're supposed to keep your "business logic" and UI separate (isn't this exactly why people invented MVC?).

Maintaining "5 different native UI applications" should involve one codebase with the whole internal logic, and 5 separate UI layers mediating between that logic and the platform it's being run on (including UI). It should not involve rewriting the same thing 5 times.

A lot of mobile apps are almost entirely UI...

An UI without logic is an useless app.

Often you can offload the business logic to the backend. That way you don’t have to implement it multiple times for each platform and you can change it “immediately” even if users don’t update their apps.

In such cases that same backend can send an XML (or JSON if you will) DSL payload that generates such UIs on the fly using the native widgets.

Pretty easy to create such framework in something like C++ or having a scripting language that drives the native UI widgets, something like JavaScript.

The 90s called, they want their UI engineer back.

UI these days is often more complex than the underlying logic itself. App logic became, to me, even secondary. Most of those issues are solved problems (databases, sql, rest, xml, json) and are mindnumbingly stupid and boring to implement. Save data record.. query data record.. validate data record, yeah, yeah, really complex.

A good fancy UI however... good luck.

You don’t want to write the predominate amount of app logic in C++. I’ve been there. The portability isn’t worth it.