[kevinsd]

While React Native is constantly being improved, to use it in its current form, one has to be very aware of its under-developed parts, and more importantly, make them aware of by designers and PMs.

Surely for any "fancy" feature one may think of doing with RN, there are always some libraries, plugins, tutorials, solutions that exist in the vast ecosystem trying to help. But more often than not they eventually lead into a maintenance/integration nightmare, simply because how fast the whole mobile industry moves and leaves things behind.

Therefore, I suppose that a wise approach is what I would call "React Native-first design": let the whole team (PMs, designers, devs) know that anything that is not officially supported by React Native and without caveats is off the limit -- just try to avoid the design until it is fully supported.

[blub]

Well, that's certainly a novel approach.

Usually technology is used to solve business needs, but in this case the business has to adapt to the limits of a particular technology, even while other technologies offer the full range of features any business might need.

[gilbetron]

Adapting a business to technological limitations has always been the case. Entire industries are shaped by technology. That you are unaware of it is probably because you are a fish unaware of water.

[haney]

All engineering requires trade offs, in this case you’re trading productivity in one area vs flexibility.

[filleduchaos]

All engineering may require tradeoffs, but when you're so prioritizing developer experience over the actual business that you're dropping perfectly viable features just so you can cling to the illusion of increased productivity, perhaps it's time to take a step back and reevaluate things.

What use is "productivity" without a performing product?

[spamizbad]

Depends on what feature we're talking about.

Is it a high-value feature to the end users? Then absolutely, you're correct.

Anyway, in my experience, most good PM and designers want an understanding as towards the amount of effort their features and designs mean for engineers. So if you aren't providing them that feedback, and letting them to factor that into their process, you're doing them a disservice.

[Jare]

MVPs are mostly about that. Unless a fancy feature not supported by RN is a necessary part of your core product, productivity takes priority.

[filleduchaos]

And is the app going to remain an MVP forever?

[Jare]

No, but the ability to produce an MVP within the limitations (time, budget, opportunity, etc) may be what allows having an app at all.

[on_and_off]

so productivity as long as you don't implement some features ?

I mean, I can double my native productivity that way too !

[haney]

Sure, I’m not advocating for developer experience above all else, just pointing out that the fast/cheap/good “pick any two” balancing problem can be solved in multiple ways. I totally agree that we build products for our users not ourselves.

[on_and_off]

oh yeah, I can get behind that.

If you need an app on both Android and iOS quickly, have low quality concerns and only one web dev .. RN is a no brainer.

It kinda occupies a completely different valley of the fast/cheap/good graph

[zaidf]

This is far from novel. PMs, devs and architects allow the tech stack to influence product all the time, often on the basis of back of napkin cost-benefit analysis.

In fact, an org that doesn’t define tech constraints is setting itself for overengineering while a disciplined org can use those constraints to drive more, not less, business value.

[fabricexpert]

Influence but not define.

If you tell me we can't hit business objectives because the team wants to use react native instead of swift without a really good reason, it's not going to work.

[chrisco255]

I suppose you could say the same sentence in reverse? These days you have to support Android and iOS so Swift is only going to get you so far.

[alangpierce]

An example of where this is already common is when deciding to ship a web app vs a desktop app. Web apps will always be more limited, and sometimes those limitations get in the way of business needs, yet you still see web apps as the most common UIs these days. It's a tradeoff that the business should be consciously making.

[jeremyjh]

Saving money might also be a business need. For this to work, obviously the whole business has to buy in to the benefits of RN, and they should be aware of the trade-offs up front.

[Cthulhu_]

But does RN actually save money? Or does e.g. having to keep up with the rapid development, maintaining your own native bridges and components, etc etc etc only cost more time and money in the long run?

I've read a bunch of react native postmortems and I'm usually reading "yes we're faster, but we're spending a lot of time on maintenance". It gives me the feeling it's probably faster short-term, but not viable long-term.

Besides, I'm sure there'll be a next big thing (Flutter?) soon enough, causing investment in RN to drop and it never getting up to par with the native platforms. (see also: PhoneGap / Cordova, Xamarin, etc).

[wsc981]

I think Xamarin really stays up-to-date with the newest features for iOS. At least that was true back when I wrote some apps with it, a few years ago.

I believe they have some automated tooling to update the APIs when Apple releases newer versions of the iOS SDK, so usually new features arrive on the same day in Xamarin iOS SDK as they do in Apple's iOS SDK.

I am not sure if the situation is the same for Xamarin and Android.

I wouldn't really hesitate to use Xamarin again in the future if a client requested it, but I haven't tried React Native yet and not sure if I should dedicate time for it or if it'll be gone in a few years. Seems quite a few mobile jobs require React Native experience these days.

[jeremyjh]

I’m not convinced everyone has these issues. I would agree if you have a native codebase then adding RN will only cost you. Not everyone has or needs a significant native code base.

[murukesh_s]

+1 but there has to be a balance. Some features that non developers think is quite easy could take very high effort and vice versa. But I agree having to not have a feature that your competitor seems to have but you can't because you used 'X' would snowball into a big roadblock when multiple such cases crop up and the sexiness of the framework fades..

[filleduchaos]

It's certainly interesting that the "wise" approach is essentially "abandon your actual product vision/goals" in the not-so-extreme case.

[spiritcat]

Maaaybe can get by with that approach if you expand that to everything included in expo sdk.