The first point in the article is the hardest one: Selecting a tech stack, specifically the shared code component that holds the business logic and interfaces with network and storage I/O.
Tools like Flutter and React Native are pretty good at sharing UI code but typically an app is much more than just UI. You need to store data locally, interface with an API over the network, (de)serialize API responses etc. And using these tools locks you into their specific UI paradigm.
I think the "next big thing" in cross-platform development is a "shared-core" layer below Flutter/RN that takes care of all I/O abstracting over platform-primitives and exposes a nice async API to the UI layer. I've seen a couple implementations of this, typically in a systems language like C/C++/Rust but all implementations I've seen were custom from-scratch setups with their own build systems and FFI-binding generators. Very complex beasts, especially if building SSL support is included.
Ideally I would like to see some kind of "batteries-included" project/framework allows me to write the shared-core completely independent of the UI. With a build system that produces libraries and bindings ready to be consumed by any UI layer. A jar for Android/JavaFX/Swing apps, a framework for iOS/MacOS apps, a sharedlib+headers for C/C++/Rust cli tools or GTK/QT, a WASM library for web.
With "batteries included" I mean common stuff most apps need like JSON/protobuf (de)serialization, HTTP Client with SSL, define high-level API services (like Retrofit), file/prefs storage, caching, maybe even sqlite or other higher level storage. This way we could build our shared-core completely headless and use various UI frameworks on top of it, without being limited to just one UI framework.
I like this the common core direction much better for cross platform, but even what you suggest is too low level imo. Consider networking, your suggestion is to target only libc capabilities and build SSL+HTTP support from scratch. This is a ridiculous approach when there are excellent higher level APIs available on the platform. It's actively harmful because it bloats the resulting binary, increases the attack surface(out of date statically compiled SSL libraries for example), and integrates poorly with the host OS.
A good common core solution would be built with Rust and integrate directly with each platform's highest level C libraries i.e. CFNetworking on iOS, fetch via WASM on the web, and w/e Android provides. Further, I think the best cross platform apps would be built by embracing this approach and keeping the UI native. Sadly, most investment in cross platform is going in the direction of Flutter, i.e. throw away the entire native UI Kit in favour of poor imitations in Vulkan, Metal, et.al.
I totally agree with you about SSL. That's what I meant with abstracting I/O on top of platform-primitives.
Similar to how the Reqwest crate in Rust-land uses fetch on WASM and something else for other platforms. For the developer the API to define requests remains the same.
Flutter/Dart also does something similar in its http packages. I would like to see the same thing but decoupled from the UI framework.
edit: Rust Cargo and Kotlin multi-platform Gradle tooling are heading in the right direction. Both have support for defining a common interface with platform-specific implementations and good support for building against various target platforms.
I don't know where Rust or Kotlin are heading, but C/WASM and Dart are already there today.
I use Zig for the C/WASM part, it does cross compilation out of box. It's also a C compiler. It has built-in libc for Windows, macOS and Linux, and built-in wasi-libc.
Flutter is not likely to be successful due to the amount of work required to maintain the UI compatibility, but if you are going to do shared UI then Flutter is the only one approaching it in a reasonable way IMO. Throw out the UI and _actually_ standardize on a unified system.
But yeah I don't think it will succeed in the long run.
Flutter is already the most popular cross-platform framework. React Native has more jobs at the moment, it has been around longer and JavaScript is popular.
However the reason Flutter is successful is because in a multi-platform world it let's you beat your competitors on cost, time to market and performance.
Dart is basically TypeScript or JavaScript with Flow, and with the exact same event loop concurrency model.
To say Flutter is the most popular cross-platform is naive. React Native is the most popular "mainstream" (aka HN) cross platform by a mile. Xamarin is huge especially within .net shops. Flutter is comparatively less mature and less adopted than either.
Shared UI is the siren song of cross platform. It has its uses (POC apps, short-lived apps, LOB apps), but it should not be the general go to for anyone. Yet inexperienced teams are going after that as their first foray into cross platform for large, production apps and paying the price.
Experienced cross platform devs generally go for what you describe, a shared core with platform specific UI. In phase 1 you have 50%-70% of code sharing, and over time as you develop a UI DSL you can move up to 90% of code into the shared layer.
The tools for this exist today mostly by leveraging existing mechanisms for C FFI. In the old days that meant writing C++, but theres much better options today in Xamarin and (soon) Kotlin Native. Xamarin is very much batteries included, and you can leverage most of the C# nuget ecosystem to get the functionality you desire.
I have been skeptical for years, but at this point I'm confident that bar the obvious examples (e.g. games) a dedicated app offers next to nothing compared to the browser for the consumers.
I see absolutely no reason to install apps like Linkedin.
>* I see absolutely no reason to install apps like Linkedin.*
Other than to skip the constant nagging to use the app instead of the site… (or, as I do when the nagging irritates, stop using the site without installing the app instead and save myself some time for doom-scrolling elsewhere!)
>* a dedicated app offers next to nothing compared to the browser*
Apps often offer less. For instance making it harder, or usually completely impossible, to have more than one thing open which is easy to do with browser tabs (unless the site/app goes out of its way to make it difficult, or they accidentally mess up session management in a way that scuppers using concurrent tabs/windows that way).
Out of the chaos of the early person computer era came the eventual coalescing around the IBM PC XT standard... it wasn't compatible if it couldn't run Microsoft Flight Simulator. This is the era in which I came of age, and learned to program, and was paid as a programmer.
For a few decades I did other things... now I contemplate a jump back into programming... and see this mess, and cry.
I see zero hope of being able to earn an income based on knowledge of how things work from the bottom to the top, and using that knowledge to deliver value.
All of the good of the world is lost, nothing can be made secure, nothing is compatible with 90% of everything... it's all been shredded, and makes me very, very sad.
What you are experiencing is called nostalgia. Computers still coalesce around a set of standards, the hardware is still a black box, the software is more reliable than it used to be.
The beauty of it is that the you can build things without having to reason about the machine and it's operating system. But you can do that too if you want.
Nothing has been shredded, there is just much more of everything.
> nothing is compatible with 90% of everything.
The Web standards, Vulkan, the OpenDocument format, C11 and so on.
> All of the good of the world is lost, nothing can be made secure, nothing is compatible with 90% of everything... it's all been shredded, and makes me very, very sad.
Computing was less ubiquitous and less complex (in terms of systems, users, functionality). Things felt more secure because there were fewer actors trying to exploit them. There was more compatibility because there were fewer companies. If the space is filled with 10 companies making technology vs. 10000, you can see how it may be easier to coordinate.
The world is messy, and computing is messy. Throwing your hands up and walking away because software ate the world and is harder now (to reason about, to make secure, to maintain) is on you.
>Things felt more secure because there were fewer actors trying to exploit them.
It is true that there were fewer threats back then.
It is also true that things were more secure. The hardware respected the write protect tab of your boot disk. The OS could easily be copied, and the copy verified, in a few minutes. The hardware was dumb, and didn't have anywhere to stuff trojan horses.
We have modern hardware, but no modern operating systems to protect that hardware and make it secure. There are no modern systems as secure as an IBM XT with dual floppy disks and a CGA display running MS-DOS. (and it isn't because MS-DOS was amazing)
I guess that's part of the reason I enjoy reading about and experimenting with old hardware like the Amiga and old consoles. You could learn how the whole machine worked. It's a wonderful feeling that just doesn't exist on modern hardware.
Good comments. However I do see things like Flutter actually being on-par with native apps. You still need occasional deeper native expertise. But way less.
Its just crazy to think that you need to build an app three times, with different technology stack (react, swift, flutter) different UI frameworks, differen people.. While in the end it renders to the same pixels on the screen.
I do see a bright future for flutter. And its already used in some very big apps.
On the other hand: If you dont want to risk it, yeah then be prepared to pay 2x to 3x more on mobile development. And slow your development speed.
Too bad that flutter for web is just to slow and has no SEO support.
> While in the end it renders to the same pixels on the screen
IMO a good app takes advantage of the features and conventions of each platform it runs on, and projects like Flutter actively undermine that.
Unfortunately, this seems to be an opinion that increasingly fewer people hold. I’ve always understood the business argument, but with the rise of Electron and friends it seems most end users don’t care if their software is bloated and weird either.
Flutter is nothing like Electron, you can build a pixel perfect native experience with Flutter, either by implementing it as a widget or you can use a native widget.
Flutter can take advantage of any features, it can call Java, Kotlin, Swift, Objective-C, C and WASM code. You can create a single API for common features, provide an implementation for each platform (endorsed federated plugin) and let others do that as well (non-endorsed federated plugin).
Flutter is lightweight, it runs on embedded devices. Toyota is going to use it in their cars.
I transitioned a side project from native to React Native and it was not a great story (2 years ago at least). Since my app used some native views, and there wasn't enough documentation or community behind that, every new RN version would take nights of my life in patching and getting the app to recompile.
Ultimately, I moved to Flutter and have loved the experience since (https://devbots.ai/jax.html). The main reason I was trying to use native views is because I wanted to draw some custom components (custom drawing commands + animations) but there wasn't a good story around that in RN, but Flutter gives you a canvas for such efforts, with no penalty caused by the native/JS bridge.
For mobile side projects at least I have settled on Flutter. Web is still a disappointing story in Flutter though, so its back to React for now.
Tools like Flutter and React Native are pretty good at sharing UI code but typically an app is much more than just UI. You need to store data locally, interface with an API over the network, (de)serialize API responses etc. And using these tools locks you into their specific UI paradigm.
I think the "next big thing" in cross-platform development is a "shared-core" layer below Flutter/RN that takes care of all I/O abstracting over platform-primitives and exposes a nice async API to the UI layer. I've seen a couple implementations of this, typically in a systems language like C/C++/Rust but all implementations I've seen were custom from-scratch setups with their own build systems and FFI-binding generators. Very complex beasts, especially if building SSL support is included.
Ideally I would like to see some kind of "batteries-included" project/framework allows me to write the shared-core completely independent of the UI. With a build system that produces libraries and bindings ready to be consumed by any UI layer. A jar for Android/JavaFX/Swing apps, a framework for iOS/MacOS apps, a sharedlib+headers for C/C++/Rust cli tools or GTK/QT, a WASM library for web.
With "batteries included" I mean common stuff most apps need like JSON/protobuf (de)serialization, HTTP Client with SSL, define high-level API services (like Retrofit), file/prefs storage, caching, maybe even sqlite or other higher level storage. This way we could build our shared-core completely headless and use various UI frameworks on top of it, without being limited to just one UI framework.