From a few years ago, Twitter and Facebook were famous examples. They pushed so hard to try and build their apps using web technology but kept running into performance issues (thanks to infinite scrolling). After spending fuck knows how much they finally admitted that maybe native components are better.

But this is Facebook, who have so much resources they can afford to build their own version of PHP three times over. I just don't understand why they put so much effort into trying to fit a square peg into a round hole instead of just going with native development.

But, I'm not an insider, I don't know the thought processes behind it. Long story short, IMO people overestimate how complex it is to build multiple native apps in parallel.

I agree, although there are now more platforms to deal with than back in the days when it was just Mac and Windows: add iOS, Android, desktop web, mobile web.

I think it also helps when it's easy to share code between platforms, which again, used to be easier when you were just targeting the desktop (just use C or C++).

Now it's a bit harder because there are no great languages that span all platforms easily without a bit of hacking. Most languages are managed and memory-safe now; that's a good thing, but it makes them more heavyweight and less portable. They generally want to drag in their own frameworks (e.g. Flutter, React Native) rather than letting you put your own UI layer on top.

Platform fragmentation exists since ever.

I was thinking mainly of the 90s and early 2000s, I guess, and for desktop apps where the main platform of interest was Windows, followed by a long tail of Mac, X-Windows, BeOS, etc... All those platforms could “easily” (i.e. with effort, but no rocket science required) be handled by a single C/C++ codebase with platform-specific #ifdefs.

I think the equivalent for today’s platforms would have to be Javascript. Unlike the C/C++ approach, you lose direct access to platform features.

I think in the case of something like Facebook, the sheer complexity of their product drives a need for a singular code base. It would slow their engineering organization to a halt to ensure feature parity with largely seperate code bases.

This problem is already solved by virtualized lists available in any decent framework. Why people don't use it is beyond me.

- implementation of the platform specific layer, supporting all the quirks of the target platform

- testing setup

- build system (some platforms have a lot of weird details to take in account)

The cost-benefit can be ok or terrible depending on the project. But for example for games, where you will draw your own UI anyway, that’s very common, and as far as I know that’s also what Microsoft is doing for their Office applications: common core in C++, then platform specific C#/Java/Objectice-C UIs.

It doesn't really matter what else is going on in your app, if that work can be done more efficiently to produce a more consistent result, then that's the decision you make.

Often with frameworks like React Native or Flutter, it means inconsistent UX bugs on each platform. Why do you think Facebook and Instagram and Airbnb abandoned RN in all their primary interfaces?

The "more efficient" implementation might lead to consistency across platforms, but people are pretty tied to the phones they have. Things like dropped frames, slow scrolling, UI locks, all have a subtle effect on the user whether they can point it out or not, and you're more likely to have those problems by diving in to these frameworks without understanding the underlying platforms.

This isn't argument to share no code whatsoever. But so many people who immediately turn to these frameworks either want to ship something at the expense of UX/design, their app is so small that it doesn't matter, or they have no idea what they're getting into.

If we know so much about what they expect, why is it still hard?

I wonder if all the trend chasing is really just making busy work and getting in the way of truly standardized and dumb simple building of software.

A solution used by plenty of commercial desktop software as we moved from Assembly as main application language for desktop apps during the 16 bit days.

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.

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

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.

Yeah, that's true. I'm looking forwards to React Native (AFAIK it uses the native JS engine + native toolkits) and libui.

I'm also hoping for declarative UI frameworks like SwiftUI so that the underlying framework/runtime can generate the appropriate UI for the exact target platform.

This may seem like a good idea, but it's not. What you will get is a leaky, lowest common denominator API that will break on each new OS version.

1. You want to support N native platforms. 2. Each of these platforms has it's own way of doing this, bugs, etc. 3. Each of these platforms is being actively developed. 4. There are differences between those platforms. One doesn't have guassian blur, the other one doesn't have right-to-left languages.

I'm working with C++/Qt/QML/Javascript. No need to maintain 5 codebases.

Just a single codebase compiles to at least 9 platforms: Linux, Windows, macOS, iOS, Android, *BSD, Raspberry, QNX and WebAssembly.

If you want an app that has platform semantics on every major platform then you need separate code bases. If you want an app that has the same semantics on every platform then you go with a cross-platform toolkit.

What's not true? You just agreed with my statement. ¯\_(ツ)_/¯

That was my statement. You are saying it's not true. All the upvotes suggest some would say that. Therefore my statement is true.

I'm not sure why you're so confused here. This isn't at all applicable to what you are saying. You are talking about writing an app once and having one code base, which is exactly the opposite of what I was talking about. You have constructed a straw man and called it not true.

So probably React Native's approach (the approach itself, not React Native) is a really good idea, where you can:

1. Sharing code if you don't like re-writing n times. 2. Not sharing code if you want to have different native stuff for different platforms. 3. Mix 1 and 2 at any percentage as you wish. Typically reuse all the business logic, and separate view components.

I've never finished a React Native app without native code. I've done a few now and I've come to believe it's not worth even trying to avoid it and sometimes worthwhile to look for places where a little native module can yield performance or UI wins. React Native is the glue or orchestration and it is, to me, extremely good glue.

I haven't seen many people beyond the tutorial level suggest otherwise. It provides a common structure (which is enormously useful), and some quick consistency wins for simple stuff like your About Us screen.