If I had to bet on one path forward, this would be it. Shared-nothing View layers and then building the rest of the layers for sharing with KMP. I have yet to give it a serious try, but it seems to be the least bad alternative out there.
Expo has been making unbelievably rapid progress with tooling, documentation, consistent, high quality API's and general improvements. Evan Bacon + team are really impressive to watch
There is no clear winner here yet. Every solution has pros and cons.
1) Need mostly cross platform desktop and using hardware extensively (bluetooth, camera, audio, nfc, sensors, etc.) -> Qt
2) Have web expertise or need easily to find well paid job and need mostly web, android, ios app -> React Native
3) Need only iOS, Android app that is mostly custom UI with some smooth animation mostly for some side project (not many jobs in the market comparing to React Native or iOS/Android Native) -> Flutter
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
When I tried it a couple of weeks ago on an old Android device (Pixel 3A) there was a little jank. Then I tried a couple apps bundled with Android and was surprised to find a comparable amount of jank.
The gallery demo app is janky on old Android devices with bad GPU drivers, and janky on iOS because of Metal, but those issues are being solved. The main issue with iOS and Metal is the shader compilation jank, for which the workaround is shader warm-up that can be automated, but requires an effort from the developer.
Dart is single threaded, but the event loop is better than threads for most things, except heavy calculations, but that's what isolates are for. This is probably the best way to do it even in C when latency is important. CPU schedulers tend to leave you with less control over latency when there is underutilization or yielding.
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 suspect that mid term this is going to be changing. There is currently a big behind the scenes push to move the web target to Wasm (dependent upon Wasm GC landing in some kind of reasonable timeframe).
At that point I suspect you will see the importance of compiling to JS declining rapidly.
Side note: The other major push that seems relevant to some of the other comments here is they are also looking to redo the shader pipeline from scratch and make that AOT compiled as well because right now it tries to just JIT all of that and it isn’t always very predictable as a result. [1]
So combining that along with a WASM target I actually feel super bright about the future of Flutter as a tech choice on web, desktop, mobile etc…
They have some more detail about both of these things in their Roadmap [2] if you’re interested.
I think they are planning to use wasm as target for Web. They don’t have any reason to compile to wasm on mobile when they already can compile to native. WASM is equivalent of JVM and I doubt they will start providing binding to different languages. Even if they do Dart would be the still main language on this platform in similar vein like Java/kotlin is the main language on JVM - JPython, JRuby, Groovy are irrelevant. I also don’t think JavaScript/Typescript will get irrelevant in WASM - for the same reason even though you currently can compile CPython to wasm
I am not a programmer by trade, but I do build apps occasionally.
Dart is a relatively simple language and you'll get the hang of it quite quickly.
The widget-tree framework of flutter makes it easy for you to just have small amounts of code that all chain together, and it becomes easier to find your mistakes and grow your platform.
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 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.
Same here, it’s something I wish Capacitor supported.
Last year I experimented with using NativeScript in a Capacior app to open native modals with a second webview. Since then Ionic have released “Capacitor Portals” which brings all the native apis available within the Capacitor webview to native apps, effectively allowing you to embed capacitor views in another app. I wander if there is the potential to combine the two to get the native view transitions.
Edit:
Just to elaborate a little further on my experiment. Effectively what you ended up with was the two webviews being able to communicate with each other as though you had used the window.open or frames JavaScript api in the browser.
You render your mobile web view like normal, wire up a JavaScript handler (formerly known as Turbolinks), and push native screens on iOS. It works really well for CRUD and "boring" SAAS apps with little interaction outside of forms. And when you need higher fidelity dropping down to SwiftUI or UIKit is straightforward.
To make things even simpler, I built Jumpstart iOS, which takes care of all of the Swift boilerplate. Navigation, authentication, and push notifications all work out of the box after adding a few endpoints to your server.
There is obviously no correct answer here, very good arguments on both sides.
Personally I prefer an opinionated framework, I don’t have to research library’s and tooling. It all just works and I have a single set of docs for reference.
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.
Completely agree with you on performance, certainly on any mobile device with less than 5yo tech. I think there are still a few performance problems on older/low-end hardware, that’s why for social media type apps I would recommend native. You would have the same perf problems with Flutter and React Native on that hardware.
I have only one significant complaint that effects Capacitor on iOS and it’s a WebKit bug (Ionic can’t fix it). With WebKit on iOS if you have an overflow:scroll with a text input of any kind (basically any app you build) the text cursor or selection highlight will remain visible outside the overflow area when you scroll. So for example if you select text in an input and scroll the view so the input is under a fixed toolbar, the selection highlight or cursor is visible infront of the toolbar. It looks very messy, I wish Apple would fix it. The minute you see it you know it’s not a native app.
Not my experience, and I'm not talking benchmarks. That said I barely use my phone and I'm thinking mainly about desktop applications. Mac-native apps are universally faster and more responsive than Electron-based equivalents.
Doing more work costs more resources than doing less work, and it's hard to beat JITing Javascript and manipulating and rendering HTML+CSS for wasteful computation, no matter how much you optimize it.
That said, I've used phone apps that were essentially some webpage in webview that were highly responsive and pleasant to use, so it's certainly possible to have a good experience with webapps.
Reducing the amount of Javascript and using simpler HTML+CSS would also probably go a long way to make these apps fasters and lighter. I remember using AJAX-based chat websites in the 2000s that ran perfectly fine on hardware far weaker than even a 5 year old phone, so how the heck does Slack have such poor performance? That's the real problem.
> 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.
My concern with Ionic/React native isn't speed (I'm sure it's good enough), it's maintainability. I've been burned enough by the JS ecosystem to stay away from it when I can. It usually takes around 1 hour to update 6 months worth of Flutter framework & packages updates, I can't say the same about the javascript ecosystem.
On paper it looks awesome, in practice I just don't want to deal with those maintenance issues anymore.
I think the majority of Ionic apps have been built with Angular, which I believe has had a fairly clean upgrade path. The React and Vue binding are newer but both aren’t to hard to upgrade (ignoring the vue2-3 transition, Ionic only ever supported 3)
Plus, with Ionic in contrast to the majority of JavaScript frameworks, you are using one built by a company where the framework is the core business. They have a long track record and sustainable business. They aren’t going anywhere.
Maybe I've been a bit unfair and I should give it a go, I just had so many bad maintainability experiences in the JS world that I was just staying away from it if I can.
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.
Ionic is a html/javascript/css mobile ui framework using web components, with bindings for Angular, React and Vue. You can build PWAs, mobile web apps, or with Capacitor actual mobile apps with it.
Capacitor is a mobile app toolkit for building apps with web technologies in a webview. Effectively the successor to Cordova/PhoneGap. It’s built and maintained by the same team/company as that behind the Ionic framework.
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.
While I agree where Kotlin is going with their multi platform tooling is great, I do think it’s just one more option in an already good bag of options. And a strong one at that.
My one observation though is that for many (the majority?) of mobile apps the UI layer is the vast majority of the app, easily 70-80%. Especially for apps where the business logic is calling a http api, which most CRUD type apps are. For these a cross platform toolkit that abstracts away ui differences so you only have to build it once is a massive plus.
KMM shows promise for writing the same db/network logic for iOS, Android, Windows, and macOS. (less so on desktop, but it does work) Realized expectations give you a good way to extend that underlying layer a bit further. But you’re totally right — in the end, you still need to undetstand iOS and Android development, UI in particular, to make it work. It also doesn’t help that KMM is currently a buggy mess, Android Studio has a million issues with it, and the documentation is sparse to nonexistent for completely pedestrian use cases (good luck writing tests for anything). I hope it shapes up soon though.
I've been waiting for the right opportunity to use it and for it to mature a little more. I really wish we could go the other way since we have a bunch of existing Swift packages and our team is much stronger on iOS than Android.
> 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.
>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.
> 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.
Agreed. I would even say in these past 3 years or so, React Native development has smoothed itself out. The experience of setting up an app and being productive in it coming in as a web developer is phenomenal. One thing is that the community support is still small compared to native or even React itself. Peformance too is lacking. I've been waiting for the new architecture Fabric to come in replacing JSC with JSI but it's taking quite a long time. There still isn't a clear estimate on it's release yet.
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.
> Don't get confused by the myriads of state management solutions. Just use GetX, it's a sane solution that works as advertised.
Saying this doesn't help anyone. There are many alternatives and as you say, they compete fiercely for Github stars. GetX is popular package, but it has it's drawbacks: maintainer and bloat.
- Maintainer: he's been known to make wild claims about his package, and target other alternatives with strong unbacked opinions.
- Bloat: it tries to do a lot of things. Integration with other packages, concepts and tools don't work well - certainly doesn't integrate easily.
That's exactly what I mean - none of this matters. The maintainer does his job well and GetX does solve the problems it claims to solve nicely. Use Obx with a GetX controller and you are done. The other parts of the project, like the routing, are an option if it fits to your app.
And sorry, I really think this stated clearly is helpful. It's not worth your time to even look at alternatives. Sure, that could change in the future if the plugin gets abandoned, but it has seen good maintenance so far and zero breakage. Everything else to my eyes is FUD.
The solution to the problem of having too many options is probably not best solved by picking one based on someone from the internet without evidence or comparison.
The solution to many people debating is not to just pick one side of the debate because the debate doesn't matter - you think.
GetX is a very high-level API for Flutter, it works for simple things, but as you go on you will realize how restricting it is. It abstracts away details not meant to be abstracted away. It's just bad design, and it's anti-patterns will bite you.
Just learn how to do things the proper way, because it's not that hard, and much more expressive and clean.
If you go for Flutter job it's best to not mention GetX either.
It works perfectly for us - in a professional app nonetheless - and has not been restricting at all. No bad design or anti-pattern bit us, and it does not get cleaner or more expressive than Obx with a controller. This is unlikely to change, the process where our app got more and more complicated has already stopped.
> If you go for Flutter job it's best to not mention GetX either.
I wouldn't work for an employer that does not let me pick the right tool for the job, so there is no danger there.
Not to get on your nerve, but GetX is basically a toy API, and the codebases that use it tend to evolve in the heap of spaghetti direction, but if your app is simple enough you can get away with it and save time, so who am I to knock it.
Na, it's okay, if you really feel that way you should comment accordingly, especially given my strong blanket recommendation. I see it exactly the other way around, but defining things like "clean" are hard to do and we might just have completely different positions.
Maybe to make it as constructive as possible, why don't you link to what is your preferred alternative approach? I assume it's not setState :)
Riverpod is pretty good, and using the Bloc pattern without any Bloc libraries, just with StreamBuilder or your own abstraction is pretty good. The rest is just using the Flutter API as intended.
I personally also like to practice data-oriented design, write most of the logic in C/Zig with a functional reactive Dart API, and then share the streams with Riverpod. I keep most of the state in C/Zig, but that should be a Dart-only library, I just use C/Zig because I need the core functionality of my app to be portable, for example to use it with Vue.js, or even FreeBSD, which Dart don't even support, but if that's not the case a Dart-only library for the core functionality is the way to go.
> Don't get confused by the myriads of state management solutions...
> Evade everything with code generation...
It is funny to see this theme getting repeated in various domains: at the same time, you will get users who complain that there are not enough choices for them in domain X, while others complain that there are too many choices in the same domain X. And usually there is no single best solution to rule them all.
E.g. in these specific items, I've found bloc + freezed-based code generation to do state works much better for me than any alternatives. ymmv.
> I've found bloc + freezed-based code generation to do state works much better for me than any alternatives. ymmv.
YMMV definitely applies :) Since I have some experience with exactly that alternative: I see bloc + freezed as the antithesis to GetX. "Clean" abstraction over "simple" code. There might be more extreme example for both sides of course, but this has been my impression.
We do use bloc + freezed for some specific flows in the app where the abstraction just fit better. A better fitting abstraction is a big plus on its own for those usecases. On the other hand, bloc had a bunch of breaking changes (nicely visible in https://pub.dev/packages/flutter_bloc/changelog), and that especially in combination with hydrated bloc has given us a bunch of grief. I hate breaking changes more than anything.
It might still be a better solution - so really, YMMV - if your goal is maximum abstraction to be able to change frameworks (or in this case, I assume it would be about state management solutions), after all that's where the solution is coming from. For me, that was an anti-goal, abstraction = complexity, while minimal complexity with maximal development speed was what we needed. GetX fit perfectly for that. Admittedly, ignoring some things to learn with lists and at the beginning strange issues with Obx change detection, but the latter got better, either with bug fixes or experience. If Obx misbehaves now it has always been a clear fault on our side.
Flutter team has already stopped developing for mobile, leaving a lot of things unfinished or missing: integration testing, location, iOS dark mode, iOS keyboard dismiss, iOS detail cell and other common iOS widgets, material date+time picker, navigator documentation, and others.
The page is called "Awesome Flutter" but it should be called "Third-party Flutter code to fill some of the holes in Flutter".
>Despite its shortcomings and Google connection Flutter is really nice to build and Android apps with one code base, and l'd prefer it even for just an Android app by now.
Have you tried building android apps with Compose? It's significantly better than the old view system in android.
Indeed I have not, its 1.0 release came after I had moved on from that job. Does not look as nice to me, from a first glance, but that might be misleading. Thanks for the hint.
Other than being unviable for creating iOS-applications, I find it significantly nicer. Merely being able to use Kotlin instead of Dart is a huge advantage.
This is terrible advice. GetX is great for rapid prototyping but nothing more.
Once you reach a certain point you will need to re-code your entire app to get rid of this.
If you choose GetX, you are no longer building a flutter app, you are building a GetX app, and you will want GetX developers to work with the code and at some point it will becomes unsustainable and you will need to start over.
GetX is bottom of the barrel flutter development, and is only valuable for people who churn out large amounts of apps for customers that have no idea what they want.
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.
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.
You can learn new language in short time but standard library and tools not that fast - especially if they dont exist. You will have to google e.g. how to parse Date etc. People enjoy big ecosystem of libraries and tools.
Just to give you example In many ways I prefer Ruby than Python as a language but Python is just swiss army knife and in many cases you are one PIP install away to finding library that solves your problem. Maybe Python doesn't have such a nice web framework as Ruby on Rails but ruby is not much used elsewhere.
I think people complaining about Dart as a chosen language not because of it's features but because
1) you have to learn and/or redevelop new SDK for it,
2) language doesn't have good interrop with any other languages (like Kotlin -> Java, Swift -> Objective-C, TypeScript -> JavaScript, Objective-C -> C++, Rust -> C, C++ -> C)
I'll give it a chance when it has algebraic data types and pattern matching. The fact that they post these as examples of language features they don't want means I don't want to touch it with a ten-foot pole. I look at Option, Either, and functor in dartz and I can see that the ergonomics are so bad and noisy to read. Semicolons required in a modern language is the cherry atop this ‘nope’ dessert.
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.
They are basically the same language, but Kotlin tries to sit on different runtime models with Kotlin/JVM, Kotlin/JS and Kotlin/Native. Dart behaves the same everywhere.
Saying they are the same language is proof of gigantic ignorance both ergonomics wise and feature wise.
Secondly Kotlin multiplatform behave the same, we are using it to share backend and frontend business logic (Kotlin js).
Yes, the reason Dart exists and continues to exist is not that it is better than Kotlin but because Kotlin is not owned by Google and they just have a giant not invented here syndrome. It's all about control for them. It's basically their way or the highway.
But Google seems to be betting on multiple horses here. They also created Jetpack Compose. And of course Jetbrains extended that to Compose Desktop and Compose Web so that ecosystem is actually becoming quite interesting together with their multi platform Kotlin compilers. Compose Desktop does not currently use the Kotlin native compiler unfortunately but it does use Skia, which is the same graphics library that Google uses for Chrome and Flutter. If they'd fix the desktop variant to use the native compiler, they'd be able to target basically any platform. Including IOS.
IMHO that is such an obvious thing to do for Jetbrains that I pretty much assume that they are planning to go there. That would make this a direct competitor to Flutter.
Compose is getting quite popular despite still being relatively new. IMHO, if Jetbrains (or Google) get their act together and make that usable for IOS, there would be a lot of developers that would use that. I know I would. Flutter is not for me. I'm sure it's great but I have no desire to learn Dart.
We are currently using Kotlin js to be able to target mobile and web and kotlin jvm on our servers. We package up our app using Cordova and we have integrated a few plugins to e.g. do things with NFC. It works great. Performance is not an issue for us. And having just one code base and 1 UI team is critical for us. But I wouldn't mind some more options for cross platform development. Browsers are a necessary evil currently to target mobile and desktop with 1 application. But the boundaries between these platforms are increasingly artificial.
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.
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.
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".
I think a simple heuristic would be who is using it internally.
It’s their payment platforms and Ads platform and a centrepiece of their upcoming operating system. It has literally billions of dollars depending on it. It’s not going anywhere.
Their cross platform mobile framework is not part of that strategy. In fact, Google has already said that they are moving toward more native development for iOS.
That doesn't mean they need to switch away from flutter. You can use it to have a single codebase that uses Material design on Android and Cupertino design on iOS.
Their upcoming operating system fuchsia? They have to first release it and then persuade most manufactures to use it and explain why they should invest money into it instead of their currently profitable android devices.
It's not going be that easy for them like with android. They had WearOS for a while and I bet they had give some big carrot to Samsung so that they finally use it instead of Tizen. Same with Google TV - Samsung prefer tizen, LG sticks with webOS. Google's IoT platforms (forgot the name) were a flop. Chromebook - mostly irrelevant and devs don't want to write software for that - recently they killed Chrome App Store.
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.
100 comments
[ 0.20 ms ] story [ 3.0 ms ] threadExpo has been making unbelievably rapid progress with tooling, documentation, consistent, high quality API's and general improvements. Evan Bacon + team are really impressive to watch
1) Need mostly cross platform desktop and using hardware extensively (bluetooth, camera, audio, nfc, sensors, etc.) -> Qt
2) Have web expertise or need easily to find well paid job and need mostly web, android, ios app -> React Native
3) Need only iOS, Android app that is mostly custom UI with some smooth animation mostly for some side project (not many jobs in the market comparing to React Native or iOS/Android Native) -> Flutter
When I tried it a couple of weeks ago on an old Android device (Pixel 3A) there was a little jank. Then I tried a couple apps bundled with Android and was surprised to find a comparable amount of jank.
I've heard it's worse on iOS though.
Dart is single threaded, but the event loop is better than threads for most things, except heavy calculations, but that's what isolates are for. This is probably the best way to do it even in C when latency is important. CPU schedulers tend to leave you with less control over latency when there is underutilization or yielding.
At that point I suspect you will see the importance of compiling to JS declining rapidly.
Side note: The other major push that seems relevant to some of the other comments here is they are also looking to redo the shader pipeline from scratch and make that AOT compiled as well because right now it tries to just JIT all of that and it isn’t always very predictable as a result. [1]
So combining that along with a WASM target I actually feel super bright about the future of Flutter as a tech choice on web, desktop, mobile etc…
They have some more detail about both of these things in their Roadmap [2] if you’re interested.
[1] https://github.com/flutter/impeller
[2] https://github.com/flutter/flutter/wiki/Roadmap
Dart is a relatively simple language and you'll get the hang of it quite quickly.
The widget-tree framework of flutter makes it easy for you to just have small amounts of code that all chain together, and it becomes easier to find your mistakes and grow your platform.
I recommend going for it if you have an interest.
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
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.
Last year I experimented with using NativeScript in a Capacior app to open native modals with a second webview. Since then Ionic have released “Capacitor Portals” which brings all the native apis available within the Capacitor webview to native apps, effectively allowing you to embed capacitor views in another app. I wander if there is the potential to combine the two to get the native view transitions.
Edit:
Just to elaborate a little further on my experiment. Effectively what you ended up with was the two webviews being able to communicate with each other as though you had used the window.open or frames JavaScript api in the browser.
You render your mobile web view like normal, wire up a JavaScript handler (formerly known as Turbolinks), and push native screens on iOS. It works really well for CRUD and "boring" SAAS apps with little interaction outside of forms. And when you need higher fidelity dropping down to SwiftUI or UIKit is straightforward.
https://github.com/hotwired/turbo-ios
To make things even simpler, I built Jumpstart iOS, which takes care of all of the Swift boilerplate. Navigation, authentication, and push notifications all work out of the box after adding a few endpoints to your server.
https://jumpstartrails.com/ios
Personally I prefer an opinionated framework, I don’t have to research library’s and tooling. It all just works and I have a single set of docs for reference.
I have only one significant complaint that effects Capacitor on iOS and it’s a WebKit bug (Ionic can’t fix it). With WebKit on iOS if you have an overflow:scroll with a text input of any kind (basically any app you build) the text cursor or selection highlight will remain visible outside the overflow area when you scroll. So for example if you select text in an input and scroll the view so the input is under a fixed toolbar, the selection highlight or cursor is visible infront of the toolbar. It looks very messy, I wish Apple would fix it. The minute you see it you know it’s not a native app.
Not my experience, and I'm not talking benchmarks. That said I barely use my phone and I'm thinking mainly about desktop applications. Mac-native apps are universally faster and more responsive than Electron-based equivalents.
Doing more work costs more resources than doing less work, and it's hard to beat JITing Javascript and manipulating and rendering HTML+CSS for wasteful computation, no matter how much you optimize it.
That said, I've used phone apps that were essentially some webpage in webview that were highly responsive and pleasant to use, so it's certainly possible to have a good experience with webapps.
Reducing the amount of Javascript and using simpler HTML+CSS would also probably go a long way to make these apps fasters and lighter. I remember using AJAX-based chat websites in the 2000s that ran perfectly fine on hardware far weaker than even a 5 year old phone, so how the heck does Slack have such poor performance? That's the real problem.
My concern with Ionic/React native isn't speed (I'm sure it's good enough), it's maintainability. I've been burned enough by the JS ecosystem to stay away from it when I can. It usually takes around 1 hour to update 6 months worth of Flutter framework & packages updates, I can't say the same about the javascript ecosystem.
On paper it looks awesome, in practice I just don't want to deal with those maintenance issues anymore.
Plus, with Ionic in contrast to the majority of JavaScript frameworks, you are using one built by a company where the framework is the core business. They have a long track record and sustainable business. They aren’t going anywhere.
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.
Capacitor is a mobile app toolkit for building apps with web technologies in a webview. Effectively the successor to Cordova/PhoneGap. It’s built and maintained by the same team/company as that behind the Ionic framework.
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/
My one observation though is that for many (the majority?) of mobile apps the UI layer is the vast majority of the app, easily 70-80%. Especially for apps where the business logic is calling a http api, which most CRUD type apps are. For these a cross platform toolkit that abstracts away ui differences so you only have to build it once is a massive plus.
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.
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.
Agreed. I would even say in these past 3 years or so, React Native development has smoothed itself out. The experience of setting up an app and being productive in it coming in as a web developer is phenomenal. One thing is that the community support is still small compared to native or even React itself. Peformance too is lacking. I've been waiting for the new architecture Fabric to come in replacing JSC with JSI but it's taking quite a long time. There still isn't a clear estimate on it's release yet.
* 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.
Saying this doesn't help anyone. There are many alternatives and as you say, they compete fiercely for Github stars. GetX is popular package, but it has it's drawbacks: maintainer and bloat.
- Maintainer: he's been known to make wild claims about his package, and target other alternatives with strong unbacked opinions.
- Bloat: it tries to do a lot of things. Integration with other packages, concepts and tools don't work well - certainly doesn't integrate easily.
And sorry, I really think this stated clearly is helpful. It's not worth your time to even look at alternatives. Sure, that could change in the future if the plugin gets abandoned, but it has seen good maintenance so far and zero breakage. Everything else to my eyes is FUD.
The solution to many people debating is not to just pick one side of the debate because the debate doesn't matter - you think.
Just learn how to do things the proper way, because it's not that hard, and much more expressive and clean.
If you go for Flutter job it's best to not mention GetX either.
> If you go for Flutter job it's best to not mention GetX either.
I wouldn't work for an employer that does not let me pick the right tool for the job, so there is no danger there.
Maybe to make it as constructive as possible, why don't you link to what is your preferred alternative approach? I assume it's not setState :)
https://riverpod.dev/
I personally also like to practice data-oriented design, write most of the logic in C/Zig with a functional reactive Dart API, and then share the streams with Riverpod. I keep most of the state in C/Zig, but that should be a Dart-only library, I just use C/Zig because I need the core functionality of my app to be portable, for example to use it with Vue.js, or even FreeBSD, which Dart don't even support, but if that's not the case a Dart-only library for the core functionality is the way to go.
It is funny to see this theme getting repeated in various domains: at the same time, you will get users who complain that there are not enough choices for them in domain X, while others complain that there are too many choices in the same domain X. And usually there is no single best solution to rule them all.
E.g. in these specific items, I've found bloc + freezed-based code generation to do state works much better for me than any alternatives. ymmv.
YMMV definitely applies :) Since I have some experience with exactly that alternative: I see bloc + freezed as the antithesis to GetX. "Clean" abstraction over "simple" code. There might be more extreme example for both sides of course, but this has been my impression.
We do use bloc + freezed for some specific flows in the app where the abstraction just fit better. A better fitting abstraction is a big plus on its own for those usecases. On the other hand, bloc had a bunch of breaking changes (nicely visible in https://pub.dev/packages/flutter_bloc/changelog), and that especially in combination with hydrated bloc has given us a bunch of grief. I hate breaking changes more than anything.
It might still be a better solution - so really, YMMV - if your goal is maximum abstraction to be able to change frameworks (or in this case, I assume it would be about state management solutions), after all that's where the solution is coming from. For me, that was an anti-goal, abstraction = complexity, while minimal complexity with maximal development speed was what we needed. GetX fit perfectly for that. Admittedly, ignoring some things to learn with lists and at the beginning strange issues with Obx change detection, but the latter got better, either with bug fixes or experience. If Obx misbehaves now it has always been a clear fault on our side.
The page is called "Awesome Flutter" but it should be called "Third-party Flutter code to fill some of the holes in Flutter".
Have you tried building android apps with Compose? It's significantly better than the old view system in android.
This is terrible advice. GetX is great for rapid prototyping but nothing more.
Once you reach a certain point you will need to re-code your entire app to get rid of this.
If you choose GetX, you are no longer building a flutter app, you are building a GetX app, and you will want GetX developers to work with the code and at some point it will becomes unsustainable and you will need to start over.
GetX is bottom of the barrel flutter development, and is only valuable for people who churn out large amounts of apps for customers that have no idea what they want.
Keep going!
Just to give you example In many ways I prefer Ruby than Python as a language but Python is just swiss army knife and in many cases you are one PIP install away to finding library that solves your problem. Maybe Python doesn't have such a nice web framework as Ruby on Rails but ruby is not much used elsewhere.
I think people complaining about Dart as a chosen language not because of it's features but because
1) you have to learn and/or redevelop new SDK for it,
2) language doesn't have good interrop with any other languages (like Kotlin -> Java, Swift -> Objective-C, TypeScript -> JavaScript, Objective-C -> C++, Rust -> C, C++ -> C)
3) ecosystem is small
But Google seems to be betting on multiple horses here. They also created Jetpack Compose. And of course Jetbrains extended that to Compose Desktop and Compose Web so that ecosystem is actually becoming quite interesting together with their multi platform Kotlin compilers. Compose Desktop does not currently use the Kotlin native compiler unfortunately but it does use Skia, which is the same graphics library that Google uses for Chrome and Flutter. If they'd fix the desktop variant to use the native compiler, they'd be able to target basically any platform. Including IOS.
IMHO that is such an obvious thing to do for Jetbrains that I pretty much assume that they are planning to go there. That would make this a direct competitor to Flutter.
Compose is getting quite popular despite still being relatively new. IMHO, if Jetbrains (or Google) get their act together and make that usable for IOS, there would be a lot of developers that would use that. I know I would. Flutter is not for me. I'm sure it's great but I have no desire to learn Dart.
We are currently using Kotlin js to be able to target mobile and web and kotlin jvm on our servers. We package up our app using Cordova and we have integrated a few plugins to e.g. do things with NFC. It works great. Performance is not an issue for us. And having just one code base and 1 UI team is critical for us. But I wouldn't mind some more options for cross platform development. Browsers are a necessary evil currently to target mobile and desktop with 1 application. But the boundaries between these platforms are increasingly artificial.
https://github.com/dart-lang/language/issues/783
It’s their payment platforms and Ads platform and a centrepiece of their upcoming operating system. It has literally billions of dollars depending on it. It’s not going anywhere.
https://9to5google.com/2021/10/10/google-ios-apps-native/
It's not going be that easy for them like with android. They had WearOS for a while and I bet they had give some big carrot to Samsung so that they finally use it instead of Tizen. Same with Google TV - Samsung prefer tizen, LG sticks with webOS. Google's IoT platforms (forgot the name) were a flop. Chromebook - mostly irrelevant and devs don't want to write software for that - recently they killed Chrome App Store.
* Payment * Video with DRM
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/
https://microsoft.github.io/code-push/faq/index.html