React Native: A retrospective from the mobile-engineering team at Udacity
engineering.udacity.com
engineering.udacity.com
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.
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?
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.
If you want, we could put this up on the React Native Blog. Would make for an interesting read !!
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!)
Based on my limited experience with native iOS app development, RN actually requires an almost completely different way of working.
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.
2. The app starts with a launch image (the logo in the center), which then fades away to show another launch image (with the logo on the top half of the screen): https://imgur.com/0n3Zbof (probably because ReactNative must load the JS bundle before it can show anything)
3. The login screen of the application fits on the screen, yet it can be scrolled up/down for seemingly no reason. The amount you can scroll feels suspiciously close to the height of the iOS status bar: https://imgur.com/P6conGz (probably because ReactNative sets the UIScrollView's contentInset incorrectly)
4. Text fields / buttons look like on a website.
5. When you navigate back from the login screen after a failed login, there's a brief moment while the "Unsuccessful login with Facebook" message is visible, which then quickly disappears: https://imgur.com/hTTKbIt
Sorry, but it feels like a webapp to me. Though it might be perfect for your use case!
Update: I've found some other issues:
6. You can't interact with buttons (e.g. "Next" button on registration) while the keyboard is visible: https://imgur.com/dpy5xv8
7. The first time you switch to a tab, it's completely empty, then suddenly the content pops into place: https://imgur.com/JKaCJED
8. Tapping on the search button makes the content of the previous page jolt against the top of the screen while navigating to the search page: https://imgur.com/BJDYvda (focus on the panda)
9. The "sidebar" menu feels very out of place on iOS. Also, when you select e.g. "Settings", the content on the right does a very weird fade/slide animation: https://imgur.com/ChNzvwW
10. When you switch between two non-adjacent tabs, the viewport slides over the in-between tabs too: https://imgur.com/BZFU0Sv
1. This can easily be fixed with a module, however time pressure didn't allow for additional "tweaks"
2. Same as 1.
3. Using Scrollview for this, since some android devices with smaller screens can make the Login screen look very ugly and small, so in that case scroll looked better.
4. Do they look like or feel like ones on a website? It is by design, but interested to see how you feel about the fields as a user (although we don't support the app anymore)
5. Caused by implementation logic
See UberEats, the former Airbnb app and others using ReactNative that can seamlessly deliver native style UX.
2. The Airbnb and UberEats apps were written by expert native developers (I happen to know a few of them), using some React Native.
You see, expert native engineers can deliver quality apps using native frameworks. And surely, if they look into React Native, most of the time they can manipulate it from the JS side to get the desired outcome on the native side. The middleware is a hinderance for them as it gets in their way of implementing what they want in the first place.
It's like building those ship models in a bottle: if you know how to build the ship, you just have to learn how to do it through the neck of the bottle. If you don't know how to build it in the first place, well... that's a different story.
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.
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.
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.
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.
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.
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.
1: https://instagram-engineering.com/react-native-at-instagram-...
You linked to a post about a bunch of settings/picker screens in Insta. On the FB side, my understanding is that only the Marketplace tab is RN, and maybe the settings & notifications.
Removing messenger and fb app has increased my phone's battery life and my phone has become faster.
However, most apps are not ecommerce apps that will have a measurable benefit from speeding up particular views.
https://facebook.github.io/react-native/blog/2018/06/14/stat...
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.
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.
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.
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'
To be fair, a lot of that is in the product vision and design and not entirely React Native's fault.
I think they specifically mentioned that some of the problems were not due to RN, it was their use cases.
Did you fire him/her?
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.
Also, type safety isn't a "fundamental thing" it's a design decision made by the creators of the language.
Nevermind that it's easy to add types to JS these days if you really want them.
How you architect a system and manage state (and how simple you keep it) has far bigger implications than types.
Looking from the other side, this seems like "static typing gives me illusion of safety, and I miss it in dynamic languages". Sure, it might be justified for large projects in the long run, but
> taking the convenience of an untyped language is usually a poor/lazy architectural decision.
sounds like not understanding (or unwilligness to use?) trade-offs involved, due to personal preference.
I don't like these (unintentional?) claims of superiority based purely on personal preference. Static typing is just a tool, with its pros&cons.
Also they aren't exactly being rewritten in JS - the person who tweeted that later casually clarified that "well, actually" they're using JS as a sort of build system/integration over a still huge amount of native code.
And yeah I saw the tweet and the response, it sounds to me more like they're building specific components of applications with javascript, not really build systems.
It's almost like some of the best developers in the world like to use the right tool for the right job, and in many cases that tool appears to be javascript.
FIRE THEM!
If you consciously produce poor work because you disagree with that technical decision, rather than either going along with it or finding more a more appropriate venue to express that disagreement, that belies an attitude that's seemingly at odds with being a member of a collaborative workplace.
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.
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?
Web front end and JS just seems like insanity.
I don't know how anyone can use node...
What would you recommend to someone averse to js to try and change their mind?
I don't know how anybody could see what's going on with React and not be interested, it (at least for me) took what was once a very painful process of manipulating the DOM and working with the front-end and made it into an enjoyable and streamlined process. React actually brings order to what once a very messy and insane process.
I've used Node in production, it works very well for rapid prototyping. I could get a Node app up communicating with a diverse set of public APIs in minutes. It's not like Java or C# where I'm having to fumble around with a hefty IDE, a bunch of very strict typing, an entire compilation process and massively bloated web libraries. Node is a very lightweight alternative to that.
I think it's kind of a shame that the JS ecosystem has such a steep learning curve, which I think is where a lot of the hate stems from but once you learn it can be quite a powerful stack.
I guess it depends on what your concerns are:
• If you're worried about too many libraries to pick from, I'd just go with the most popular ones. React is a pretty solid choice.
• If you're worried about config being a pain, I'd recommend going with one of the starter tools like Create React App. Build tools are indeed a bit complex, but hopefully that's getting better over time.
• If you're scared by lack of type safety or worried about language quirks, I'd recommend TypeScript. (Flow is also quite good.)
In particular, TypeScript (and Flow) provides much more flexible static typing than I've used in any other mainstream language. You get the nice navigation, autocomplete, and static checking that you'd expect from a typed language, and I've found that I spend much less time needing to think about how to write my code in a way that appeases the type system.
Here's a tutorial that hits all of the points above: https://github.com/Microsoft/TypeScript-React-Starter
I'd recommend taking a look at Vue (https://vuejs.org/v2/guide/). You can write nontrivial and well-structured apps with just a text editor and not deal with npm/node unless you choose to. I also find it to be both simpler and more flexible than React.
But as a language for professionals who are willing to spend 40 hours a week on it and devote week after week to learning the internals of massive, rickety declarative APIs like Babel and Webpack, yes JavaScript has improved a lot for that audience.
You have to be a dedicated professional though, ideally a former Rubyist. If you’re not, stay away. Learn Python.
If you’re 20 and have learned just the basics of coding, but have not made any deep forays into software engineering, and can focus on a brand new codebase, and only support bleeding edge browsers, modern JavaScript is also ok too.
Personally I think it’s the wrong direction. I went back to ES5 and am developing a non-insane toolset for that language.
I love Clojure and from what little tried, I like Elm...
I had no idea I could do clojure > react nactive to get an app! I'll look into this, thanks!
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.
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.
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.
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).
I believe they have some automated tooling to update the APIs when Apple releases newer versions of the iOS SDK, so usually new features arrive on the same day in Xamarin iOS SDK as they do in Apple's iOS SDK.
I am not sure if the situation is the same for Xamarin and Android.
I wouldn't really hesitate to use Xamarin again in the future if a client requested it, but I haven't tried React Native yet and not sure if I should dedicate time for it or if it'll be gone in a few years. Seems quite a few mobile jobs require React Native experience these days.
What use is "productivity" without a performing product?
Is it a high-value feature to the end users? Then absolutely, you're correct.
Anyway, in my experience, most good PM and designers want an understanding as towards the amount of effort their features and designs mean for engineers. So if you aren't providing them that feedback, and letting them to factor that into their process, you're doing them a disservice.
I mean, I can double my native productivity that way too !
If you need an app on both Android and iOS quickly, have low quality concerns and only one web dev .. RN is a no brainer.
It kinda occupies a completely different valley of the fast/cheap/good graph
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.
If you tell me we can't hit business objectives because the team wants to use react native instead of swift without a really good reason, it's not going to work.
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.
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.
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?
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.
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.
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...
Android apps being required to target api 26 by August 2018.
The urgent need for safe area support for the iPhone X.
Happy for being pedantic?!
And if you're painful (sic) familiar with modern web development why are you still creating div soup?
That Web designers are still playing catchup with native RAD tooling from the 90's?
That React devs so enthusiastically re-discovered how 90's UI were keeping up to speed with slow hardware?
Or maybe because GPU acceleration requires CSS tricks with Z-Order to actually work?
That said for native apps be it desktop or mobile using native tools would be the way to go.
What's the state of the art in 2018? Can you have a DIV with a fixed aspect ratio fitted to the screen? Last time I've checked (in 2017) this was impossible without JS.
It's admittedly far from obvious, but that should be doable by determining the height of the DIV with the padding-top of a child element, and limiting the width with max-width limited to at max height * aspectratio, so it doesn't overflow the bottom if the page gets to wide. Not really anything fancy and new in there either.
EDIT: s/width/height, added half sentence explanation.
Sorry, I don't understand this.
max-width: calc(100vh * 16 / 9);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.
Has been there for at least 6 months.
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.
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.
It has to do with native navigation. What apps are all about.
The one exception to this is cross-platform stuff. I wish Swift could compile to be used on Android easily, but alas.
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.
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.
- 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)
And FB mentioned the native bridge will be overhauled.
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
Used Expo for this. It required me to rethink a few things but in the end it worked like a charm and I didn't event need to detatch.
I used it for offline storage of video and audio files.
Didn't touch the code that interacts with that lib for half a year now.
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...
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...
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.
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?
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.
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.
React Native takes smaller markup and a subset of CSS and renders it using native components. So how is that as native as you can get in comparison?
I agree that layer between markup and native controls is thinner in React Native but the actual abstraction is actually very comprehensive. iOS and Android applications are constructed quite differently from each other. And React Native is itself different from that. It has an entirely different API with a whole different model for how applications are made. So much so that the platform differences are almost completely papered over. So is that native?
I disagree that the idea of "native components" trumps the fact that practically everything you do in React Native is different from the underlying platform. Ultimately that seems like the least important detail. The abstraction is actually what makes React Native useful but it shouldn't be sold as "native".
The only issue was there was a bug in RN core. We submitted a PR which was finally accepted about 6 months later: https://github.com/facebook/react-native/issues/16612#event-...
> 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.
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.
I didn't expect a clickbait from a serious company like yours.