[Grim-444]

Well I give them props for at least having a facade of a "what went wrong" section, which most RN articles leave out, although it doesn't feel like an honest analysis of the negatives of their switch.

I'd like to see some actual data about what percentage of their code is written in native vs RN. In my experience you need to maintain massive amounts of native framework code on both sides to support the RN code, and to implement stuff that RN can't do or does horribly. Adding RN into the mix just basically adds one more platform to be supported, making things more complicated, rather than combining code into fewer platforms. RN teams never bother to mention how much native code is needed to support them, and seemingly never include native work that was done when giving metrics about how long it took to "write" a feature in RN, usually because a separate "native" team does that work, not them, so it's conveniently not mentioned.

Also curious about other metrics such as how many developers they lost that weren't interested in becoming JS developers. Or have they stuck around because there's still so much native work that they need native developers for, to support RN.

[brundolf]

Anecdotally we've got a RN app, and we've only got one or two native source files for each platform, which are mostly there to bridge in third-party libraries for things like analytics. Our UI and business logic are almost 100% JS and it works out really nicely for us

Of course this is a mostly standard (but not small) CRUD app. We've got some custom animations/widgets here and there, but mostly it's vanilla forms, controls, views, etc. which translate easily to both platforms

We also started out on RN from the beginning; it's possible that migrating to it from native code is a much bigger challenge

[chenxi9649]

Same for us. Certain dev environments bugs were been a big pain in the ass for us in the past. For the logic side of thing React Native has been a nice experience for us as well!

[59nadir]

> [...] and seemingly never include native work that was done when giving metrics about how long it took to "write" a feature in RN, usually because a separate "native" team does that work, not them, so it's conveniently not mentioned.

In this case it seems like they transitioned a mostly native mobile workforce into React Native, so I don't know that the last bit makes much sense here. I agree with you that there is a general absence of information about how they still deal with the native side of everything with React Native becoming more and more important in their apps. Even just the "yet-to-be-transitioned-but-we-need-to-use-it" kind of stuff would've been more interesting to learn about and certainly "What native stuff remained in sections that were ported?" seems reasonable as well.

[secretsatan]

I can’t really see an app like Shopify really needing specific native code

[secretsatan]

I’m one of few left in our company of our original mobile team after we switched to qt, and i pretty much soft quit by writing an entirely new native app

[Hithredin]

How does QT fare for multiplatform dev? This is often forgotten when talking of the choice available.

At the time of Blackberry 10, this was an appealing solution with Cascade. But now?

[secretsatan]

My personal opinion, it is the worst, we spent more time working on getting it to build than coding, it’s a platform only a die hard cpp developer could love and only because they’ve never tried anything different.

Even the mobile app we do have in qt has substantial coding in native. It doesn’t have things like faceid for login, light/dark themes, is extremely restrictive in supported devices and orientations.

There’s next to no community, anyone who does mobile just doesn’t use it, and imho, for very good reason, mobile dev moved on and supporters of qt just seem to like making it harder for themselves to support it.

I’d say it works ok on desktop, but i generally find qt apps on my mac look dated and have odd unmac like qualities.