React Native: A retrospective from the mobile-engineering team at Udacity

https://engineering.udacity.com/react-native-a-retrospective-from-the-mobile-engineering-team-at-udacity-89975d6a8102

by phaedryx • 8 years ago

285 194 8 years ago

engineering.udacity.com

haney3• 8 years ago

So I'll state my bias up front. I'm a pretty happy non-native react-native developer.

After reading this write up and AirBnB's write up about RN I keep wondering if the source of the problem is more with integration points between native features.

Like I said, I'm not a traditional native mobile engineer, but as a single dev I've been able to build a rather large and complicated app almost entirely in react-native. That's not to say that I don't use mobile features, I'm using a dozen or so libraries for native features, but the common problem that seems to arise is "this doesn't integrate well with the rest of our native app". IMHO if you're writing business logic in swift/java instead of javascript you're going to have a bad time. If, however, you use/implement narrowly scoped native libraries that are glued together with javascript it's a pretty nice experience.

I wonder if the issues that they encounter are more a symptom of trying to "bolt on" react-native.

egeozcan• 8 years ago

I wonder if the issues that they encounter are more a symptom of trying to "bolt on" react-native.

Exactly. React native shines exactly in your situation, not when you already have a few developers who can write native code for each platform, and especially not when you already have an established app for each platform.

meiraleal2• 8 years ago

Exactly. React native shines exactly in your situation

It also works well when you have thousands of developers with established apps (Facebook). This React Native bashing storm is more a cultural thing as the other solutions (native, swift/objc, java/kotlin) are not technically superior, with obvious up and downs compared to RN.

TAForObvReasons• 8 years ago

Like with React itself, as long as you play within the React-Native box the experience is great. For basic apps you don't need anything extra. Once you start having to go into the larger ecosystem for features not provided by RN, the weaknesses start to show up.

danpalmer3• 8 years ago

I think there are a few other major problems, but I think many apps are unlikely to hit them in the same way that they are unlikely to have integration issues with native code, because they don't need much native code.

Most apps only need to be a bunch of table views and detail views, with some forms. Line of business apps that need to be efficient (not pretty) or that don't use many of the advanced platform features, short lived apps for events/marketing/competitions/etc, apps for restaurants or shops, these are all places where I think React Native fits perfectly.

However, if you want your app to have the best performance (spoiler alert, you probably don't), you want to be at the cutting edge of platform support, or you want to create experiences that fit on the target platform perfectly, then I think native is the way to go. Most apps do not need this.

Cthulhu_2• 8 years ago

However, if you want your app to have the best performance (spoiler alert, you probably don't)

Actually you do. An app like Facebook, Instagram, etc are used for hours a day; having a suboptimal performance directly translates to battery drain and a poor user experience, which costs you money.

I'm sure someone smarter than me has a nice soundbite about using the best tool for the job. React Native is a compromise. Web technology on mobile is a compromise.

vlozko2• 8 years ago

Spoiler alert, more than you think you do. I was involved in refactoring a product detail page for an e-commerce app. It was a several month long project as the view is pretty complicated and the only goal was to improve UI performance. Our efforts led to a direct, measurable result in user engagement and an increase in items being added to the cart.

spicyj• 8 years ago

React team here. I think this is largely true. We’re already working on tackling a lot of these rough edges; see a recent post I made to learn more:

https://facebook.github.io/react-native/blog/2018/06/14/stat...

ckluis• 8 years ago

B2B (Xamarin) team where I work. One huge step to help B2B adoption would be to include an official library to include some functionality instead of having to choose between many different fragmented options.

A perfect example is qr/barcode scanning - there are numerous commercially supported "enterprise" scanning engines which are substantially more performant than builtin solutions or existing open source solutions. If you can meet a few of these requirements with main library support it would become incredibly hard not to use react native in B2B solutions.

on_and_off5• 8 years ago

I wonder if the issues that they encounter are more a symptom of trying to "bolt on" react-native.

I suspect that your experience as a single developer has VERY little in common with what the 100 people Airbnb team is doing.

I am not trying to say that you or your work are in any way lesser than the one of a big team but it is a very different problem.

I have worked in such an environment and even with native, we had to code a ton of custom Views in order to get exactly the specific behavior we had in mind.

There are tons of little tweaks that demand to exploit the platform to 100% that you can in a very large team and that you would just avoid a single dev because you don't have the time for this kind of stuff at big scale.

chrisco2556• 8 years ago

He's not wrong though. Other big teams have had success with React Native including Skype and Office teams, as well as Instagram.

When I read this article by Udemy, where they started with 1 dev for each platform and had a mere 3 or 4 react Native features and then ended up with 7 or 8 mobile devs split along platform lines, I wondered if 2 or 3 react native devs couldn't achieve the same thing if they actually tried to share 90% of the code across iOS and Android and went all in? The productivity boost is there if you embrace it.

q-base• 8 years ago

A very good and nuanced write-up. React Native seems to get a bit of heat at the moment, or perhaps I am just paying more attention to the content, as I have just started building a project with it.

But nevertheless I am still sticking to it with what I have read so far. Building from scratch with no iOS or Android experience, but some "normal" React experience(and a lot of .Net experience) it seems like a no-brainer in my situation.

The issues I have gathered from numerous articles seems to relate more to existing teams with experience in iOS or Android. Or projects that have had high growth.

Starting out from scratch those issues are not of concern. I will deal with them if/when I get there. My main reason for using React Native is to build something fast that can target both iOS and Android at the same time. And they rightly also point to that as a good reason for selecting React Native in the end of the article.

txmjs2• 8 years ago

I'm under the impression, in Udacity's case especially, that part of the problem stems from asking native engineers to use a language and ecosystem that they're not used to working with, and then trying to get them to integrate RN code into an established, brownfield native codebase.

As a sole dev in a 3-person startup, I’ve managed to build a pretty large app with React Native, having zero prior native experience (although, that’s not to say that I haven’t had to learn a _lot_ about Xcode!)

jwarren3• 8 years ago

I had a pretty similar experience. It's still a challenging environment - getting performance and memory management nailed across platforms and devices took some very careful engineering.

Based on my limited experience with native iOS app development, RN actually requires an almost completely different way of working.

bottled_poe• 8 years ago

That sounds like unnecessary complexity, skills and cost. Until it’s simpler to build, higher quality and a more predictable result than native, i will continue to use native frameworks.

laurent1234562• 8 years ago

That was my impression as well. What he wrote about localisation as well - they are trying to localise text in RN files, native iOS files and Android files, maybe using a different approach for each platform, so of course it's complicated.

I managed to localise a relatively large cross-platform app built in Electron and React Native using gettext and had no problem with it. It supports 18 languages and people send me update from time to time, which are very easy to integrate.

coding1232• 8 years ago

It seemed a large part of their frustration was integrating the native with react native. I think too if you decide to use react native you don't hire more iOS and Android specific devs, you hire react native devs and replace the entire native codebase.

blub2• 8 years ago

Show us the app and ideally some code to let us judge how well you managed then. I believe the standards for native development are well known at this point.

i6mi63• 8 years ago

Check out GoodOrBad - Simple Meal Logging on the stores, it’s fully React Native with some little native code (push notifications, etc.)

Jonovono• 8 years ago

Check out Bunch (https://itunes.apple.com/us/app/bunch-group-video-chat-games...). Been working on this for ~6 months. We def have some issues but we believe they are fixable, overall have been pretty happy with RN

anothergoogler2• 8 years ago

Spot on, they should fire their mobile devs and hire more Full Stack JavaScript DevOps ninjas. Those guys do it all, resource allocation baby!

anad72• 8 years ago

If only we could learn from past experiences, many companies have done that in the past because some CXO thought that they could save some money using hybrid frameworks, didn't go well for them and they ended up writing native apps. It's like you are asking people to fire "Master of one" and hire "Masters of none".

gtycomb• 8 years ago

stems from asking native engineers to use a language and ecosystem that they're not used to working with

yes, so reminiscent of “enterprise” situations where SAP (or put any of your other favorite's name here) is so dominant. In a recent situation, the marketing side of the business kept asking for newer agile mobile technologies, and so the cio-purchasing-manager engages Gartner (or put any of your other favorite consultant’s name here) for guidance. Well, the result is to start an in-house prototyping team composed of who -- folks seeped in SAP maintenance but who wants to learn the newer mobile technologies for career development. They do create some prototypes but so many things remain open while they are busy doing their daily SAP work, their forte. The CIO then steps in to satisfy the marketing folks: We buy SAP’s packaged solution for mobility and an outside consultant will integrate it. Problem solved. Or is it? The answer waits another three years when the integration is really completed, by then the CIO leaves and the issues need to be visited again.

blizkreeg2• 8 years ago

Can I reach out to you? My team will shortly be starting out with RN to build our mobile app. I'd love to get some pointers and advice on what we can do to make it as successful an experience as possible.

txmjs2• 8 years ago

Of course - email in bio :)

axemclion2• 8 years ago

If you have questions, you can ping the RN team too. I would love to help !!

amelius• 8 years ago

How does it compare to Flutter?

cmjqol• 8 years ago

Flutter has it's own issues.

First , flutter uses an architecture similar to a game and uses it's own rendering pipeline and Layout system, meaning integrating with anything that exists is extremely challenging ( Chartings , Lottie etc... ) you'll be often waiting behind the Flutter team to implement the feature inside the engine.

On top of that the SDK supports for Darts right now are non-existent, maybe it'll change in the future , but Firebase + GCloud is pretty much all you'll get in terms of SDK as of now.

Fifer822• 8 years ago

All in all is it still a terrible idea to try to build native apps with HTML?

In my experience going back to Phonegap, I have tried many evolutions of these products over the years and all of them are terrible. Like unusable. 3fps and unresponsive.

Is React Native a new generation, a new stable outlook, or is it simply making React 3fps and unresponsive?

lwansbrough• 8 years ago

React Native is native. There’s no HTML. You’re using JSX (probably) which is basically XML in JavaScript (it’s not as bad as it sounds) to build native UI. Can’t stress the native bit enough.

Where React Native differs from truly Native is that UI orchestration is batched into chunks on the JS side and sent asynchronously to a native receiver, which then applies those changes to the native side. This means that currently if your JS thread gets blocked, or the main thread gets blocked, your app will snag. Performance is a top priority for React Native and it mostly fulfills that goal too. It’s not hard to keep your app running at 60fps.

wvenable2• 8 years ago

React native is an abstraction layer. It has all the problems of any abstraction layer has ever had on any platform that has ever existed. The lessons from this article (that is 15 years old) is still relevant today:

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

Using the term "native" to say something is "not HTML" is sort of disingenuous. There is just a whole different custom layer in the middle instead.

jwarren3• 8 years ago

RN isn't a wrapped HTML renderer like Phonegap. It uses bridge code to render native UI powered by JS business logic. You still write in JSX, which makes layout pretty straightforward. With some careful optimisation, I had pretty solid 60fps scrolling performance on 1000 item/image lists on old Android devices.

i6mi63• 8 years ago

Did you use FlatList or ListView (or a custom module) for this? I've noticed that ListView sometimes does much better than FlatList, interested to hear what you used.

imeron• 8 years ago

Phonegap is pure crap in my mind. React Native is much much better, but still has it's issues. Also, it's not HTML based, you write JavaScript code to drive native components.

Fifer822• 8 years ago

Thanks for pointing it out to me guys, I am not in the react world and don't mind getting down votes for being corrected. Appreciated.

andrewingram• 8 years ago

You weren't rude, and not knowing something shouldn't be justification for a downvote. So you got an upvote from me.

TekMol• 8 years ago

    Android apps being required to target api 26 by August 2018.

    The urgent need for safe area support for the iPhone X.

Reading about these annoyances of native development reassures me to keep building web apps. They are so much more future proof.

rimliu• 8 years ago

Support for iPhone X is trivial unless you’d made bad choices before. Anecdote, but as having extensive experience in both areas (20 years web, 9 years iOS): natives has way way less annoyances.

pjmlp4• 8 years ago

Sure, because handling div soup and CSS across browsers is so much fun.

https://www.youtube.com/watch?v=eVnUDTtOLE0

hesarenu3• 8 years ago

get familiar with modern web development!

rhodysurf• 8 years ago

Both of these things are easy if you just don’t use react-native

k__4• 8 years ago

I don't understand.

I added iPhone X support to an RN app rather ad-hoc a week before it was released.

While I had a few issues with the resolution, safe-area wasn't one.

ricardobeat4• 8 years ago

https://facebook.github.io/react-native/docs/safeareaview.ht...

Has been there for at least 6 months.

kevinsd• 8 years ago

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.

blub2• 8 years ago

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.

jeremyjh2• 8 years ago

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.

haney3• 8 years ago

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

filleduchaos7• 8 years ago

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

murukesh_s• 8 years ago

+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..

zaidf• 8 years ago

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.

gilbetron• 8 years ago

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.

alangpierce2• 8 years ago

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.

spiritcat3• 8 years ago

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

nebulous1• 8 years ago

Some of the criticism is valid, such as the performance issues and the fact that overall they didn't feel that it was worth it, the issues with the speed of the ecosystem.

Some of it isn't valid. Build times increasing when you add RN to an existing project is to be expected. If you want very different UX on each platform then you'll generally have to implement it (as you would anyway). Internationalization is always a task, he's unclear why React is being criticized for this.

Overall my takeaway is that if you're looking for an app customized to the UX of each platform, and that's more important to you than having devs who can cover both platforms, then RN is not the way to go. They seem to feel that the work involved in producing the RN features was greater than the work involved to just do things natively twice.

chrisco2556• 8 years ago

If they're only using React Native for 3 or 4 features (as they say in the article) I could see how adding in i18n support would be challenging as you'd now have to maintain Java/Kotlin, ObjC/Swift, JS versions of this. But thats just true of the whole approach in general. I think if you're using RN for only 20% or less of your product, it probably is more trouble than it's worth.

ItsMe0000015• 8 years ago

For our use case RN has two major features missing:

- No file system access. We use react-native-fetch-blob (to which I actively contributed to add missing features and improve the code) which itself has quite a few disadvantages, such as a disappearing maintainer (fortunately a new one was found after a while, but the whole code has a few issues)

- The only way to transport binary data across the JS-to-native bridge is base64 encoded strings (expensive, has to be encoded and decoded on each side of the bridge) - if you need to read (raw binary) files and send them via websocket streams, as we do, you are screwed (I'm going to change the app design only because of RN so that this can be done within the native code without going through JS code)

laurent1234562• 8 years ago

For filesystem access, can't react-native-fs do the job? For a few things I found it less buggy that react-native-fetch-blob.

ItsMe0000015• 8 years ago

RNFB and RN-fs are the main two 3rd party modules that provide filesystem access. I chose one of the two after checking the code, the API, and the user base and commits (at that time the RNFB maintainer still was very active and had plans) to see which one looked more promising for my use case. I'm pretty familiar with both those modules down to the code (out of necessity, had to provide a lot of patches, I'm still using my own fork because when the maintainer disappeared there was no chance to get anything merged).

k__4• 8 years ago

Didn't finde the filesystem stuff too limiting, it was just different from other systems I was used to. But yeah, it's a bit of a pain.

And FB mentioned the native bridge will be overhauled.

ItsMe0000015• 8 years ago

Didn't finde the filesystem stuff too limiting

I don't understand. You don't need file system access? Then of course that's not a problem, does that need to be mentioned? Or you do need it, use a 3rd party app, and have not found the many issues of having to rely on a 3rd party module, such as when RNFB's maintainer disappeared (plus numerous code issues)? Since I care about future maintenance and I know that unpaid volunteers fed up with the demands placed on them by more and more users of their free packages I am not satisfied when at the time of use the package happens to work, I always look ahead and fear the future. When you have to unravel the whole thing a year later, when you have long moved on and have other things to do but now have a big maintenance issue on your hands because of some 3rd party package that you now have to maintain your own fork of, it's no fun.

And FB mentioned the native bridge will be overhauled.

That is a plan for the possibly far-away future. In the recent HN thread about RN plans the RN person who responded to questions ("spicyj") said "likely yes", so it's not a done deal yet even as far as plans go. Reference: https://news.ycombinator.com/item?id=17314315

loftyal• 8 years ago

https://docs.expo.io/versions/latest/sdk/filesystem

ItsMe0000015• 8 years ago

That's not RN but Expo on top of it.

We tried Expo and very quickly decided against it. I forgot the reasons, somebody else did it and reported the findings and we all agreed.

Besides, why would I add an entire pretty big layer on top of still beta RN (version number well below 1) only to get one tiny component? That only makes sense if one wants the entirety of Expo, and this is where our tester (if we should use it) quickly ran into numerous issues.

I understand that it's en vogue to immediately point to this or that npm package or github repo for every problem big or small, but we don't do that. We look at the sources of every package we include, and we look at possible maintenance issues. Our own stuff is trouble enough, we don't need the added problems of all those layers on top of layers of "stuff". I know it's "move quickly and sort it out later when the business has grown" - but we don't want to work like that whenever we can avoid it. Because we don't have an "exit plan", we ourselves will have to maintain the mess we create now...

thawab• 8 years ago

Thanks, the post answered most of the questions I might have if a team used react native and decided to switch to native code.

Would love to hear your opinion about the last post in react native blog:

https://facebook.github.io/react-native/blog/2018/06/14/stat...

mncolinlee3• 8 years ago

2500 commits seems shockingly low for all of Facebook. Doesn't that seem like there's some hardcore users and a lot of tepid users just kicking the tires? My "pizza" team at Amazon did almost that many commits in a year on mobile projects and we always rebased changes.

maxdo• 8 years ago

Airbnb complains had some real issues. Udacity “problems” looks artificial. Animation Performance on old androids - and then agreed it’s non RN issue. Android SDK 26 playstore limits only NEW apps at first and react 0.56-RC support it, so plenty of time (4 month to adopt). Notch support was available before first devices hit the market. I believe here is different beast - programming language as a religion. One of my devs was really sabotaging processes just because he hate JS.

ko27• 8 years ago

The 4 months timeline (November) is for updates to existing apps not new apps. The new app limitation already goes next month into effect.

cyberbuff• 8 years ago

Udacity “problems” looks artificial. Animation Performance on old androids - and then agreed it’s non RN issue.

I think they specifically mentioned that some of the problems were not due to RN, it was their use cases.

tzahola8• 8 years ago

One of my devs was really sabotaging processes just because he hate JS.

Did you fire him/her?

illuminati1911• 8 years ago

I hope they fired the people who thought using JS in 2017/2018 unless absolutely necessary is a good idea.

Both Kotlin and Swift are extremely elegant and modern languages with awesome set of features while JS lacks fundamental things like type(s)afety and is filled with inconsistency errors/problems etc.

And yeah yeah, JS is not complete garbage. I'm well aware of that, but there is no point bringing a broken knife into a gun fight.

anothergoogler2• 8 years ago

The load time when entering into the React Native portion of the app was longer than we would have liked. It often did not feel like a seamless transition.

That is a "real issue." Frame it however you want, React Native is a compromise. Performance is a huge deal to users. It's not hard to tell when you're running one of these "one size fits all" apps.

LandR3• 8 years ago

One of my devs was really sabotaging processes just because he hate JS.

To be fair, JS is a mess.

Although if I was a dev and asked to write JS, I wouldn't sabotage stuff! Probably just leave and get another job.

Seriously though, what do you mean by sabotaging stuff? What form did this take?

sodafountan4• 8 years ago

But to be even fairer, JS has evolved into quite a nice language to work with over the last few years and I'd hope that developers who've used it in the past would take the time to re-evaluate it.

fulafel• 8 years ago

JS is a mess, but it's a fair compiler target. React Native is good because it lets you use nice languages like ClojureScript or Elm to write mobile apps.

_alexander_• 8 years ago

Is it the new trend to publish articles about moving from React Native? :)

meiraleal2• 8 years ago

I hope it produces a "counter attack" from RN the same way the trend about moving from React because of its license made Facebook remove that patent thing.

danabramov• 8 years ago

What do you mean by a "counter attack"?

React Native usage at Facebook is growing. We know there are issues around integrations with existing native code, and they've been the motivation behind the ongoing large-scale changes in the internal architecture (which started in the beginning of this year).

We posted about those changes a few weeks ago so you might be interested: http://facebook.github.io/react-native/blog/2018/06/14/state...

Once that work is done it should make integrations with existing native code much easier. You can see that some of the post's content directly matches the pain points listed by Airbnb and Udacity -- because we bumped into the same problems and are working on the solutions.

solidr53• 8 years ago

I have a pretty solid counter argument lining up to be published soon (less than 2 weeks, hopefully not too late). I feel that those who had such a bad experience are just doing it wrong.

It has to do with native navigation. What apps are all about.

mromanuk• 8 years ago

IMHO, The promise of multi-platform dev is sharing code and reusing resources (including developers) which generally comes subpar with native developing for several reasons. Having 2 separated teams of iOS and Android, they should aimed for native in each platform.

voidr• 8 years ago

1 iOS dev 2 Android devs 1 PM 1 Designer

They didn't have a single JS/Web developer at the start.

There was also an issue that caused a crash because one version of npm had a `package.lock` and the other didn’t which caused us to install incorrect versions of a dependency across a React Native upgrade.

This issue I would attribute to their lack of experience or knowledge of how NPM works, not to ReactNative.

Lastly, CI for the iOS project was a pain point as well. We now had to add an npm dependency layer and make sure those were being updated properly before continuing the install. This added nontrivial amounts of time to our build step.

The same way if I would add Java to my JavaScript project, my build time would increase.

There are a lot of legitimate complaints in the article, but a lot of their issues stem from their lack of web experience.

emilioicai• 8 years ago

They state the iOS dev had some experience with JavaScript and web. I wonder how much and how old that experience was.

akura• 8 years ago

Yeah, the team makeup is the interesting aspect for me. It seems they took an existing mobile engineering team and had them integrate react native.

Our experience was opposite in that we had a web/js team and decided to go to react native as a way to deal with a mobile app that we couldn't maintain well (and couldn't justify the hiring of dedicated devs for).

React native gave us an avenue to utilise existing skills and overall we found it pretty positive.

dave_sid4• 8 years ago

It’s incredible the lengths intelligent, experienced developers will go to, to avoid learning iOS or Android development. It’s a small bump to overcome to unshackle your project from an ever changing comfort blanket between yourselves and the platforms, that inevitably lags behind and is ultimately a comfort blanket that’s future is always in the hands of a third party. If your developing iOS and android apps in JS, then you’re smart enough to get stuck into Xcode/Swift and Android/Java, and you’ll probably never look back. Sounds like most RN devs find themselves in the trenches often enought as it is.

chrisco2556• 8 years ago

Software development is already crazy expensive. Do you know how much it costs to build and maintain web, iOS, and Android apps? It's ridiculous. It's not a matter of not wanting to learn each platform. As Udemy pointed out, they ended up with 4 devs on each platform. They also have who knows how many devs on web and platform / backend services. Udemy is a successful product with market fit I'm sure they're doing fine either way, but for many startups this kind of efficiency can mean life or death. Not many can afford to burn through $100-$200K per dev just to reinvent the wheel wiring a bunch of REST calls up.

mncolinlee3• 8 years ago

That's precisely the point. Airbnb decided they were now maintaining web, iOS, Android, AND THEN React Native instead of only web and React Native. Their costs went up, not down.

I've found far too often over the years that companies decide to use a hybrid framework to save time and money and take just as long to write the app with equally as much cost. Then no one wants to maintain the finished product. It requires too many unlikely skill sets and trickier debugging.

React Native isn't automatically cheaper because it's a hybrid. Hybrids work great for trivial apps that look a lot like the examples. A hybrid framework also has to address every new niche the native solution fills or else integrations themselves add up to a massive cost.

dave_sid4• 8 years ago

Half an hour wiring up some well understood rest calls vs tearing your hair out close to a deadline when React won’t call a new feature? Always keep it simple I say.

hesarenu3• 8 years ago

The issue is multiple codebase which can diverge as well. But yes using swift/kotlin would be the way to go. RN developer here learning native code now.

yomansat• 8 years ago

The trouble here isn't with learning a platform, but with having to develop and maintain two. Web tools often allow hot reloads so a smaller feedback loop.

dave_sid4• 8 years ago

Maintaining two code bases is not a big deal. Check them both out side by side. There they are right in front of you. Is sold as a bigger problem than it really is.

jacksmith21006• 8 years ago

Really think Flutter will eat into a lot of React Native use.

So far really loving Flutter. The hot reload speed is just incredible. Plus there is some unusual features.

One is widgets keep state so can go directly to where you were already at when developing. This makes you a lot more productive and experiment a lot more.

The other is able to be somewhere in the app your are coding and just click that page on the screen and takes you to the code behind it.

Also it does look like Flutter is the future as the native UI for Fuchsia.

spiritcat3• 8 years ago

waiting for react-flutter here

SneakerXZ• 8 years ago

What would it do? Flutter uses same approach to UI.

jokoon• 8 years ago

Look, cross platform is already a lost cause as OS manufacturers will always departs from competitor design flavors, so that it will be costlier to adapt to other platforms, so each OS manufacturers can have loyal developers who won't write code that work on competitor's platforms. This has been happening for ever.

Secondly, how many time is it necessary to whine that javascript is a bad technology, and that anything that stems from it is destined to less than optimal ends?

JS is great but only for deployment, and it has been its best strength, but JS cannot thrive on mobile, because mobile platform don't offer programming flexibility. Less memory, tighter chips, less battery. Converting from one language to another, and adapting design so it can fit is hacky.

Why does everybody is always jumping in on brand new shining ships?

sebringj• 8 years ago

My issues have been related to difficult builds at times and hard to fix performance problems but my use case demands better performance with videos in a feed streaming as you scroll down when viewed. I would say react native is not bad when you keep things light and simple but go native when you have critical performance. you'll find that instagram uses rn in certain parts like that, definitely not on their feed and on their filters or AI related filters.

untog• 8 years ago

I wonder whether React Native was just a little too late to arrive. As someone with a majority JS background I could never quite get into Objective C (I never tried that much to be fair, just hobbyist stuff) but took to Swift immediately. There were enough rough edges around RN when I played with it that I preferred simply working with Swift directly.

The one exception to this is cross-platform stuff. I wish Swift could compile to be used on Android easily, but alas.

mattbierner• 8 years ago

I started as an iOS obj-c developer but do web development stuff mostly these days. I found it extremely frustrating to go back to Xcode and swift. It’s not about being able to write in JavaScript (or Typescript); in my opinion react native offers a significantly better developer experience around debugging, dependency management, interface building, iteration speed, testing, and sharing code. Hot reloading, npm, and “flex” layouts alone made react native more than worth it for me.

I am only writing simple apps—not even cross platform ones—so I can’t speak to the pain points from this article. But I do hope that Apple learns a thing or two from react native. Once you realize how much better iOS development could be, it’s very hard to go back to Apple’s current developer story.

mncolinlee3• 8 years ago

There's always Kotlin, which adds a lot of the niceties of Swift when writing Android code.

Kotlin also works on iOS through AppCode and Kotlin/Native, but that integration is still very young. I can't promise you won't have platform issues along the way.

stanq• 8 years ago

Great! I'm finished React/React Native course at Udacity a couple month ago. But now, they don't use it.

iOSGuy• 8 years ago

Seems like both AirBnB and Udacity made the mistake of not investing enough in the tech. If you keep building out full native features while transitioning a brownfield app to RN, you’re going to have this fragmentation problem.

I’ve converted, (with lots of help of course), a massive brownfield platform product to RN. It took a lot of work, building the right bridging layers, retraining the team, figuring out best practice, etc. We still have a lot of tech debt, but it works!

Pros: Solid cross platform development, easy to teach, easy to get up and running on Xcode/Android Studio (running and working on both in first week on the job), easy to teach the native languages from there, real time bug fixes, fast iteration times on new features. Cons: No 64b on Android, Android peformance lags behind iOS, RN bugs, build process was tough to nail down, no built in navigation support.

We’ve now solved most of the huge RN exclusive problems we had with RN we had when we started out, so at this point I’m not going to be abandoning it anytime soon. There are still problems, but just your average engineering problems, same as you’d get in native development land or any other platform. It’s been about 3 years now, with a 10+ person team now, so maybe I should write it all up somewhere.

kodablah2• 8 years ago

but it works!

Did it not before? Of those pros you mentioned, are they worth the many year investment you made and are continuing to make in the tech? Hypothetically, if the tech were to fall out of favor soon, does that change the worthiness?

jmhyer123• 8 years ago

It’s been about 3 years now, with a 10+ person team now, so maybe I should write it all up somewhere.

Please do! I'm about a year into a cross-platform app build on react-native and I'd love to hear/learn from your experience.

spencerg12• 8 years ago

Yes, please do!

augbog• 8 years ago

Would love to hear your findings :)

username3• 8 years ago

Where will you publish the write up?

axemclion2• 8 years ago

It’s been about 3 years now, with a 10+ person team now, so maybe I should write it all up somewhere.

If you want, we could put this up on the React Native Blog. Would make for an interesting read !!

abledon2• 8 years ago

React-Native... the new Metor.js

abledon2• 8 years ago

   > At other times, React Native lags behind in the adoption 
   of new platform requirements such as Android apps being 
   required to target api 26 by August 2018.

Just keep moving the target, good strategy to mess them up.

hecontreraso• 8 years ago

"We removed the last traces of React Native from the apps because the only remaining React Native feature was being sunset and we no longer had to support it."

I didn't expect a clickbait from a serious company like yours.

CGamesPlay• 8 years ago

Great read. There are obviously lots of different issues here, but the biggest takeaway I have seems to be: Udacity wasn't building a single app that ran on multiple platforms. They were building 2 separate apps that each ran on a single platform, and there happened to be a lot of overlap which made React Native look appealing.

It turned out that the overlap wasn't enough, or else the team would not have done things like ever allow a feature into the tree that didn't work on both platforms before merging (i.e. let the trees get out of sync). Useful to consider before you adopt React Native in another app.

Apocryphon• 8 years ago

It really does seem like that a commonality between the AirBnB apps (huge team) and the Udacity apps (much smaller team) is that both introduced React Native to preexisting apps. If they were designed and created with RN in mind from the ground up, the experience would be likely different. However I'm not sure if there's such a case study for any prominent app using RN complete- not even Facebook's apps. Instead, most of these are hybrid, between native and RN.

Mc_Big_G• 8 years ago

These retros are surprising. I tried RN for one day and realized the massive limitations and eventual need for native libraries and tools. It seems so obvious.

0xfeba• 8 years ago

I can concur with the breaking changes point. That and unmaintained libraries. It seems after a certain size you need to devote 10% of your time to just trying to keep libraries up to date security wise.

And then libraries get abandoned. "Your still using LibA? Switch to LibB!"; "Critical vulnerability! Upgrade LibX now! See migration guide to go from 1.2 => 9.1" literally 30 times across our projects...

raprp• 8 years ago

Thanks for the feedback. We've started investing heavily on RN and I was starting to get worried seeing big companies jumping ship.

arisAlexis• 8 years ago

so basically you hired more android and ios developers and they kicked out RN while the whole purpose of it is not ti have dedicated mobile developers. sounds like your taxi drivers would not like uber too..

React Native: A retrospective from the mobile-engineering team at Udacity

Related Stories