I think developers often want to find a “one true cross platform toolkit for all cases” and I don’t believe that will ever exist. It depends so much on both your app/market but also the skills and experience within your team. No 1 priority is move quickly.
Flutter is brilliant, and probably the way to go, for some apps. A great example of a successful Flutter app is the Sonos app, relatively simple and responsive ui talking to an api. No “rich” or user supplied content. Although they haven’t replaced their desktop app with the flutter app, my guess is that it is the plan.
I think Flutter is brilliant for that type of IOT app, banking/crypto/utilities also the sort that would work well. I don’t think it’s best placed if you want to start using WebViews for some content, when I was last looking at it a year ago there were serious problems.
If you are building a social media app, either Native or React Native (or a combination) is probably the best way to go. You are aiming high so need the best performance and ux.
If you are building a b2b SAAS app I would probably reach for something like Ionic/Capacitor. You can share almost all you codebase with your web/PWA/desktop (electron) apps and can achieve it all with a tiny team. If you need a little more native functionality then adding in NativeScript to a Capacitor works very well.
For an e-commerce app I would probably go Iconic/Capacitor too, the Amazon app for example is mostly webviews.
Productivity apps are much more difficult to recommend for as you probably need large native components.
I've been wondering why webviews with native page transitions aren't a more commonly used thing. It improves the UX a lot by dealing with the abrupt navigation changes of regular web apps. There was a plugin for Cordova that did this (https://github.com/Telerik-Verified-Plugins/NativePageTransi...) but it's abandoned.
> If you are building a social media app, either Native or React Native (or a combination) is probably the best way to go. You are aiming high so need the best performance and ux.
I'd also add that from a business perspective if your product heavily depends on or is entirely mobile-based then it often makes sense to go native and remove an extra party, you don't want to be stuck waiting for upstream fixes or features to land months after they've been released.
Agree! I have been building a React/Next capacitor application for a Dutch e-commerce with a colleague.
Up until now everything is fine for our purposes and performance is near native. Usually similar e-commerce apps require multiple teams, or at least 5+ employees, to release an app on web, Android and iOS. Due to the fact that we have just one single codebase, we can still manage it with the 2 of us.
I also recommend the Capacitor community on Discord in case you need help getting started.
>If you are building a b2b SAAS app I would probably reach for something like Ionic/Capacitor. You can share almost all you codebase with your web/PWA/desktop (electron) apps and can achieve it all with a tiny team. If you need a little more native functionality then adding in NativeScript to a Capacitor works very well.
Honestly nowadays with Expo I would never suggest doing a hybrid app anymore unless you have a large existing JS codebase you want to leverage. Expo makes React Native development so ridiculously simple from the point of scaffolding your app all the way through the app store submission process that there's really no productivity loss anymore vs. doing an Ionic app. The tooling has come so far in the last 10 years that you can just easily develop a native iOS app in Javascript like it's a web app now.
For mobile, if you ask me, the only sane cross-platform strategy is what Kotlin Multiplatform Mobile [1] intends to do: portable business logic, and leave the UI aspects to each platform, keeping them native.
Both Android and iOS have been making strides in simplifying DX for composing expressive UIs. It only makes sense to use those new Android Studio/XCode features as they come.
The myth that Ionic is slower than react native (android native - > skia ) or flutter (skia) has to stop. The evidence isn't just there anymore, chromium is the open source library with the most human resources on earth (mlre than 1 million commits) and therefore has more optimization resources than any competitor. The addition of edpressivity through new features in newer releases does not slow the browser despite the very infantile and hand wavey idea of "bloat" that many HN readers share.
In fact Ionic should be even faster than Electron since it embed many modern optimization practices inside the UI framework. Unfortunately it seems people have zero interest doing serious benchmarking of similar tasks on multiple GUI renderers so the myth stay pervasive. What is sure is that you will never actually have significant performance issues in Ionic or otherwise you're doing something wrong.
Still the myth allows react native and flutter to survive relevancy despite their major ergonomics and expressive inferiority, but for how long? People are used to experience that Electron apps are usually better and faster. The smartphones double standard will break.
Some opinions about good choices here, over a year of app development:
* Don't get confused by the myriads of state management solutions. Just use GetX, it's a sane solution that works as advertised.
* There were a couple of storage plugins like hive that claimed to be better because they be native to the platform and not SQL. As with all platforms, that's bull. SQLite is available, so use that.
* The routers are a clusterfuck, the recent addition of declarative routing by the flutter team was a step in the wrong direction. However, the go_router (in the list) that's based on that looks actually nice.
* Evade everything with code generation, it hinders a good development workflow and the related plugins for that regularly break. For JSON-serialization that's hard though, I make an exception here, since there are many DTOs to manage.
* Flutter theming is a mess. An example that says it all: If you set a colorScheme with a primaryColor, Theme.of(context).primaryColor is not automatically that color. The results of the new ColorScheme.fromSeed() were awful in my test. flex_color_scheme solves that. Be prepared for significant changes here when Material 3 gets fully introduced to Flutter (the recent release 2.10 started with that).
Some things to keep in mind despite plugins: Flutter is not ready for the web (and the sites it would produce are JS abominations, so it will never be suited for the web if the approach does not change) and while the framework seems more stable than native app development, there are still breaking changes, both in the core and even more so in the plugin ecosystem. Selecting plugins based on a good stability is hard (as it's not obvious), but worthwhile.
Despite its shortcomings and Google connection Flutter is really nice to build iOS and Android apps with one code base, and I'd prefer it even for just an Android app by now.
Loving Flutter to bits. It's been such a tremendous help publishing a fast, reliable and good looking app cross platform. It can't really be compared to anything else. The regular updates are awesome as well. There is always performance improvements and other things to look forward to.
It's always been dart that put me off. For flutter apps supposedly compiling to native code, I don't like using a language that was apparently designed to live within the constraints as a web-based language. There are many other languages that I would rather use instead.
I was surprised to see how janky the gallery demo app is on mobile, especially considering Dart is AOT compiled. Apparently Flutter is single threaded too and has a feature called "Isolates" but I'm not sure if they can be used to paint animations off the main thread
I think they should give up on Flutter for Web and just focus on mobile and desktop (and maybe extend use on Smart Watches, Smart TV, embedded instead). Too many people still remember Java Applets, google's GWT, Flash/Flex and how it ended. They are out of focus trying to support Web as well.
I had also higher expectation regarding Dart FFI - I think with their ffigen we are still only in ctypes like python bindings territory. Nowhere near something like pybind11 [0] for c++ bindings yet.
I love the idea of Flutter, as I think it's a more stable approach than what React Native tries to do. But I hate Material Design with a passion, and I'm not sure why they tied it so closely to Flutter. Even the functional packages you import into your Flutter project are labeled "material".
Dart is like Java, Kotlin or Swift with the runtime model of JavaScript, there is nothing weird about it. It takes an hour to learn it if you know either of these.
The language fades into background in my experience. There are some gotchas (like overuse of Dynamic) but on the whole, tooling works really well, and can get stuff done.
Why is Dart weird for you? I've seen people getting to know Dart from various backgrounds (be it from Java, JavaScript, C# or Python), and so far everybody got productive in a short amount of time.
One feature I feel holding Flutter back compared to ReactNative and other options is Code Push support.
I really enjoy writing Flutter apps but the ability to push updates and bypass store reviews has been extremely valuable for multiple companies I've built apps for.
Flutter is much less expressive and ergonomic than Ionic + Vue3.ts. Ionic is also more performant, in fact chromium is the fastest rendering engine to exist (let alone with css contain) which is no surprise since Skia is made by chromium devs for chromium devs in the first place. But myths about "native" performance (flutter isn't even native and native isn't a performance property, it is an ad-hoc property) are very slow to update despite the countless example of electron apps bringing a performance competitive advantage (vscode vs intellij, Figma vs Adobe xd, etc)
Flutter is built on top of Skia, and Dart AOT produces compact, fast native code. Dart only has a small runtime, it's memory usage is measured in megabytes. Chromium need gigabytes of memory and a powerful mobile or desktop processor. Dart can run on IoT devices like a fridge or thermostat. You can use Flutter in cheap infotainment systems.
[+] [-] samwillis|4 years ago|reply
Flutter is brilliant, and probably the way to go, for some apps. A great example of a successful Flutter app is the Sonos app, relatively simple and responsive ui talking to an api. No “rich” or user supplied content. Although they haven’t replaced their desktop app with the flutter app, my guess is that it is the plan.
I think Flutter is brilliant for that type of IOT app, banking/crypto/utilities also the sort that would work well. I don’t think it’s best placed if you want to start using WebViews for some content, when I was last looking at it a year ago there were serious problems.
If you are building a social media app, either Native or React Native (or a combination) is probably the best way to go. You are aiming high so need the best performance and ux.
If you are building a b2b SAAS app I would probably reach for something like Ionic/Capacitor. You can share almost all you codebase with your web/PWA/desktop (electron) apps and can achieve it all with a tiny team. If you need a little more native functionality then adding in NativeScript to a Capacitor works very well.
For an e-commerce app I would probably go Iconic/Capacitor too, the Amazon app for example is mostly webviews.
Productivity apps are much more difficult to recommend for as you probably need large native components.
[+] [-] udbhavs|4 years ago|reply
[+] [-] jamil7|4 years ago|reply
I'd also add that from a business perspective if your product heavily depends on or is entirely mobile-based then it often makes sense to go native and remove an extra party, you don't want to be stuck waiting for upstream fixes or features to land months after they've been released.
[+] [-] stragio|4 years ago|reply
Up until now everything is fine for our purposes and performance is near native. Usually similar e-commerce apps require multiple teams, or at least 5+ employees, to release an app on web, Android and iOS. Due to the fact that we have just one single codebase, we can still manage it with the 2 of us.
I also recommend the Capacitor community on Discord in case you need help getting started.
[+] [-] ramesh31|4 years ago|reply
Honestly nowadays with Expo I would never suggest doing a hybrid app anymore unless you have a large existing JS codebase you want to leverage. Expo makes React Native development so ridiculously simple from the point of scaffolding your app all the way through the app store submission process that there's really no productivity loss anymore vs. doing an Ionic app. The tooling has come so far in the last 10 years that you can just easily develop a native iOS app in Javascript like it's a web app now.
[+] [-] sirius87|4 years ago|reply
Both Android and iOS have been making strides in simplifying DX for composing expressive UIs. It only makes sense to use those new Android Studio/XCode features as they come.
[1] https://kotlinlang.org/lp/mobile/
[+] [-] jcelerier|4 years ago|reply
[+] [-] The_rationalist|4 years ago|reply
[+] [-] amelius|4 years ago|reply
[+] [-] newlisp|4 years ago|reply
[+] [-] onli|4 years ago|reply
* Don't get confused by the myriads of state management solutions. Just use GetX, it's a sane solution that works as advertised.
* There were a couple of storage plugins like hive that claimed to be better because they be native to the platform and not SQL. As with all platforms, that's bull. SQLite is available, so use that.
* The routers are a clusterfuck, the recent addition of declarative routing by the flutter team was a step in the wrong direction. However, the go_router (in the list) that's based on that looks actually nice.
* Evade everything with code generation, it hinders a good development workflow and the related plugins for that regularly break. For JSON-serialization that's hard though, I make an exception here, since there are many DTOs to manage.
* Flutter theming is a mess. An example that says it all: If you set a colorScheme with a primaryColor, Theme.of(context).primaryColor is not automatically that color. The results of the new ColorScheme.fromSeed() were awful in my test. flex_color_scheme solves that. Be prepared for significant changes here when Material 3 gets fully introduced to Flutter (the recent release 2.10 started with that).
Some things to keep in mind despite plugins: Flutter is not ready for the web (and the sites it would produce are JS abominations, so it will never be suited for the web if the approach does not change) and while the framework seems more stable than native app development, there are still breaking changes, both in the core and even more so in the plugin ecosystem. Selecting plugins based on a good stability is hard (as it's not obvious), but worthwhile.
Despite its shortcomings and Google connection Flutter is really nice to build iOS and Android apps with one code base, and I'd prefer it even for just an Android app by now.
[+] [-] davidkuennen|4 years ago|reply
Keep going!
[+] [-] The_rationalist|4 years ago|reply
[+] [-] pepalgarid|4 years ago|reply
[+] [-] sdflhasjd|4 years ago|reply
[+] [-] udbhavs|4 years ago|reply
[+] [-] pzo|4 years ago|reply
I had also higher expectation regarding Dart FFI - I think with their ffigen we are still only in ctypes like python bindings territory. Nowhere near something like pybind11 [0] for c++ bindings yet.
[0] https://github.com/pybind/pybind11
[1] https://github.com/mozilla/uniffi-rs
[+] [-] kkjjkgjjgg|4 years ago|reply
[+] [-] danielvaughn|4 years ago|reply
[+] [-] fdjm|4 years ago|reply
[+] [-] mkl95|4 years ago|reply
[+] [-] slig|4 years ago|reply
[+] [-] netcyrax|4 years ago|reply
[+] [-] Comevius|4 years ago|reply
[+] [-] stragio|4 years ago|reply
[+] [-] chakkepolja|4 years ago|reply
[+] [-] mikewhy|4 years ago|reply
https://github.com/dart-lang/language/issues/783
[+] [-] isoos|4 years ago|reply
[+] [-] daanlo|4 years ago|reply
[+] [-] The_rationalist|4 years ago|reply
[+] [-] jasfi|4 years ago|reply
[+] [-] vyrotek|4 years ago|reply
I really enjoy writing Flutter apps but the ability to push updates and bypass store reviews has been extremely valuable for multiple companies I've built apps for.
https://microsoft.github.io/code-push/
[+] [-] chgibb|4 years ago|reply
[+] [-] randyrand|4 years ago|reply
[+] [-] phantomathkg|4 years ago|reply
* Payment * Video with DRM
[+] [-] sgt|4 years ago|reply
[+] [-] xsnepaul|4 years ago|reply
[+] [-] sunjester|4 years ago|reply
[+] [-] sonnyblarney|4 years ago|reply
[deleted]
[+] [-] scarface74|4 years ago|reply
[+] [-] The_rationalist|4 years ago|reply
[+] [-] Comevius|4 years ago|reply
[+] [-] geraldwhen|4 years ago|reply