17 ms·

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

285 points by phaedryx 8y ago

haney 8y 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 8y 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.
  - meiraleal 8y 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 8y 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.
- danpalmer 8y 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_ 8y 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.
    - danpalmer 8y ago
      I did say “probably”. Facebook and Instagram definitely care about the last bit of performance. Your typical line of business apps don’t need to, and that’s a lot of the market.
      - Longhanks 8y ago
        Do they? Their apps are so inefficient that both of them have a "lite" version (instead of fixing the main apps) to save memory and perform better.
        samat 8y ago
- spicyj 8y 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/state-of-react-native-2018 https://facebook.github.io/react-native/blog/2018/06/14/stat...
  - ckluis 8y 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_off 8y 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.
  - chrisco255 8y 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.
    - on_and_off 8y ago
      RN is a compromise, and a very big one. It might be the right choice for some products but my experience on complex products more closely reflects the Airbnb one than the myth of 'only know js, write once, run everywhere'
    - filleduchaos 8y ago
      I wouldn't exactly call the Skype app a success. Easily the worst communication app on my phone by far. To be fair, a lot of that is in the product vision and design and not entirely React Native's fault.
q-base 8y 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.
txmjs 8y 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!)
- jwarren 8y 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 8y 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.
    - ricardobeat 8y ago
      That's the entire proposition - easier to build, faster to iterate, cross-platform development, overlap with web development skills (and ecosystem).
    - x0x0 8y ago
      The giant carrot is reducing ios + android development from, say, 80% more work than ios alone to even 20% more work.
      - kybernetikos 8y ago
        And with the right practices it's possible to share a huge amount of Web code too.
amelius 8y ago
How does it compare to Flutter?
- cmjqol 8y 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.
Fifer82 8y 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 8y 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.
  - wvenable 8y 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-abstractions/ 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.
    - ricardobeat 8y ago
      Not disingenuous at all - all the rendering code is _native_, no subtle hidden meanings. No webviews, no custom drawing, all existing platform components - that's as 'native' as you can get.
      - 8y ago
TekMol 8y 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 8y 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.
- pjmlp 8y ago
  Sure, because handling div soup and CSS across browsers is so much fun. https://www.youtube.com/watch?v=eVnUDTtOLE0 https://www.youtube.com/watch?v=eVnUDTtOLE0
  - hesarenu 8y ago
    get familiar with modern web development!
    - pjmlp 8y ago
      I am painful familiar with web development!
      - jazoom 8y ago
        GP said "modern"
        pjmlp 8y ago
        I am painful familiar with "modern" web development! Happy for being pedantic?!
        jazoom 8y ago
kevinsd 8y 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.
- blub 8y 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.
  - jeremyjh 8y 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.
    - Cthulhu_ 8y ago
      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).
nebulous1 8y 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.
- chrisco255 8y 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.
ItsMe000001 8y 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)
- laurent123456 8y 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.
  - ItsMe000001 8y 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__ 8y 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.
  - ItsMe000001 8y 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 https://news.ycombinator.com/item?id=17314315
thawab 8y 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/state-of-react-native-2018 https://facebook.github.io/react-native/blog/2018/06/14/stat...
- mncolinlee 8y 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 8y 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 8y 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 8y 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.
- tzahola 8y ago
  >One of my devs was really sabotaging processes just because he hate JS. Did you fire him/her?
  - illuminati1911 8y 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.
    - coding123 8y ago
      That might be a perspective, our team uses typescript and we feel it's like bringing the army to a gun fight.
_alexander_ 8y ago
Is it the new trend to publish articles about moving from React Native? :)
- meiraleal 8y 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 8y 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-of-react-native-2018 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 8y 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 8y 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 8y 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 8y ago
  They state the iOS dev had some experience with JavaScript and web. I wonder how much and how old that experience was.
- akura 8y 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_sid 8y 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.
- chrisco255 8y 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.
  - mncolinlee 8y 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_sid 8y ago
jacksmith21006 8y 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.
- spiritcat 8y ago
  waiting for react-flutter here
  - SneakerXZ 8y ago
    What would it do? Flutter uses same approach to UI.
    - spiritcat 8y ago
      I guess just looking over the flutter docs, I'd miss jsx too much. Also hopefully a more stable backend to target with less differences between platforms.
jokoon 8y 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 8y 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 8y 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 8y 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.
- mncolinlee 8y 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 8y ago
Great! I'm finished React/React Native course at Udacity a couple month ago. But now, they don't use it.
iOSGuy 8y 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.
- kodablah 8y 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 8y 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 8y ago
    Yes, please do!
- augbog 8y ago
  Would love to hear your findings :)
abledon 8y ago
React-Native... the new Metor.js
abledon 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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..

285 points by phaedryx 8y 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 8y 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.
- meiraleal 8y 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 8y 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.
danpalmer 8y 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_ 8y 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.
  - danpalmer 8y ago
    I did say “probably”. Facebook and Instagram definitely care about the last bit of performance. Your typical line of business apps don’t need to, and that’s a lot of the market.
    - Longhanks 8y ago
      Do they? Their apps are so inefficient that both of them have a "lite" version (instead of fixing the main apps) to save memory and perform better.
      - samat 8y ago
spicyj 8y 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/state-of-react-native-2018 https://facebook.github.io/react-native/blog/2018/06/14/stat...
- ckluis 8y 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_off 8y 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.
- chrisco255 8y 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.
  - on_and_off 8y ago
    RN is a compromise, and a very big one. It might be the right choice for some products but my experience on complex products more closely reflects the Airbnb one than the myth of 'only know js, write once, run everywhere'
  - filleduchaos 8y ago
    I wouldn't exactly call the Skype app a success. Easily the worst communication app on my phone by far. To be fair, a lot of that is in the product vision and design and not entirely React Native's fault.

q-base 8y 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.

txmjs 8y 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!)

jwarren 8y 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 8y 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.
  - ricardobeat 8y ago
    That's the entire proposition - easier to build, faster to iterate, cross-platform development, overlap with web development skills (and ecosystem).
  - x0x0 8y ago
    The giant carrot is reducing ios + android development from, say, 80% more work than ios alone to even 20% more work.
    - kybernetikos 8y ago
      And with the right practices it's possible to share a huge amount of Web code too.

amelius 8y ago

How does it compare to Flutter?

cmjqol 8y 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.

Fifer82 8y 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 8y 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.
- wvenable 8y 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-abstractions/ 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.
  - ricardobeat 8y ago
    Not disingenuous at all - all the rendering code is _native_, no subtle hidden meanings. No webviews, no custom drawing, all existing platform components - that's as 'native' as you can get.
    - 8y ago

TekMol 8y 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 8y 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.
pjmlp 8y ago
Sure, because handling div soup and CSS across browsers is so much fun. https://www.youtube.com/watch?v=eVnUDTtOLE0 https://www.youtube.com/watch?v=eVnUDTtOLE0
- hesarenu 8y ago
  get familiar with modern web development!
  - pjmlp 8y ago
    I am painful familiar with web development!
    - jazoom 8y ago
      GP said "modern"
      - pjmlp 8y ago
        I am painful familiar with "modern" web development! Happy for being pedantic?!
        jazoom 8y ago

kevinsd 8y 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.

blub 8y 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.
- jeremyjh 8y 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.
  - Cthulhu_ 8y ago
    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).

nebulous1 8y 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.

chrisco255 8y 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.

ItsMe000001 8y 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)

laurent123456 8y 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.
- ItsMe000001 8y 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__ 8y 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.
- ItsMe000001 8y 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 https://news.ycombinator.com/item?id=17314315

thawab 8y 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/state-of-react-native-2018 https://facebook.github.io/react-native/blog/2018/06/14/stat...

mncolinlee 8y 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 8y 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 8y 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 8y 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.
tzahola 8y ago
>One of my devs was really sabotaging processes just because he hate JS. Did you fire him/her?
- illuminati1911 8y 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.
  - coding123 8y ago
    That might be a perspective, our team uses typescript and we feel it's like bringing the army to a gun fight.

_alexander_ 8y ago

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

meiraleal 8y 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 8y 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-of-react-native-2018 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 8y 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 8y 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 8y 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 8y ago
They state the iOS dev had some experience with JavaScript and web. I wonder how much and how old that experience was.
akura 8y 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_sid 8y 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.

chrisco255 8y 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.
- mncolinlee 8y 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_sid 8y ago

jacksmith21006 8y 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.

spiritcat 8y ago
waiting for react-flutter here
- SneakerXZ 8y ago
  What would it do? Flutter uses same approach to UI.
  - spiritcat 8y ago
    I guess just looking over the flutter docs, I'd miss jsx too much. Also hopefully a more stable backend to target with less differences between platforms.

jokoon 8y 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 8y 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 8y 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 8y 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.
mncolinlee 8y 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 8y ago

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

iOSGuy 8y 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.

kodablah 8y 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 8y 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 8y ago
  Yes, please do!
augbog 8y ago
Would love to hear your findings :)

abledon 8y ago

React-Native... the new Metor.js

abledon 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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..