Flutter is the most popular cross-platform mobile SDK
stackoverflow.blog
stackoverflow.blog
Search Query "Flutter" in Job Posting Title: https://www.indeed.com/jobs?as_and&as_phr&as_any&as_not&as_t...
Search Query for "React Native" in Job Posting Title: https://www.indeed.com/jobs?q=title%3Areact%20native&l&vjk=3...
That said, it may also be a quality indicator: maybe RN users just have fewer problems. Maybe RN community members are better at documenting problems and their solutions outside of StackOverflow?
Flutter is where RN was three/four years ago, it's far too early to even think about calling it the king of cross platform.
- Learning a framework is still usage of the framework and so even beginner questions lag "usage" statistics
- Learning a framework is prior to "[Production] usage" of the framework and so beginner questions lead "[Production] usage" statistics and job descriptions
I think I lean a lot more towards the first take, especially in our industry: in general we aren't paid to learn new technology stacks, our companies don't budget for such training costs, and generally don't like it done on company time. Sure we make a big thing about "we are an industry for passion" and often force software developers to moonlight and learn things on their own time/dime "as a hobby", but I wouldn't like to think there are enough moonlighters and "hobbyists" to make something "popular" on Stack Overflow with just beginner questions.
When my team struggles with a new library or stack, we go to the maintainers' Discord. Most of them seem to really want people to engage there.
It makes sense that there are fewer "new questions" about an older technology. They've already been asked, you just need to look them up.
Flutter for web exists, but all those answers are lumped in.
But particularly on iOS, the native components have some incredibly subtle behavior (eg. the "fling" gestures from UIPageViewController, the native modal animations, overscroll, etc.), and these are extremely difficult to get right.
React Native's story for native inter-op has recently become miles better with JSI, which allows native<->JS FFI at much better performance than the previous approach. This has enabled libraries like Reanimated 2 (https://www.reanimated2.com/) and Gesture Handler 2, which take full advantage of this and get React Native apps tantalizingly close to "truly native"-feeling.
I was gonna say, “look, Flutter looks like peering at a screen through a fishbowl, responds like your hands are in some kind of jelly glove, and feels like you’re two martinis into happy hour,” but technical responses are of course better appreciated with this crowd.
https://github.com/flutter/flutter/issues?q=is%3Aissue+is%3A...
A lot of apps end up using at least one if not a lot of web views, I probably wouldn't use Flutter because of it.
The particular use case I was looking at was integrating a web based rich text editor based on contenteditable. It had to be a proper webview, and the issue is that the interaction with the text (cursors/selection/typing/onscreen keyboard) was completely broken.
Flutter's UI can't match native components exactly, but they do a very good job, and I don't think the vast majority of users would be able to notice the difference or cares that much.
The reality is, the native UI homogeneity is long dead anyway. Every app, website, brings it's own set of UI components and styling. It's all inconsistent and people are used to it.
It really does not matter whether your modal dialog is native or not, as long as it follows basic abstract UX conventions of looks and behavior.
Users do notice these things. They just can't explain it in technical terms like "i feel like this app is built with a non-native toolkit that is why animations are wrong".
They explain it as "this feels off" and "why doesn't it run like X" and "I don't like it" etc.
This "fickle group of users" is eager to spend money, moreso than other groups of users.
I'm happy a significant portion of consumers have been trained to expect better than the bare minimum in terms of UX.
Also they're rich.
Some apps also fail by trying to emulating native UI so hard, when it would be better advised to just adopt a more abstract style. Today's flat UI is just simple shapes after all.
From technical a standpoint, Flutter definitely is performant, capable of delivering smooth scrolling and 60 fps. Your experience may vary of course, but I've been shipping an app with it for 2 years now and things been working out well. Can only really say great things about it.
That is, indeed true. So the question becomes: does the framework nudge you towards and help you with making well-made apps almost indistinguishable from native apps, or the opposite :)
At some point, you're better just doing your own thing rather than be dragged around on the leash of some product manager looking to make a splash at the next conference.
It’s far too easy to be scrolling, accidentally go slightly too horizontal and end up popping the view and losing your place.
Yes, i know that it runs wrong because its ReactNative and not SwiftUI, but you don't need to know why its wrong to know its wrong.
Eg: Alexa App doesn't go back a frame when you swipe from left, you have to click back button.
This is the key point where Flutter wins over both React Native but also the native Android and iOS toolkits. When you design a screen in Flutter, it will behave as you expect on every different version of Android and iOS. You just check it does the right thing as screen size changes (which is usually pretty easy to implement, and very easy to test) and then you get predictable behaviour. It is so rare that you need to fix X screen on Y phone running X version of the OS because it has odd behaviour, and that happens all the time with any of the native toolkits.
That said - I haven't used Swift UI, so it's possible the situation has improved (although I wouldn't bet on it).
Really what way? Make a backend endpoint? Convert to C++ and invoke as native code? I'm only speaking for react native it's more than sharing code it's sharing skill, a web/nodejs dev can learn it and jump on company's mobile app when needed, as opposed to have dedicated devs for Android and iOS who sit around doing nothing sometimes and stop company from shipping when they go on vacation.
Lest anyone read this the wrong way: you absolutely can embed native components in your Flutter app. They have a scheme called "platform views" that involves splitting the scene hierarchy above and below a native component, and this is used for stuff like web views or map controls that are firmly native components which people want to drop into their app.
I see lots of Dart skeptics here. I was too when I started but Dart is great and better than JS.
I’m a Go developer by profession and Dart feels similar in ways. Simple language, simple type system, easy to learn, only one way to do things. Great compiler, great debugger, good ecosystem, good performance.
The complaints about widgets feeling off on different platforms is fair. My app is a totally custom UI so it doesn’t matter.
My favorite feature is the widget testing framework. It’s really easy to run the actual app and interact with it and verify UI interactions, UI state, app state and even UI pixels.
My frustrations are:
- cross platform system packages are of various quality and feature support. Someone in the ecosystem has to build the libraries with native bird and message passing to the flutter interface. I’m constantly surprised how much exists but when there are bugs or features missing on one platform it’s some major work to get it addressed.
- app initialization, lifecycle and navigation and routing took a long time to get right. Some more conventions on overall project structure and better getting started templates would go a long way.
The monolithic language and framework will be an advantage to some and a turn off to others. As a solo hobbyist, it’s a super power to get all these platforms at once.
Hm that's interesting to me. As a Go dev I just felt like "welp, I'm in Java."
I don't dislike it, but it doesn't feel nearly as light.
I've been working on a video call app for fun and have certainly noticed this. On the surface it appears possible to write such apps with Flutter. The reality though is that the implementation depends on half a dozen or so third party plugins with varying degrees of quality (and a small enough ecosystem to afford very little choice). Not to mention the inconsistencies with how they work across Android and iOS, although there's little which can be done there. At this point mostly everything's just adapters and other integration glue. If it ever goes beyond a hobby project I'll probably write native versions for each platform.
Hopefully it doesn't catch on.
I've taken it to mean: You don't know it, you might not particularly want to be using it, but you have a specific requirement and a deadline.
eg: "Plumbing in Anger" I would expect to distill enough to fix a sink or install a toilet or something, and tend towards a bundle of task-focused items/outcomes, and less on the "Gestalt of Plumbing".
I strongly suggest aspiring dependency manager authors read these
https://research.swtch.com/version-sat https://pnpm.io/faq
before building yet another broken package management solution. This is a huge problem in the Lisp community too but their problems are worse. Racket doesn't have lockfiles. Same problem with quicklisp. The alternative replacements like Racksnaps don't support conflicting versions either. As far as I know, CLPM is the only modern dependency manager in the Lisp world though it is very poorly documented, barely maintained, and installing it is difficult. If you go to the racket mailing list, nobody seems to be interested in tackling the problem or even acknowledging that it exists.
Cargo/Go/npm, as you say, will try to "shade" conflicting versions, which is basically a gamble. It may or may not work at runtime because data exchanged between different nodes in the tree of dependencies may have conflicts that make them incompatible... so having module A depend on version 1 of X, while module B depends on version 2 of X, and then A and B exchange objects that depend on which version of X they use will cause issues... this will blow up at compile time in Rust, at least, if you expose X in the API of A and B... but even if you don't, it's still possible for a conflict to occur if the exchanged information is in the form of serialized data or generic collections.
Pub selects one version of each library. It has great tools like listing the currently latest versions of every dependency, or the currently updatable ones given your version constraints, it addresses Dart SDK bounds of each package and it just works greeat. Can you give an example of when it didn't work for you?
EDIT : in the Lisp world, the biggest package manager is Quicklisp[1] as far as I know... and it works decently! I think Ultralisp[2] might be somehow better because it updates indexes faster or something.
In my experience, Flutter is the worst cross-platform mobile development tool; except for all the others.
[1] Time Cop: https://github.com/hamaluik/timecop
Different languages place different constraints on package management. For Go:
1. The language is structurally typed. If A gets a value from C 2.0 and passes it to B which expects a C 1.0 value, as long as the interfaces are structurally compatible, it will compile. (Whether it runs correctly is a completely open question. In principle, it won't because C is explicitly saying that 1.0 and 2.0 are incompatible. But there's nothing in the language to prevent a value from one version of C being passed to a function from the other version of C.)
Dart (like most languages) is nominally typed. If you have a class named Foo defined in two different libraries (or different versions of the "same" library), they are considered different, unrelated classes. If Dart were to allow multiple versions of the same package, then users will run into compile errors like "Expected a Foo (1.0) here but got a Foo (2.0)."
2. Code size is relatively less important for a primarily server-side language. Most Go developers don't really care how big their executable is as long as its within reason. Want to compile in five versions of some package? No big deal.
Dart is designed for client-side mobile apps, both native and compiled to JS. That means small code size is an absolutely critical performance requirement. Silently allowing multiple versions of the same package even when it's possible to find a single version that satisfies all constraints would bloat applications for no benefit.
This was historically a problem when people started trying to use the Node/NPM ecosystem in the browser. NPM freely gives you multiple versions of packages and the end result was large apps that weren't friendly to running in the browser. NPM added shared dependencies later to try to mitigate this, but now you've got two ways to manage dependencies and the extra complexity that entails.
3. Go chose to bake the major version number directly into each import in the source files. This makes imports unambiguous in the presence of multiple major versions of a package. But it means that upgrading a package to a new major version is a sweeping transitive source code change even when the new major version is in fact backwards compatible, which is the common case.
For Dart, we wanted users to be able to rev versions more easily than that and keep version management outside of source code.
> Dart's authors decided to use the traditional Java style package management algorithm (which in the worst case, on paper at least, requires NP time constraint solving but this is rarely an issue in practice).
Pub is most closely based on Bundler (which in turn informed the design of Cargo), and not Maven/Ivy/Ant. You're correct that version constraint solving is NP-complete. Fortunately, we have a state of the art solver [1] and it generally finds solutions very quickly. When it fails, it tends to fail fast and report helpful errors.
It's not perfect but there is no silver bullet for code reuse, and package management is fundamentally about code reuse. Code reuse is hard and anyone claiming they have a solution that makes it easy is most likely sweeping some unsolved part of the problem under the rug.
Cargo can have multiple copies of the same dependency and Rust is (mostly) nominally typed.
https://doc.rust-lang.org/cargo/reference/resolver.html#vers...
I never understood why you would want this to ever compile, especially as the default. There is no way to guarantee that two versions of a library loaded into the same program will work together, so of course you want the compilation/package resolution to fail if this happens.
Now, in some rare cases this may not be a problem, so it would be nice to have an escape hatch to permit this highly unusual use case, but it certainly can't be the default in any sane technology stack.
- Text Fields are almost unusable for iOS users that don't have predictive keyboard enabled. Reported in 2017: https://github.com/flutter/flutter/issues/12920
- Emoji rendering is broken on iOS. Reported in 2019: https://github.com/flutter/flutter/issues/28894
This is due to the fact that everything, including the OS controls, are re-implemented in Flutter.
I get consistently good reviews about performance and ux/ui.
I think it's quite ready.
Just curious, how much time do you think you put into it in total? App / web
Also curious how you marketed it, if at all
I'm monetizing only through subscription. I made it part of my mission to refrain from all ads and focus on privacy as much as possible. For the next version I have removed Firebase Analytics and Crashlytics as well.
The subscription for my app is half as expensive as the one from other apps on the market. But there is a rather hard point where you kinda have to buy PRO. That's if you want to track more than 15 stocks.
I put in around 1000 hours so far.
Android 70% of the downloads and 60% of the revenue
iOS 30% of the downloads and 40% of the revenue
Generally, there are a lot more Android users outside of the US.
Thanks.
> Text Fields are almost unusable for iOS users that don't have predictive keyboard enabled.
"Almost unusable" sounds like you can't type, but really it is just missing the autocorrect popups. And if you check the comments, somebody provides an implementation that does show them.
> Emoji rendering is broken on iOS.
This makes it sound like it doesn't show emojis, but really they're just slightly too small.
On a phone, the synergy of autocorrect and fat fingers is a delicate one, and even small changes can really upset the typing experience.
Samsung once updated the keyboard on my phone, and the different visual cues and behaviour completely threw off my muscle memory and made typing very difficult.
Even the autocorrect mode being wrong on an email input can be annoying, so a whole app acting up would be even more unpleasant.
They all have their strengths and weaknesses, you should always chose one where the strengths align with your app and your team. I see it something like this (of the ones I know enough about):
Flutter - Brilliant for somewhat simple apps talking to an api that don't need to share any ui with the web. Sonos is a brilliant example. Banking/Utilities, Smart Home, Restaurant/Takeaway (I think here in UK the Pizza Express app is Flutter). Things that need a "flashy" but consistent ui. In many ways I see Flutter as the new Adobe Flex/Flash.
React Native - Brilliant where you need a more native feel or need to drop to native more regularly. Good WebView support if you need them, mixing web and native views together. Also good to extend native apps. Facebook and other social media apps are a good example.
Ionic/Capacitor (or the older PhoneGap/Cordova) - You have a small team and need to get a fully cross platform app (web/mobile/pwa/desktop) done quick. If you are just calling a few HTTP apis (a CRUD app) and rendering some screens you can't be more productive than with this platform, particularly if sharing views with the web. Brilliant for enterprise, or internal apps. Good examples are the UK NHS apps. Performance on any mobile hardware less than 5yo is better than good. I have used NativeScript with Capacitor, they work very well together when you need to access native functionality not available with the standard capacitor apis.
(I don't know enough about Kotlin and its cross platform tools)
Rendering to a canvas does not "work reasonably well", unless you want to go back to Flash days (but controlled by google this time)
Blazor, Uno, Qt, Yew, Flutter,....
The craziness of faking UIs with paragraph tags massaged via CSS and JavaScript into a drop down menu.
Now they are back, even Google Docs is moving into it.
[0] https://yew.rs/
(And I sadly just can't buy the philosophical issue anyway, frankly: if anything, I'd argue the biggest flaw with the web is it has a million nit-picky features when it should ONLY offer JavaScript+canvas, as third parties have a hope of reimplementing that correctly, unlike HTML+CSS. To the extent to which there were important behaviors people liked, such as accessibility, those should come from higher-level frameworks instead of being baked into the lowest level of the system.)
That would break the web, though? One of the biggest _strengths_ of the web is backwards compatibility.. I, for one, am grateful to use modern browsers to consume older content and apps.
> behaviors people liked, such as accessibility
lol
(As for accessibility, I appreciate you might find my wording funny, but it isn't a laughing matter really.)
Type some CJK in here and watch as each letter appears 500ms late, or try to bring up the emoji input on MacOS
https://flutter.github.io/samples/web/form_app/#/form_widget...
From my experience anything you could have done natively you can bridge to RN.
So either create a native app if you have resources, otherwise, create a RN app and use either custom or community extensions.
That's the beauty of the flexibility and extensibility of React.
React Native Web works so well I use it as my main for even web-only projects.
You basically get a mobile and desktop site for free with your app. Or native apps for free, whichever way you look at it.
Non web-devs seeing the word "JavaScript" and running away. Or stated otherwise, having to learn React + the JS ecosystem (minimized within RN) on top of all the mobile specific stuff.
I had no previous experience with Android or iOS or the languages and was able to get caught up, but there was a curve to figuring out code signing, the app stores, deploying, permissions, etc.
For those non web-devs, they will have to learn some of web. You will need to learn the tooling like the other platforms. You don't really need CSS knowledge or HTML just basics. RNW implements RN stylesheets which is a streamlined subset of CSS.
The main thing is learning React, but SwiftUI was inspired by React so it should be easy for at least iOS devs to grasp it.
Xamarin is very popular in enterprise
React Native has a much larger ecosystem and feature set, including desktop & web targets, native view, many extensions, huge support, a lot of jobs.
NativeScript seems to just tie into native APIs, not the view layer, right? React Native bridges to native controls so you get native look and feel.
Flutter emulates the native view later by drawing everything itself which can be off, but it's performant at least.
If I preferred Web components, Svelte, Angular, or Vue I'd see the appeal of NativeScript.
React Native is not based on NativeScript though, they are two different implementations.
The value of cross platform toolkits is all about cost reduction. It is cheaper to staff up on a single skill set rather than to staff up on three entirely separate skill sets. As of 2022, that single skill set is most likely web SPA development.
Flutter and Dart are no where near as similar to React or Angular as Ionic or React Native. Even the most experienced web developer will need time to learn Flutter. There are also some positives to Flutter that you should consider. Of the three PoC apps, the Flutter app had the fewest lines of code and took the least amount time to develop (once you know Flutter).
> The value of cross platform toolkits is all about cost reduction.
what i want to know is, how do cross-platform tools lead to better software products (less bugs, faster iteration, higher quality features, smoother animation, higher performance etc) for customers?
I've seen several startups fail that spent way too much time obsessing over native UI/UX and ended up building the wrong product three times in parallel for three platforms at great cost as opposed to shipping something good enough much earlier and iterating on that. If users care about your app, it being native won't be the deciding factor. It's what it does; not how it does it that decides these things.
People obsess about native too much when they should be focusing on functionality and design instead. Form over function is a classic design mistake.
Whenever I search for something in React Native it's already answered in the past or has a regular React equivalent answered so I don't need to ask a new question.
Since Flutter is newer and uses a less popular language there's many more questions about Flutter. This is totally expected.
Call me tinfoil but I believe SO is really financially supported directly or indirectly to support Flutter over React Native.
Could you elaborate on this one?
I try to "reverse engineer" it and think "what would have caused these very smart people to write such a lame blog post that doesn't reflect reality" and that leads me to this conclusion.
Again, I just said I believe in this. Maybe I am wrong.
But I really try to be realistic and frankly can't see Flutter being truly more popular.
But just because I favor React Native over Flutter doesn't necessarily mean that I'm biased and there's no truth in what I'm saying.
It's more complicated than your proposed cause & effect. A counterexample is that Rust is much newer than C++ and yet C++ still has higher volume of questions using Stackoverflow's trending tool:
https://insights.stackoverflow.com/trends?tags=rust%2Cc%2B%2...
This matches real world observation that C++ is still more popular and widely used than Rust.
I don't have the raw data but I'm guessing that even if Stackoverflow compared Flutter-vs-ReactNative # search queries instead of # of questions, Flutter would still have a higher count.
Another article highlighting Google Trends[1] shows that Flutter surpassed React Native around 2020: https://www.nomtek.com/blog/flutter-vs-react-native
[1] https://trends.google.com/trends/explore?date=2018-01-02%202...
Flutter: 87K, Initial Release: Mar-2015
React native 88K, Initial Release: May-2017
I think growth rate of Flutter is higher than React.
However, I do agree that RN has the momentum and familiarity of React as tailwinds.
It's newer, has a less-known language, learning React Native is very easy for existing React developers so less searches for how-tos.
It still doesn't reflect reality.
Thank you for bringing up a very good point. There's definitely manipulation going on. I've never used Flutter, but this blogpost doesn't reflect the impresion I get on HN regarding Flutter or even Google in general.
Many/most developers — at least in the tooling world — are Linux people, so we get these cross-platform tools based on Electron and Flutter that everyone insists are either “good” or “good enough”, and it makes me feel so bummed about the state-of-the-art, that our hardware is better than ever and we’re just throwing it away on this crap.
No, your cross-platform app is not indistinguishable from native, or good. It is probably good enough, here’s a participation ribbon.
Usually you wait til someone gets fed up and builds a GPL-licensed clone.
It has two fundamental mistakes, each of which is probably fatal.
(1) non-native controls. The problem is it takes a lot of work to catch up and keep up with native controls. This is a cross-platform SDK, so multiply that by all the platforms. You end up doing a massive amount of work to achieve a lowest-common-denominator, janky, low-quality experience.
(2) custom language. There's a lot of unnecessary friction here.
Maybe Google will keep paying for it anyway... but I doubt it.
It felt like they couldn't use it for anything else so it was mandated that people use it somewhere.
I can't help but infer that Lars is quite often a little bit frustrated with the emergence of Typescript. But on top of it being embarrassing for me to imagine up such personal rivalries based on hardly anything, you could view the interview as Dart-hostile given the interviewer.
Dart (as of 2.0) has a sound static type system. It's just an easier language compile well.
Typescript would not have been a plus for me.
Now it's clearly a success because the alternative is Phonegap and all it's offspring ( ReactNative kinda included ). It's compelling enough for people to learn a different approach to UI building ( new for most people coming from Web ).
There always be a "lowest-common-denominator", but with Flutter and for most types of app it's a pretty high denominator.
If you have a webapp built in React, it's going to be very easy for you to spin up a React Native app, mostly because you can pull those React devs into RN without much of a fuss. With Flutter/Dart though, you will have to hire outside specifically for the role, even if you hire a "React Native" developer, it will be easy to transition that dev to regular React if org needs change, Flutter/Dart are more brittle in that way.
Flutter will never provide native feel and that's not the point.
In the limited mobile ecosystem of Iceland for instance, there are no positions advertised for native mobile development, only Flutter/ReactN.
I am probably going to end up using Flutter for a couple more projects. As a config tool for a bluetooth enabled product. And then I was going to abuse its web and desktop views for a local UI for another device. Not 100% sure that will go great.
But Dart has been decent to use. Once you figure out how to navigate its type system its as easy as any other language.
1. Flutter's docs are missing a lot of critical information. For example, try understanding the docs on the Navigator 2.0 API or finding out how to make an app launch screen.
2. Flutter is missing a lot of critical functionality. For example, try writing an integration test for a Flutter app [0]. You can't because the tooling is broken and Flutter Team refuses to fix it. Or try adding a keyboard dismiss button to your iOS app [1]. Also, when debugging Dart code, there is no way to inspect scheduled async tasks, so debugging concurrency issues is excruciating work.
Flutter Team has made little progress on mobile functionality in the last two years. For example, dark mode on iOS was left half implemented, with widgets requiring complicated workarounds to even be visible in dark mode [2].
Flutter's version number is 2.10 but for iOS it is actually a pre-1.0 product.
Flutter Team seems to have abandoned Flutter mobile and is entirely focused on web and desktop now.
I'm a solo entrepreneur and I regret choosing Flutter for my mobile app.
[0] https://github.com/flutter/flutter/issues/45076 (Flutter Team member added some missing functionality, ignored the most important missing functionality, closed the issue, then the bot auto-locked it.)
[1] https://github.com/flutter/flutter/issues/88549#issuecomment...
This mirrors how Google is also using canvas in Google Docs and basically abandoning the DOM.
This gives them so much control — they’re writing directly to the canvas, they’re not relying on any platform rendering - but also means they need to take over so much of the look and feel and affordances that the platforms provide natively.
This definitely isn’t the kind of tool for everyone but seems super useful for some use cases.
The reason we are moving to Flutter is the limited size of the development team (only a handfull collectively working on both platforms). In that regard, being able to share the codebase has been a massive boon to productivity.
However there are tons of issues that come with Flutter, just like any programming language and framework. Like the article mentions, the third party plugin ecosystem is nowhere near the maturity and stability that one has come to know from the Android & iOS community. Packages sometimes get left behind and not updated for ages, which causes various issues as new versions of the platform OS's come out.
Dart is also a very verbose language, and it really took a long time to get used to the noise it generates on screen. The lack of proper null safety until only recently had also been difficult for the team to get to terms with.
In our case we are also integrating Flutter along with our native code base, which opens up all kinds of other cans of worms then when just using Flutter standalone.
To me it serves a purpose, and is another tool in the toolbox. I am however much more excited for the possibilities that come with Jetbrain's new UI framework Compose.
I'm working on a multi-front-end, multi-back-end UI framework called Nexus. The initial front-end will be Flutter and the initial back-end will be Nim (Python following soon).
- Can’t share code between the web app and the mobile app
With React being prevalent on the web front, why would anyone do a Flutter web app + mobile app?
Both will perform well, I've made advanced applications on RN that perform well.
https://docs.flutter.dev/development/accessibility-and-local...
I mean, Flutter is stupidly good at this.
The downside is, that it doesn't implement the platform look&feel perfectly. If you want fully custom look and feel, it might be not a bad thing, but those who aim at native experience, they will never reliably get it.
---
On the other side of the debate, React Native, it is not all roses either. While it uses native widgets, it also runs JavaScript. And not just any JavaScript engine, or your preferred JS engine, but JSC. With JSC, RN team took their sweet time to support 64-bit Android properly, with issues rearing as late as 2020.
Since then I learned that most users do not give a s...t if it's pixel in pixel perfect copy of native components. Especially when Flutter team makes it literally pixel in pixel perfect to the native UI. I mean, it really doesn't matter in 99.99% cases in my experience (I have around 12 apps in Flutter atm).
So I see this Flutter design feature as huge upside, not a downside.
- Supporting older platforms is much easier with Flutter.
- You can use native UI components with Flutter if you want to, and mix them with Flutter widgets.
- Flutter has a tiny and fast runtime, React Native runs on Safari or Chrome. Flutter works great on embedded platforms too, such as IoT devices.
- Dart is similar to JavaScript, with the same runtime behavior, though obviously you can't use existing JavaScript libraries outside of the browser. You can use many WASM ones though.
How can I make flutter use native font rendering? I've played around with it a bit and fonts look completely off, don't respect my systems hinting settings, etc.
You should open an issue if your font configuration is not applied, although on Android, iOS and macOS font hinting is not relevant, and I think on Linux fontconfig is used. I don't know about Windows.
https://reactnative.dev/blog/2021/10/26/toward-hermes-being-...
If you're going true cross-platform across Windows, macOS, and Linux, I think it's hopeless to try and maintain three separate apps that look and feel like a supposedly native app should look and feel like, if there's such a thing anymore. Windows and macOS are not even consistent for their own apps and OS GUIs.
France just had one of the worst fiasco in the history of mobile app (fresh from this month) : the national train company, which everybody uses to book train tickets, just revamped its mobile app and websites, which were working just fine, to rebrand it and apparently redevelopped everything.
The mobile app is a total crap : worst ergonomics, but most of all, it is lagging on every scroll, even on an iphone 12, even for the almost static homepage.
When i saw that, i told my friends "the last time i saw a scroll that lagged that much, it was a flutter demo app". So i googled "scnf connect flutter". And i stumbled upon the press release for the release of the new app, explaining how proud they were of having bet on flutter.
Flutter and Dart go hand in hand as the only thing people use Dart for is Flutter.
If you want to compare them you need to add React Native + React + Javascript questions together and then you'll realise how tiny Flutter is in comparison.
As someone else said - I can't even find a single Flutter job in my country but there are dozens posted for React Native daily.
Flutter is definitely a legitimate cross platform choice but it's nowhere near the most popular one.
- QtFramework: 3.8k member
- FlutterDev: 87.0k member
That being said, the Flutter widget model is remarkably simple to understand. And rules like "Constraints go down. Sizes go up. Parent sets position." make it pretty easy to reason about the UI. State management is a bit of a hurdle, since there are so many options, each with its own advantages and disadvantages.
All in all, this was a great choice for building something that works on both mobile and desktop, and has a fast startup time.
> In July 2020, 2.6 billion people (36% of the world population) use the Latin alphabet.
If you include languages that don't use the basic Latin script (26 characters or so), it gets even worse, since 90%+ of languages that use it have extra characters.
Dear Google, we will choose your framework if we want to learn your language before you cancel it and your bloated locked in framework that emulates native decently for now and sucks on web.
I much prefer React Native and from my perspective it's winning out by far, especially with react-native-web. The entire stack is flexible and extensible.
This is why I left dart ecosystem last year, thanks Google. At the beginning or 2020 Googlers promised full support of AngularDart, saying that they have a lot of internal websites developed in it and adwords is in AngularDart, they were fully committed to making it a competitor to angular and typescript. I discussed it on one meetup and met a technical startup founder that decided to go this way, one language for web, android and iOS. A year later AngularDart was soooo outdated that it was impossible to use cross platform. AngularDart team didn't even bother with a proper announcement or giving us notice. They updated wiki on github saying that it won't be supported. I have no trust in Google giving us anything good.
I've seen this but never heard of anyone using it. Do you have any notable examples of serious production apps shipped with this?
[1] https://webcache.googleusercontent.com/search?q=cache:https:...
It's a really nice React library, I go to it even for web only apps. The CSS-in-JS engine meets all the expected performance features like atomic css.
Do you have any notable examples of a Flutter web app being used in production? I assume not because of accessibility isn't ready, along with the many other issues.
You posed the question if there were any notable examples of RNW used in production because you haven't seen any. (it's on their home page)
I answered who is using it and simply posed the question if there were notable examples of Flutter Web used in production because I haven't.
If you knew enough about RNW to look out for sites using it and pose a question about it then I assumed you knew enough about Flutter to do the same?
That it exists, it's general purpose, and given it's semantic version that it's pre-release software. That's all I know about it. I know a little more about Flutter since it has a marketing budget.
It probably wouldn't be wise to rely on either of them outside of hobby projects. Unless of course you are Facebook/Twitter/Google, aka have effectively unlimited budget and employ the people who wrote the stuff to begin with.
That's why I asked. You asked about RNW because you hadn't heard of anyone using it, I asked about Flutter because I haven't used it and don't know anyone who does.
> It probably wouldn't be wise to rely on either of them outside of hobby projects. Unless of course you are Facebook/Twitter/Google
I rely on RNW and RN everyday for a production app (iOS/Android/Web) with thousands of DAU. I developed and maintain the app solely.
Curious what's not working in Flutter's accessibility. We are aware of multiple bugs, some specific to a particular assistive tech not interpreting our ARIA attributes that we need to work around, but our accessibility support is rarely described as not ready.
Does React-Native have an exclusive forum, IRC channel, or Discord server?
One creator of a famous Deep Learning framework regularly blabbers on Twitter about the framework being the most popular one based on number of SO questions, where the actual most popular one has an exclusive forum for all questions.
Is that the case for React-Native? I wouldn't know.
Most problems and questions that developers encounter while working on React Native applications are not specific to React Native, but rather React itself. As such, I find it likely that many RN developers don't always use "native" in their search terms.
It wouldn't be such a bad thing if the writing of native plugins wasn't such a big hurdle for the average developer. The vast majority of mobile and frontend devs have never done anything with FFI, it's not the easiest thing to learn compared to other more documented skills, and it requires doing what most cross-platform devs wanted to avoid in the first place... was writing in some other compiled language they have little knowledge or interest in.
So far I don't think any particular cross-platform mobile SDK is necessarily better than the other in an objective sense. For the most part all end up taking a dynamic language runtime and stick it on top of a GUI toolkit, whether it's a web view or something a little closer to the metal. People act like any combination of these facets are significantly better than each other, but every few years we get the next generation mobile SDK and then a year later we find posts on HN laying out how the marketing points of said SDK didn't pan out in the field (case in point; no one really talks that much about React Native, Titanium, or Cordova anymore, but Flutter is the hot thing I keep hearing about as of late).
A cross-platform mobile SDK can stand out if it can nail the story around plugins. Maybe that means implementing a native-development layer with a language like C++, kind of like Qt. Actually, Qt already is one answer to this question, except its answer to interface design and implementation is this weird QML thing that applies nowhere outside of Qt.
The problem is also that different platforms require totally different implementations of a certain feature, e.g., background audio in android requires a service whereas on ios just a capability flag...
You have to let it go.
a = b ? c["${d}"] : e;
...I think don't compile. You have to write
a = b ? (c["${d}"]) : e;
...for it to compile.
I'm one of the developers of Dart, and I just tried to reproduce your bug. Here's what I tried:
int? f(bool b, Map<String, int> c, int d, int e) {
int? a;
a = b ? c["${d}"] : e;
return a;
}
main() {
print(f(true, {'1': 10}, 1, 20));
print(f(false, {'1': 10}, 1, 20));
}
Can you say more about what you were trying to do when you ran into this bug? Ideally file an issue at https://github.com/dart-lang/sdk/issues/new. (We really do read and respond to them, and if you find a bug in the grammar, there's a good chance I'll be the one to fix it!)
clientTable?["seat${seat}Pot"] += clientTable?["seat${seat}Front"] + (clientTable?["bettingRound"] == 1 ? (clientTable?["seat${seat}Dead"]) : 0);
compiles
clientTable?["seat${seat}Pot"] += clientTable?["seat${seat}Front"] + (clientTable?["bettingRound"] == 1 ? clientTable?["seat${seat}Dead"] : 0);
doesnt
good luck fixing this :)
it's intriguing, but is it battle hardened?
Flutter would probably be more popular if it didn't use Dart (e.g. Kotlin), which also means it would receive fewer mentions on StackOverflow. That's exactly the phenomenon we are seeing with React Native.
To me, the only real, tractable metric for assessing how popular a technology is is by looking at job postings. And from that perspective, Flutter is nonexistent.
I've therefore decided to write my iOS app in Xamarin.iOS, instead of a cross-platform solution like Xamarin.Forms or Flutter. The Xamarin.Android version already works perfectly, but my attempt at a Xamarin.Forms version had dismal performance and simply couldn't match the native Android version.
Also try looking into xamarin's successor "Maui" which I have been playing with and am impressed with the speed and code organization, even though it is still in beta/preview.
Now with MAUI we're moving into yet another long period of instability and change. I'm fed up with this.
Flutter for web flies in the face of all accessibility standards and tooling, and will make it impossible for extensions and interoperability with the Open Web. The path Flutter is going down is one in which the web browser is simply a canvas that pixels are blitted onto from a web-incompatible language (Dart) that interoperates with nothing else and requires reinventing everything that makes web applications work well for millions of people that face accessibility challenges. And of course, for page isolation, it means that Flutter will have to reinvent iframe-esque sandboxing and RPC to support ads. (More on that at the end.)
Rendering real text blocks, links, alt text, etc., ensures compatibility with screen readers, non-mouse navigation, accessibility modes including magnification and high contrast, and enables real interoperability/embedding with an open web.
It may come at a high engineering cost, but surely not at a higher moral cost than locking out millions of users from using apps, or a higher cost to the principle of an open web than removing the ability of end-users to integrate HTML, CSS, JS in the same web application as a Flutter Web app.
React Native Web does this by providing escape hatches that allow, e.g., iframes in web applications, and rendering to HTML/CSS/JS by default to ensure compatibility with web standards. It is not impossible.
See: https://flutterplasma.dev/
This page cannot be interacted with by a screen reader, by keyboard shortcuts, and so on. Even the text highlighting, ability to copy paste text had to be reinvented. The browser is not highlighting text, and ctrl-C is not copying characters that were highlighted. That's all being done by Flutter re-implementing an entire rendering stack.
And the future of this, of course, is advertisements rendered by Flutter in Flutter apps. We all know this is true, even if Flutter developers might deny it and say they have nothing on their roadmap to do this. At some point, people will want to integrate ads in their Flutter app to monetize them. And how will they do that, except by including some snippet of code in their Flutter app that leaks user information or provides a remote-code-execution-as-a-service to advertising networks, if Flutter doesn't reinvent the wheel to sandbox and isolate code snippets and composite the ad into the canvas? And we'll have come full circle then, Flutter will have reinvented - again - everything a browser does just to wall itself off from the rest of the world.
And at that point, since the entire web browser is just the end of a pipe pixels are blitted onto, users won't be able to say no to yet another form of intrusive advertising.
Dart is nice but it lost, TypeScript has won for many reasons.
I'm looking into how Basecamp created hey.com mobile application.
I'm just kidding, they don't use it either.