41–50 of 109 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 ca…
Integration with the operating system look & feel & accessibility by using native UI elements instead of poorly trying to mimic it in a webview
Earlier quoted context omitted.
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.
Haven't had much experience with Flutter apps.
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.
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).
Earlier quoted context omitted.
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.
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.
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?
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.
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 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.)