9 ms·
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.
- mikece 3y agoWhy 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.
- floomk 3y agoBecause you might want to give your users a somewhat decent experience.
- mikece 3y agoDepends 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).
- elforce002 3y agoYou woke up today and chose violence.
- meitros 3y agoReact 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.
- keltex 3y agoMy 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.
- brokenbyclouds 3y agoThere's nothing that requires you to use EAS Update though. You could just stick to submitting builds through the app store like normal.
- floomk 3y agoI have no idea why you would pay that. Just eject.
- brokenbyclouds 3y agoEjecting 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.
- cutler 3y agoThanks for that. One more reason, if I needed one, not to go native at the outset.
- winrid 3y agoNothing 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.
- fakedang 3y agoSorry, time to market is important. What's important is getting your product out the front door, then iterating as you go on.
- winrid 3y agoQT is also really great, depending on what your app is.
- lockhouse 3y agoAs 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.
- winrid 3y agoInteresting. 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?
- lockhouse 3y agoOn 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.
- joshuawright11 3y agoPurely 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.
- itake 3y ago> 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.
- joshuawright11 3y agoYeah if React is your strong suit, an initial version in React Native is the way to roll.
- bartaxyz 3y agoWith 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.
- thih9 3y ago> 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.
- joshuawright11 3y agoYeah - 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.
- sureglymop 3y agoI would use Kotlin multiplatform and Jetpack Compose multiplatform. But mainly because I already know Kotlin. It's definitively nicer than typescript though.
- esafak 3y agoNicer 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.
- cutler 3y agoBut 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.
- deleted 3y ago[deleted]
- esafak 3y agoI 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.
- lockhouse 3y agoAndroid 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.
- 3y ago
- bickeringyokel 3y agoFlutter 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.
- cutler 3y agoFlutter's widget tree is an abomination.
- thelollies 3y agoCan you elaborate? I've found it a delight.
- bickeringyokel 3y agoA 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.
- thelollies 3y agoYeah 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.
- empty_banana 3y agoExactly, it's so simple and transparent when done correctly.
- brokenbyclouds 3y agoReact 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/ https://www.jetbrains.com/lp/compose-multiplatform/
- dvh 3y agoI 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?
- Barrin92 3y agoSeveral 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.
- fakedang 3y agoThat 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.
- jbirer 3y agoI 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.
- brigadier132 3y agoGonna 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.
- petabytes 3y agoIve 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.
- DANmode 3y agoThis. If reuse across platforms is of interest, a proper crossplatform webapp is a great answer.
- andix 3y agoMost 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).
- dhrubajyotidas 3y agothere is small issue with webview on android https://bugs.chromium.org/p/chromium/issues/detail?id=1289741#c59 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
- jconley 3y agoReact 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.
- joshuawright11 3y agoAlways been interested in the idea of sharing code across the full stack. What do you find you can share the most? APIs / data models?
- simlevesque 3y ago> What do you find you can share the most? Types.
- ctvo 3y agoTypes (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://protobuf.dev/ - https://smithy.io/2.0/ https://smithy.io/2.0/
- matthewwolfe 3y agoSee 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.
- nwienert 3y agoI 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 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.
- upmostly 3y agoNeither. The developer experience for both is awful, especially after you've been spoiled to an amazing dev ex from RedwoodJS.
- mandrizzle 3y agoYou can’t even connect a debugger to that thing last I checked. Has the debugging experience improved?
- toastercat 3y agoFor 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.
- jamil7 3y agoIf 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.
- pritambarhate 3y agoI 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-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.
- karmakaze 3y agoI'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.
- WorldMaker 3y agoHave 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.)
- a_wild_dandan 3y agoThe 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.
- WorldMaker 3y agoYou 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.)
- starik36 3y agoThere 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.
- willio58 3y agoThe 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.
- kcorey 3y agoDepends. 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 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.
- deleted 3y ago[deleted]
- wetwater 3y agoI 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.
- hbcondo714 3y agoI'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/ https://docs.expo.dev/develop/authentication/ [2] https://github.com/hbcondo/revenut-web#-authentication https://github.com/hbcondo/revenut-web#-authentication [3] https://docs.expo.dev/guides/progressive-web-apps/ https://docs.expo.dev/guides/progressive-web-apps/
- wiradikusuma 3y agoIf you don't mind following my approach, I'm writing a book ( https://opinionatedlaunch.com 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 :)
- kahnix 3y agoThis 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.
- Oras 3y agoBeen 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.
- solarkraft 3y ago> 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.
- moomoo11 3y agoFlutter Dart is a nice language. Lots of libraries. Easy to fill in the gaps. Manageable to bridge native. Great community.
- theironhammer 3y agoWhat about https://dioxuslabs.com/ 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."
- flax 3y agoI'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 https://MarkMyWordsGame.com
- revskill 3y agoWhy not web PWA ?
- solarkraft 3y agoAs 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.
- ac130kz 3y agoNative +: 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)
- patatino 3y agoI worked with both. Honestly, it doesn’t matter. Choose what you like more
- TechBro8615 3y agoInteresting 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-for-cross-platform-apps-flutter-vs-react-native/ https://stackoverflow.blog/2022/10/31/comparing-frameworks-f...
- swah 3y agoAre 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.