Ask HN: React Native or Flutter for a new app in 2023? 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. |
Ask HN: React Native or Flutter for a new app in 2023? 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. |
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."
Haven't had much experience with Flutter apps.
The developer experience for both is awful, especially after you've been spoiled to an amazing dev ex from RedwoodJS.
Dart is a nice language.
Lots of libraries.
Easy to fill in the gaps.
Manageable to bridge native.
Great community.
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.
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.
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.
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.
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.
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.
Well launching on both platforms at once is one benefit. But how about the benefit of writing code once?
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.
But IMHO for apps where that isn't the case starting with a single platform is a good bet.
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).
If reuse across platforms is of interest, a proper crossplatform webapp is a great answer.
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
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.
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.
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.
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.
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. :)
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?
[1] https://docs.expo.dev/develop/authentication/
After Compose Multiplatform has matured a bit more I'd be seriously considering using that for everything going forward.
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.)
JavaScript will eat the world. At least Microsoft saved us somewhat by inventing TypeScript.
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.)
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).
+: 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)
RN
+: 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)
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...
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 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.
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 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
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.
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 :)
I agree with others saying native is the way to go.
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.
Reflecting on Code Sharing React and React Native
https://matthewwolfe.github.io/blog/code-sharing-react-and-r...
APIs / data models?
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.
Types.
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.
This is also common to JSX though so not sure what the "abominable" comment is referring to.
I’m not surprised that people are reaching for Flutter and React Native instead.
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.
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".
There can be probably other reasons too.
I'm highly skeptical of code sharing for other scenarios, and rarely (never) have seen the effort worth the payoff.
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.
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.
I think they do the demos in qt quick to appeal to auto makers.
But more importantly, why it doesn’t take advantage of an accessibility feature that that a native app would get for free.