Comment by moomoo11 | Hacker News Reader

Comment by moomoo11 | Hacker News Reader

This is cool and I’ll definitely try it out some time.

Serious question though. Who is this for?

I’ve done mobile app dev in all the popular ways - native, flutter, and react native.

Both flutter and react native bring up a ton of issues anytime the app becomes more complex than rendering a list with some detail pages.

I wrote so much custom code bridging gaps.

Swift and Kotlin make native dev so easy and straightforward.

With flutter (which I have the most experience with along with native) I had to anyway write bridge code for handling both platforms.

I think considering how easy it is to write APIs, isn’t it better to just use native for both platforms to deliver a fantastic user experience built on those APIs?

Is this another project that’s suitable for simple apps or will it actually be useful for very complex UIs and deep device integration. I mean flutter still has open issues around scroll to top breaking which I fixed with custom bridge code. It’s impossible to get issues addressed.

Like say it takes 3 days to make a complex UI. Then a week or more to write and test the bridge code. I’d rather take 6 days writing platform appropriate code and save a day or more of pain. And when that breaks fix it. Over time this adds up to a lot of saved time I think.

Yes. I have experienced the same. These tools make 99% too easy and rest 1% too difficult. I have worked on a RN (expo) app, it was working well for the client. New requirement added - geofence, wifi connect from app in background. There is no RN (Expo) plugins. So tried last few days with custom expo module. I didn't know kotlin, i worked with java only. Now i am learning Kotlin and realized that Jetpack compose is way better than wasting time with these do all magic tools. Now rewriting the whole app in Kotlin only.

> Who is this for?

Speaking with my experience with Expo, this kind of framework works great for their purpose in enabling a small team of engineers working closely with products and business analyst to deliver features as fast as possible.

From business perspective, turns out not everything needs to be a blazing fast native code. That means if you can write code once and it will run in other platforms with minimal changes, you save some time. More time to ship more features!

In a zero sum market where every extra features could bring more customers, this could become important factor when picking the tech stack. More so when you're running on investors money and need to make profit ASAP.

To target iOS, Android and Web, you’d have to write 3 apps / frontends then, instead of just 1 (with One).

On React Native then One uses Expo, which is used in a lot of top tier and complex apps.

For more about the CTO type decision of going with 3 apps or 1, and the various options from RN, Flutter, Ionic Capacitor, NativeScript (etc.) then you’ll likely find my comprehensive blog post helpful:

https://magnemg.eu/the-different-tech-strategies-for-buildin...

Not arguing with you there, of course there will be 3 apps.

If the app is simple, as many of the top tier apps are, I'd recommend flutter/RN/One* in a heartbeat. However, many apps are also quite complex, and should be built for the target platforms to provide a great user experience.

However, as even Airbnb found out, they're spending half their time writing bridge code to make things work.

At that point I'd almost argue you're better off having 3 apps. FWIW I used to work at a tech unicorn that had a great exit, and we had native applications. We did some research projects to see if we could leverage RN and Flutter but found the headache was not worth it.

Most of the libraries out there are low quality and without any tests let alone good documentation. That means we would most likely have to write our own (which we did).

Then, we found out the underlying abstraction layer (flutter/RN) had its own set of issues. Then we started maintaining bridge code for those.. as I mentioned basic interactions were broken, which you'd think are the lowest hanging fruit.

Yeah, I’ll add that the decision to use RN if you already have a couple of native apps is way harder than if you are starting out with RN. I think the former was why AirBnB reverted their RN foray, and it seems to match your experience.

Airbnb was early, React Native has grown immensely since then. Honestly not to tout myself, but Tamagui brings so much as well to make it possible to share styling.

Uniswap I think proves it can be done, try out their apps. They still can improve, and I need them to upgrade tamagui and turn on the optimizing compiler because it's gotten like 60% faster in latest releases, but basically - we've come a long way, I'm long RN.

Reply on news.ycombinator.com