7 ms·

Ready, Set, Multi-Platform

27 points by feross 5y ago

TeeWEE 5y ago
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.
- deergomoo 5y ago
  > 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.
  - Comevius 5y ago
    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.
- arpit 5y ago
  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 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.
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.
a_imho 5y ago
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.
- dspillett 5y ago
  >* 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).
  - pcmaffey 5y ago
    Also, ad-blocking inside apps, or any kind of 3rd party extensions to improve/customize the experience is not possible.
    - dspillett 5y ago
      If you do your personal ad blocking, at least in part, via DNS and run your phone traffic through a VPN to home, then it can work for many apps too. Though that is a bit of faf, a lot more than just using a browser add-on, if you don't already have it setup.
mikewarot 5y ago
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.
- sirwhinesalot 5y ago
  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.
- ctvo 5y ago
  > 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.
  - mikewarot 5y ago
    >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)

27 points by feross 5y ago

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.

deergomoo 5y ago
> 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.
- Comevius 5y ago
  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.
arpit 5y ago
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 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.

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.

a_imho 5y ago

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.

dspillett 5y ago
>* 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).
- pcmaffey 5y ago
  Also, ad-blocking inside apps, or any kind of 3rd party extensions to improve/customize the experience is not possible.
  - dspillett 5y ago
    If you do your personal ad blocking, at least in part, via DNS and run your phone traffic through a VPN to home, then it can work for many apps too. Though that is a bit of faf, a lot more than just using a browser add-on, if you don't already have it setup.

mikewarot 5y ago

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.

sirwhinesalot 5y ago
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.
ctvo 5y ago
> 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.
- mikewarot 5y ago
  >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)