Ask HN: React Native or Flutter for a new app in 2023? | Hacker News Reader

Ask HN: React Native or Flutter for a new app in 2023?

66 pointsdjanowski105 comments

App has typical requirements plus some interactions with OS native APIs.

This is a startup so the returns of using a single development platform to target iOS/Android seems unquestionable.

I would say Flutter. Performs much better than React Native.

Upgrading old RN version to new RN version has always been a very painful experience. Flutter in our experience has been easier to upgrade.

Also Flutter has support to call native APIs using platform channels. (https://docs.flutter.dev/platform-integration/platform-chann...)

At my company we have multiple Flutter Apps in production. The experience has been quite good so far. In fact we are converting some of our native projects to Flutter in order to reduce the maintenance burden.

I'm not primarily a mobile dev but have done enough Android/iOS appdev to prefer Flutter. Even if it was only for the Android version of an app, I'd choose Flutter over Android APIs because it's so fragmented and janky in its own ways. RN to me is the worst of both worlds (React + Android quirks).

Of course it depends on the app, if it has specific not-run-of-the-mill UX requirements. It's also better to start with Flutter (or RN) rather than switch from something else, as the feel is so different users would be put off by the change. Each is fast/slow in different places/ways.

Purely curious; why not start natively with iOS or Droid (depending on which one your target audience uses more)?

You'd have the easiest native API access and fewer headaches. Once you hit PMF & have proven the idea, add the second platform.

Is there a benefit to launching on both platforms out of the gate? Unless perhaps there are specific React web assets you'd like to reuse to get up and running faster via React native.

> Purely curious; why not start natively with iOS or Droid (depending on which one your target audience uses more)?

For me, React is just easier to use than natively supporting iOS or Droid. No new languages or skills to learn.

I also found for social/marketplace apps, Droid users are the supply and iOS is the demand. Can't have one without the other.

Yeah if React is your strong suit, an initial version in React Native is the way to roll.

With Swift UI & Jetpack Compose, I found it really easy to make a jump from React to either platform. The mental model is pretty similar to React in both. Sure, Android is still a lot of boilerplate (in my opinion), but Kotlin & Swift are also relatively easy to get into, especially if you happen to have some OOP experience.

> Is there a benefit to launching on both platforms out of the gate?

I guess the benefit is access to larger audience, and as a result easier growth; this could be especially important in the context of a startup.

Yeah - however IMO large growth isn't as important until some semblance of PMF is hit with a few core users.

Then can treat the other platform as a marketing cost - i.e. if you're making 75k on iOS and predict a similar revenue for Android it's worth it to hire an Android developer for to build it out. But if one hasn't yet found a few hundred quality users on one platform why build the other one.

For some apps, cross platform mobile development and finding core users across larger audience can be easier than going native and finding core users on a single platform.

There can be probably other reasons too.

I agree with this and reflects my personal experience.

While potencial of a large audience is great, if you don't even have users to start with, the choice should be the response to "what gets PMF faster" and not "what do I need to take me from 500k ARR to +2M ARR".

Why target one platform when your project can target all major platforms (web, iOS, Android, MacOS/Windows/Linux)? Especially if you're already experienced with React and can later hire from that monstrous talent pool?

Hell, instead of casting that wider net for users, you could still only release/focus on iOS, but still have tons of work done when you're ready to move your React app to those other platforms.

Because your app will equally suck on all platforms?

You might not be the target user - and actual target users might not care about the native vs react native app UX.

Because your app will work on all platforms and the rest of the billions of app users outside of this little niche-of-a-niche-of-a-niche forum just want to do whatever they need to get done on a app in their normal lives and don't even know what you are talking about when you say the app "sucks" because it doesn't use exactly the right rounded corners on a button or the listview scroll physics are exactly same as a "native" app.

Until the people wonder why it doesn’t do $x new feature that Apple released a year ago but there is no cross platform equivalent.

But more importantly, why it doesn’t take advantage of an accessibility feature that that a native app would get for free.

this downplays the possibility of having competitors. if your idea either already exists or can be cloned quickly, being stuck on one platform while somebody else hoovers up the broader userbase can absolutely kill you.

> Purely curious; why not start natively with iOS or Droid (depending on which one your target audience uses more)?

That did not go well with Clubhouse. Started with iOS only and a year and a half later they added Android support after getting cloned by everyone else. Especially Discord (which is in React Native).

Today, more people use Discord Stages and almost no-one uses Clubhouse, despite Clubhouse being a native app from the start.

That's a good point - if the success of the product relies on a critical mass of adoption (social networks, marketplaces) then missing one platform would exponentially hurt that.

But IMHO for apps where that isn't the case starting with a single platform is a good bet.

> Is there a benefit to launching on both platforms out of the gate?

Well launching on both platforms at once is one benefit. But how about the benefit of writing code once?

And having access to a massive React developer talent pool.

Because you'll still want to support both OS's sooner rather than later and then you'll be re-inventing the wheel by rewriting all your code a second time on the other platform. Plus using Flutter from the start means you have the option of seeing a much wider world than just Android or iOS: you can build the same app for Linux, MacOS, Windows and the Web.

React Native. TypeScript. NestJS backend, NextJS frontend. The ability to easily share code across the full stack is underrated. Of course you need someone that thinks at that high level building it.

Always been interested in the idea of sharing code across the full stack. What do you find you can share the most?

APIs / data models?

> What do you find you can share the most?

Types.

Types (interface contracts) are already easily sharable with an IDL and code generation. There's no need to stick to a common programming language to share types.

I'm highly skeptical of code sharing for other scenarios, and rarely (never) have seen the effort worth the payoff.

- https://protobuf.dev/

- https://smithy.io/2.0/

See my other comment above, but I was able to share basically everything that was not UI code. Types, request hooks, utils, configs/constants. Probably about 60% of the app, and you wouldn’t want to share UI code anyway because web and Native are so different.

I made Tamagui (with much effort) to solve this, which has probably the best setup out there at the moment for sharing your UI code on the frontend: https://tamagui.dev

For backend we're working on a starter kit that puts together all the pieces (there are a lot!) that's days from release, if you reach out on the Discord I can help get you on as a beta tester. It uses Supabase for data and auth, which seems to give the best overall package for data and auth.

For state depends entirely on the complexity of app. For simple apps you can get away with just something like React Query and Reacts useState, for more complex one of Daishi's state management libraries (everyone has their different preference, I love the black sheep Valtio), or the new kid on the block Legend State looks interesting.

The biggest part is getting a monorepo set up properly with shared code. Again the Tamagui starter repo `npm create tamagui` has this set up and its a whole ton of work saved in terms of getting that right.

Looks really cool.

FYI, the Silkscreen font on the website is completely illegible at smaller sizes like in the menus. Looks like a rendering glitch. Might want to choose something a little more legible.

Are you using a very dense resolution? I've turned off anti-aliasing, but if you scale your monitor to be more dense than natural resolutions it will appear quite odd. At "normal" resolutions it looks fine. I could turn aliasing back on at the cost of a bit of visual niceness for most.

Yeah, probably. I’m not sure exactly what the pixel density is, but it’s 1440 vertical pixels. Maybe try a resolution media query to toggle the antialiasing?

Finally I have a relevant blog post!

Reflecting on Code Sharing React and React Native

https://matthewwolfe.github.io/blog/code-sharing-react-and-r...

Yeah this is my experience as well. You can share a ton of code if you think about it up front. But the UI is not worth it. So different.

On the opposite, I find that sharing code across full stack is becoming overrated. The reason I'm saying this is because that often leads to some very messy dependencies, and maintaining that codebase can become really difficult if you're not very careful.

Additionally, I found that in some teams, people would use some backend code on the frontend, resulting in some security vulnerabilities (server-side logic running on FE instead of BE). Instead, now that we have backend (Go) & frontend (TS) teams at my work, both teams consider the best practices for each environment with more focus. You could say that the same people do that with the same stack, but in my experience, if you allow people to put more focus on the one component they're building, they'll just build it better than when they have a plethora of other dependencies to consider.

The main problem could be talent, as if you have specialised people, you always have to hire for both of these positions (or train your people in either direction internally). But I honestly never experienced a shortage of people. It's more of a problem if you have a shortage of money, at which point, you should just use whatever you can build with the quickest to keep your business afloat.

Gonna say something controversial, the future of mobile apps is going to be webviews. It's already the case for desktop. iPhones are getting cpus that are close to desktop CPUs from 5 years ago and they can run 3d games.

This.

If reuse across platforms is of interest, a proper crossplatform webapp is a great answer.

Most mobile apps are already hybrid apps. It's just so much easier to develop it, especially if you already have a web app and some frontend code that can be reused.

Most apps don't need many native features, and the native app that wraps the web view can be quite minimal. Developing it directly in Xcode and android studio is usually easier than using some kind of multi platform abstraction like react native, flutter, xamarin, ...

Native apps mostly became something for companies with a big development budget >1m$ per year, or much more. Like Uber, Meta, Twitter and so on.

A good native app may be superior, but the gap is not huge. With a limited budget the hybrid app is probably going to be much better than the native app.

Another benefit of the web app approach: users can use it even without installing it, just in their mobile browser (maybe with limited functionality).

there is small issue with webview on android https://bugs.chromium.org/p/chromium/issues/detail?id=128974...

in my experience build pwa if low budget, build native android and ios if hight budget, development experienct is much nicer with android studio for android and xcode for ios, simple multi page application with vanila js is much nicer for pwa on web

Ive written a few android apps in webview, and I don't want to do it ever again. For small apps maybe, but large scale apps in JavaScript is a nightmare to maintain.

React native imo. Expo is terrific and the library ecosystem, while it might feel like it’s one step down from web JavaScript, is still robust enough for what you need since there are more than enough people out there shipping rn apps.

My only concern with Expo is once you're using it, you're going to get charged per user and per update. It's $0.005 per user per update (plus additional bandwidth and storage charges). So if you have 100K users, that's $500 per update. One update per month would be $6K per year. So you have to factor in the economics of your app.

There's nothing that requires you to use EAS Update though. You could just stick to submitting builds through the app store like normal.

I have no idea why you would pay that. Just eject.

Ejecting is an outdated concept when it comes to Expo for the past two years or so. The eject command in the cli is just an alias for the prebuild command even.

The way Expo builds your app these days let's you add native code as you want, modify your Gradle and pods files as needed, and you can still be on their managed workflow where you don't ever need to have Android and iOS folders in your repo. It's a really great time to be using Expo.

Thanks for that. One more reason, if I needed one, not to go native at the outset.

I would use Kotlin multiplatform and Jetpack Compose multiplatform. But mainly because I already know Kotlin. It's definitively nicer than typescript though.

Nicer than Flutter's Dart too.

The only problems with Compose Multiplatform are the lack of multiplatform libraries, and documentation, but JetBrains tells me that a new documentation site is due this summer.

But then you're in Android Studio land. Have fun when adb refuses to recognise your connected Anroid phone. I gave up and created a React web app optimised for phones.

I have little experience with mobile development; my primary target now is the desktop and I have a Google Pixel so I have not encountered such a problem. And I am using IntelliJ more than Android Studio though I had no problem with that yet either. It would be a shame if Android Studio were not the best platform for Android development.

Android development is just very janky. There’s just so many pieces that sort of work together, until they don’t. It is Kotlin compiling to Franken-Java with a thick crusty layer of compatibility libraries because OS updates are completely broken on Android. ADB and Gradle just randomly break sometimes. The emulator is slow.

I’m not surprised that people are reaching for Flutter and React Native instead.

I will acknowledge that and I do think it sucks. Even when learning kotlin, what bothered me the most was the IDE and the other tedious tools needed (maven, gradle, etc.). Why can't I have something like rustup that just gets the newest kotlinc for me? So I think it's a valid point you're making although I was able to get used to the ecosystem over time.

Jetpack Compose Multiplatform is in alpha status on iOS and Kotlin Multiplatform still has a a beta disclaimer on it, so I don’t feel like this is a good choice at this time. Something to keep an eye on for the future certainly.

Flutter is an awesome developer experience and would probably also make sense for small team that needs to support many platforms. I think I would target flutter if I had to support desktop OS.

React-native would probably be preferable if you are just doing iOS/Android/Web due to the maturity of the ecosystem and wide use in the industry.

Flutter's widget tree is an abomination.

Can you elaborate? I've found it a delight.

A heavily nested widget can be a little sore on the eyes. You can break up heavily nested widgets into multiple widgets though.

This is also common to JSX though so not sure what the "abominable" comment is referring to.

Yeah it's usually a sign that you're doing too much in a single widget if you end up with a crazy amount of nesting.

Exactly, it's so simple and transparent when done correctly.

Nothing beats native.

2nd best is what you know.

I'm using egui right now for quickly putting together a native cross platform tool. For a startup, again I'd pick what you know. RN and Flutter will provide similar experiences for most apps. Flutter will perform better with charts etc.

Sorry, time to market is important. What's important is getting your product out the front door, then iterating as you go on.

QT is also really great, depending on what your app is.

As an end user, Qt apps do not feel particularly great. There’s just a lot of weird behavior in them and they just really feel off. At least that’s how the official demos from the Qt Company feel. I’m not sure how a real production level app feels. I’m not aware of any major apps that use it.

Interesting. A lot of open source software uses it via the python bindings. What do you mean by feels? Slow? Look? Layout? Isn't it all os-native widgets?

On mobile I don’t believe it uses native widgets. I think the official Qt Company demos are done with Qt Quick. They just look off, the rendering of the controls isn’t quite right and some of them don’t handle screen rotation well.

It’s been a while since I’ve tried them though, maybe it’s improved but about a year or 2 ago I wasn’t impressed.

Yeah QT Quick is not using native widgets. If you use native qt components then it uses native widgets cross platform.

I think they do the demos in qt quick to appeal to auto makers.

I'm a massive egui fan but I don't think you properly compare an immediate mode framework to the retained mode behemoths of Flutter or React Native.

Mobile is ruled out. Some very basic things people take for granted like flex layouts are also incredibly hard to do right.

They have different use cases. That said, I love egui and have built a bunch of in-house tooling with it, such a joy to work with and uses barely any resources despite being immediate mode.

Actually I wouldn't call Flutter and React retained mode. They're basically fancy immediate mode. That's why React is so productive.

Flutter looks to be the same. Even google's docs say (paraphrasing) "isn't doing the layout every frame slow? No, because the runtime is optimized".

Not suggesting using egui btw, just off handed mention. :)

The problem with native is you need to write everything twice, and that's if you only want to support Android and iOS. Of course you can start by targeting just one platform, but then God forbid people actually like your app, everyone starts asking when it's coming to the other platform and you buckle under the pressure of recoding the same app and somehow avoiding all your technical debt from the first one.

If you have a team with 2+ devs, and maybe some actual users, then go for it. But are there any examples of single developers publishing an app cross platform, written natively for each?

I really don't see flutter surviving long term. As it matures it will accumulate hard to solve issues and making shiny new thing will be easier. Does Google have track record of maintaining these kind of projects?

Several large Chinese companies are quite heavily invested in the ecosystem. Alibaba, Baidu and Bytedance use it extensively. Nubank's using Flutter too I think. That one is like 50 million users alone? So even if Google let it die given that Flutter is open source I don't see it going away any more.

That was true 3 years back, but with all the recent developments (especially the new impeller upgrade against iOS jank), there's a lot to be optimistic about the longevity of flutter. Meanwhile I haven't seen much development from React Native, although granted I didn't bother checking either. Flutter is so much easier to work with than React Native or even React.

I'm building an app right now in Expo / React Native + Typescript for its Authentication library[1] that allowed me to easily integrate Stripe's web login[2]. Expo apps can also be exported as PWAs via Workbox[3] so you could have your app distributed on the web plus have a native version in the app stores using a single code base.

[1] https://docs.expo.dev/develop/authentication/

[2] https://github.com/hbcondo/revenut-web#-authentication

[3] https://docs.expo.dev/guides/progressive-web-apps/

React Native over flutter all day every day. There's almost nothing you can't do in the react native world when sticking with the managed Expo workflow these days.

After Compose Multiplatform has matured a bit more I'd be seriously considering using that for everything going forward.

https://www.jetbrains.com/lp/compose-multiplatform/

I have been developing in React Native since 2019, the ability to quickly create one app for web, one for Ubuntu, one for Windows, one for MacOS while using React functional metholody for me is indispensable. I hate Flutters rendering system and Dart.

Have you considered MAUI?

I was looking at the newly announced VS Code extension for .NET 8 MAUI development and that piqued my interest again in MAUI. (Also the in-progress performance metrics of the .NET 8 preview using .NET NativeAOT versus classic Mono AOT are fascinating.)

The stuff I've been directly building in the last few years has just been PWA/WebView [Ionic's Capacitor], because web stack is reliable and even more "single development platform", but I've been keeping something of an eye on MAUI in case it grows up into something great. The newly announced VS Code support helps a lot, especially because that gives you a consistent IDE across Windows, Linux, and macOS. (Which can be important if you are targeting iOS because you have to have at least some macOS time, regardless of what you prefer as your main development environment. In this case, VS Code is much more consistent cross-platform than the odd differences between Visual Studio and Visual Studio for Mac, despite the shared brand name of all three.)

The value proposition here is great...if you're living in 2016. But that framework ship has sailed. People already have years of experience deploying React (Native) targeting all those platforms and the web. Competition is great, but this new UI framework will join the same graveyard of all Microsoft's other similar attempts.

JavaScript will eat the world. At least Microsoft saved us somewhat by inventing TypeScript.

You can have JavaScript in MAUI. It's just as good a WebView host as anything else can be. I've seen plenty of "Blazor in MAUI" demos. (Maybe too many, as something of a sceptic about Blazor and its dumb brand name.)

MAUI is the "new brand on the street", but it's mostly just the latest revision of Xamarin's old stuff in a fancy new package and the option to call parts of itself in .NET now "System". There are people that already have years of experience deploying Xamarin stuff that (I hear) happily transitioned over to MAUI. (Sure, there's also plenty of people that think MAUI is too different from Xamarin and somehow killed their Xamarin puppy, because people will always hate any and all backwards compatibility breaks and semver MAJOR releases.)

Why not a PWA using Ionic (or similar)? A PWA can be packaged as a hybrid app if your need to access native APIs beyond what PWA supports.

Because you might want to give your users a somewhat decent experience.

Depends on the specific experience you're trying to create but there are fewer and fewer cases where what you want to achieve with a mobile app cannot be done with the mobile web. I can only think of one case in my career where native was actually necessary and not the vanity of the manager having an irrational disdain of the mobile web.

Or stated differently: unless it can be articulated why mobile web/PWA/hybrid cannot work for a specific technological reason, starting with PWA/hybrid is always the best approach. If it needs to be native then go with the vendor-recommended manner of development (unless you love painting yourself into a corner 95% of the way through the project -- been there, done that, don't want to go back).

Integration with the operating system look & feel & accessibility by using native UI elements instead of poorly trying to mimic it in a webview

Dev teams continuing to ship garbage-tier webapps should not condemn all webapps and webapp methods.

You woke up today and chose violence.

Native

+: Great performance, Compose (with multiplatform) is awesome, you also can write basically anything

-: Cost is at least 2-3x, if you use a lot of system dependent libraries (and you'll probably do), higher skill ceiling and harder learning curve (you'll have to learn everything - 5x of RN or Flutter)

+: Shared web stack is a killer feature, easily pushable code, native look

-: Awful performance, the ecosystem is a bit beaten, lots of plugins are poorly supported

Flutter

+: Time to market is king, performance is fine, huge standard lib, superb libraries for state management, less tiresome to setup proper types than Typescript

-: Some long running issues like the lack of static metaprogramming are nuts, wonky threading, non-native look and feel is still (and will probably be) a thing, library support is okayish, could be better (especially, if google actually cared about basic features like a good http client, for example)

Interesting timing, since I've just started experimenting with this. I'm a Web/TypeScript developer who wants to create a mobile application which doesn't do too much fancy stuff, but will rely on some esoteric WebView logic (think injected scripts) and possibly a Rust module. I've been reading up on Flutter and React Native, and am currently in the process of the Flutter "Hello World" tutorial. So far I've been really impressed with the docs, but I'm literally on hour two of this experiment.

I'll probably try React native too, but I've been using React for six years and frankly I'm sick of it - I wanted a change of pace, and I feel like React Native is a bit of a crutch for web developers. Sure you can keep using TypeScript and CSS and everything in a WebView, but you end up with a janky application that buckles under the weight of all its abstraction layers. And it seems like a lot of effort just to avoid learning something new.

What I absolutely do not want to do is code the same thing twice, once for Android and once for iOS. So far it seems like Flutter or React Native are the best options. This blog post [0] convinced me to experiment with Flutter first.

[0] https://stackoverflow.blog/2022/10/31/comparing-frameworks-f...

Been thinking of the same question recently. Appreciate all comments sharing their experience.

For those saying to native, I completely disagree. Going native for the same app running on multiple platforms will face the following issues:

- hard to be consistent.

- hard to get the exact same design especially when using native components.

- release lags and platform specific bugs. Unless you want to block releases for one app waiting for the other app to catchup.

- support effort will double especially if you’re making screenshots and screen recordings.

> hard to be consistent

> hard to get the exact same design especially when using native components

Well, that's the point. Users are generally happier with an app that feels native to the platform.

Depends. If it's a hobby, learn both to be more valuable.

If it's for a business? How much money do you have to throw away? Does the app pay for itself, or is it a cost centre? (99.9998% of the time, it's a cost centre.)

You really asked the most boring part of that question. Most of the answers below suggest that the app is defending its territory, etc. Malarkey.

Just like you're not winning the lottery, you're not writing a standalone app that can pay for itself.

Why? Hundreds of thousands of apps exist on each platform right now.

For your app to stand out enough to be successful it needs synergy with something. A web site, a service, a IRL business.../something/.

Tha says to me: do the cheapest possible thing. If you have React devs, use that. If you don't, find the alternative cheapest possible way. Flutter? Maybe. Nocode (like Glideapp, https://www.nocode.tech/category/app-builders)? Maybe.

Pick the fastest/cheapest way to get an app out to validate the concept. Once validated, then you'll have enough information to know what pain points you have, and what solutions you /really/ need.

I've been building a game in Flutter for the last couple of years, and I absolutely love the dev experience. Dart is the best language I've used professionally in 20 years (for reference: Dart, Java, JavaScript, TypeScript, ActionScript3, Kotlin).

I do web stuff for my day job, and I just HATE the javascript/typescript house of cards build system and npm. Flutter's pub is great, and the builds just work.

I chose Flutter because I already liked Dart, and I was building a game to play with my wife, so it had to be cross-platform from the beginning. That was difficult since I don't have any Apple hardware. But I was able to get things going by borrowing hers for a minimal setup then offloading production builds to codemagic.io.

Shameless self-promo: https://MarkMyWordsGame.com

There are also 2 paths that .NET offers that you might want to consider.

First one is Maui, which is a cross-platform toolkit supporting iOS, Android, Mac, Windows, etc... This generates a native app on each platform. Second path is embedding a Blazor app in a Maui skin, so Electron like.

If you don't mind following my approach, I'm writing a book ( https://opinionatedlaunch.com ) for building and launching mobile apps end-to-end. It's for solopreneurs who can code and a small team of up to a dozen devs.

It covers not only the mobile app, but everything else. So, opinionated. There are many ways to make a mobile app and its supporting ecosystem, and it defeats the purpose if I simply explain everything there is and let the reader decide how they want to proceed. Not to mention I will never finish writing that kind of book :)

As a user I tend to prefer React Native apps. Flutter feels distinctly off in some places (more on Android than on iOS) and apps made with it sometimes show serious slowdowns, which the native toolkits tend to not do.

The fact that Flutter is tied to Google is a huge reason in my eyes to not trust that it will survive long-term.

I agree with others saying native is the way to go.

Flutter is also used by and contributed to by Alibaba and Baidu.

I hear this a lot but as a counterpoint so is Go.

If mobile is integral to this business then go native and launch with whichever platform makes sense first, push as much logic to the server as you can or write some shared Kotlin Multiplatform or Rust components. Otherwise I’d start with a webapp or maybe React Native, Flutter still feels pretty risky to me personally.

This might be derailing but I've personally had a lot of success with CapacitorJS + Nativescript, which is a Webview with hooks into native API's for anything you might need access to at a lower level. But out of the list I'd probably pick Flutter, I don't really see Google culling it anytime soon.

What about https://dioxuslabs.com/?

It uses the Rust language for development.

"One codebase, every platform. Dioxus is a React-inspired library for Rust focused on developer experience. Build fast, beautiful, and fully-featured apps for every platform in less time."

Are you going to code it? If its "business app" I'd say RN is great (Expo?). PWA also to consider for some cases. Honestly I wish PWA was a bigger thing. Why do I have to install an big app just to rent a bike, etc.

For what it's worth, I've actively started to avoid React Native apps due to performance and APK-sizes, especially now that phones become obsolete so quickly.

Haven't had much experience with Flutter apps.

I am in a situation right now where I have to deliver on all three platforms. I chose Flutter because I just couldnt do anymore JS.

Neither.

The developer experience for both is awful, especially after you've been spoiled to an amazing dev ex from RedwoodJS.

You can’t even connect a debugger to that thing last I checked. Has the debugging experience improved?

I worked with both. Honestly, it doesn’t matter. Choose what you like more

Flutter

Dart is a nice language.

Lots of libraries.

Easy to fill in the gaps.

Manageable to bridge native.

Great community.

Why not web PWA ?

Reply on news.ycombinator.com