5 ms·

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 w

by zorr 5y ago

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.

K0nserv 5y ago
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.
- zorr 5y ago
  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.
  - Comevius 5y ago
    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. https://ziglang.org/ https://ziglang.org/
- JamesSwift 5y ago
  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.
  - Comevius 5y ago
    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.
    - 5y ago
JamesSwift 5y ago
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.

by zorr 5y ago

K0nserv 5y ago

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.

zorr 5y ago
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.
- Comevius 5y ago
  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. https://ziglang.org/ https://ziglang.org/
JamesSwift 5y ago
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.
- Comevius 5y ago
  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.
  - 5y ago

JamesSwift 5y ago

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.