Why did Airbnb dump React Native? (2021)
theimmigrantprogrammers.com
theimmigrantprogrammers.com
That said, I find it perfectly represents about 90% of React Native evangelism: someone who has never shipped an app copying and pasting talking points to shill their YouTube channel.
Also, I got my first DMCA takedown the other day. They said I'm allowed 3 before they delete my site. All my videos passed the copyright check when I uploaded them so I relied on that as fair use. It occurred to me that my site will inevitably be taken down if 3 is the limit so I've lost all motivation to use it for anything.
As others have linked, Airbnb actually did write a summary about this.
Basically what went down: For years Airbnb had actually pretty strong native mobile engineering both on iOS and Android (some of the best engineers I’ve worked with) there was no issue investing more in to it. The had the resources, platforms were working well.
The main challenge however was that anything the company needed to launch, needed to be built on 3 platforms at the same time (4 if you count tablet). Timelines were often tight which made the overall coordination between the platforms tough.
One the main examples of this was when 2015-2016 team I was part of basically redesigned and rebuilt the mobile apps, and created a design system/component/layout library at the same time for each platform. It was a huge effort.
At the same time, there was one guy basically hacking on React Native and ended he built the whole component system by himself in few weeks, compared to the months it took in native platforms. This was obviously impressive and company decided to experiment if we could use RN more to speed up development. I think the idea was never to fully replace the native platforms or even core flows, but there were lot of random flows and screens in guest and host apps which only minority of the users see.
So 2016-2019 there was a core team working on a RN adoption, and different people and teams used it in different projects. There were some technical issues at times with performance and navigation that got eventually solved.
However where it all came down was there wasn’t that much adoption and there wasn’t clear group who would actually use RN. Mobile engineers didn’t want to write RN code and web engineers didn’t want to build on mobile. RN also requires understanding of the native platforms, and if the point is build both for iOS and Android, then you need to understand both platforms which is a rare skill set.
So in the end it was just more complicated than it was worth.
I think new company/product can build the team and culture around RN will have better success.
I’d still think if it’s the right choice given what you are building. No matter how good you are I think the RN/Flutter apps can be ok it’s really hard to make them feel fully native.
There were many people who claimed they have achieved all three, but at the close examination all of them, 100% without exception, were missing many little things like standard shortcuts, respecting color preference in user settings, or just couldn't see the difference between 11pt and 13pt fonts while looking directly at them.
10 years ago I worked on rewriting Qt interface of a desktop app back to native for a similar reason, and now I am reading all the same story except it's about React Native in mobile apps.
But wouldn't knowing that require that you investigated the tech choices of all the apps you are using? If not, there's a slight fallacy in that you only _know_ that the app is cross platform when you can see that it is. So then obviously all the apps you know is cross platform will look out of place, because that's how you know they are cross platform. Not sure I'm making the argument very well.
For instance, I'm don't think that the Discord app for iOS and Android looks out of place [0].
> Switching to React Native for the Android app means an experience that is ever-improving at a more rapid pace across every platform Discord is available on, while still retaining Android and iOS specific patterns in the UI.
[0]: https://discord.com/blog/android-react-native-framework-upda...
It has a good rating in app store today. Better than Slack, even. And although there are probably many reasons for that, atleast RN hasn't killed the ratings.
Seems like the bigger problem is their QA department than their engineering decisions
I did investigate every app I ran, because I was programming UIs and was interested in all tech that was there. To the point of being able to tell whether the app was written with Delphi or Qt or MFC/ATL by just playing with it.
Qt apps on Mac always stand out, being "OK" is the top they achieve.
Windows is less offended because it has never had a stable style, but still, there are always tiny details like context menus or not responding to Ctrl+Arrows that give non-native away.
Mac OS X looked a little off, especially the spacing.
A few years ago I worked on Java application using SWT. It looked very OK on Linux/Mac/Windows. Even original AWT in Java was cross-platform an native. The problem with Java was GC pauses, but this is a solved problem now.
Java actually succeeded quite well at being cross-platform, it just wasn't a design worth being cross-platform in the first place.
Hopefully they fixed some of this in 20 years.
I wonder if those tight timelines seem justified in retrospect. The stress. Missed social events.
Engineer stress is manager success. You get burnout, they get payout.
I want to put this on a t-shirt
That's interesting. In our experience, we're having a difficult time hiring folks that want to write native (including UI) in antiquated languages and frameworks - but it's much easier to hire JavaScript folks that just hack at RN.
Of course, someone still needs to stand up the actual platform, as well as write shared (and sometimes platform specific) pieces of functionality mostly in C++ so for now I guess us oldtimers still have some job security :)
No iOS developer considers Swift antiquated (because it isn't). I'd argue no one even considers UIKit antiquated (middle aged, maybe). Maybe with the exception of brand new iOS developers who has jumped on the SwiftUI-only bandwagon. SwiftUI itself is so new that it barely is production ready.
Sounds to me like you are actually looking for web developers who doesn't want to start learning native, but are OK to do the work in JS.
Ended up using react-native-web in an Electron container to make a desktop version of an RN app, which worked surprisingly well.
These people probably have never worked on a production RN app or done upgrades and maintenance for one.
It just suffers because everybody "knows React" so how hard could it really be and people get hired into roles working on RN with very little understanding of how it's different from a web based React project.
I’m which land is Kotlin and Swift antiquated? Both a modern and cutting edge technologies with stellar toolchain and 1st class IDE and platform support.
I really dislike this argument, and it comes up every time React Native is discussed. I think it's a holdover from Ionic style mobile applications that simply emulated native UI in a webview. It was awful - especially when the native UI changed and the Ionic apps didn't. It's likely you use RN apps every day and don't even notice because they're indistinguishable from native apps.
React Native is designed to compile down to native code and it uses native UI frameworks. The documentation on how it does this is very thorough. The problem is not React Native in my opinion. It's the native UI frameworks for iOS and Android. These frameworks have a lot of issues and taming them often requires developers with a lot of time and experience in that specific domain. Which is stupid and wasteful.
Here's a story from yesterday of how Apple's SwiftUI (their much vaunted successor to UIKit, a very flawed framework itself) is struggling to construct basic settings views in the new version of MacOS: https://daringfireball.net/linked/2022/08/15/ventura-system-...
Not to mention the criticism of Swift as a language and how it has evolved, including the original creator leaving. And how complicated doing a fucking substring is: https://stackoverflow.com/questions/39677330/how-does-string...
In my opinion, Flexbox is a perfect way of laying out elements on a 2D screen. It's way less confusing than the complex constraints system that UIKit used. React Native's implementation of it works well. Kotlin and Swift as DSLs do not need to exist. They are solutions in search of a problem. Designed by big tech to moat their platforms.
Unless you're building an app that has a very non standard UI or a game, it doesn't make sense not to use React Native in my opinion.
One somewhat direct comparison is Discord (RN) vs Telegram (Swift) on iOS. Discord has put a massive engineering effort into their app but switching channels still often feels glitchy and sluggish whereas Telegram’s layouts snap into place instantly. Telegram feels more solid, and it also properly wires up all the little iOS features like haptic feedback, pull to refresh, etc. whereas Discord mutes all of that and feels less lively.
Regarding constraint-based layouts, they can actually be much simpler in many cases because they help you avoid deep layers of nesting. They also ensure consistency (leading and trailing margins, safe areas, etc.) Again, trade-offs that deal in performance and uniformity with the platform.
For CRUD type apps, it probably doesn’t matter. But like I said those probably aren’t the types of apps native developers would be most interested in building.
React native works maybe fine if your target device is the highest end iPhone, but if your users are on Android One devices, it's not going to work nearly as well.
That's aside from the layouting being obviously off compared to the native layout engines.
I can say from comparing pre-RN and post-RN apps side-by-side on a Nokia 6.2 it's definitely much slower (scrolling immediately drops frames, opening/closing the keyboard and other reflows e.g. multiwindow cause the app to hang for seconds).
A journalist who is not an iOS developer saying something 'feels wrong' doesn't mean much in terms of quantitative evaluation of SwiftUI.
Others have already commented elsewhere on the source material (a list of UX nits) was based on a one month old beta release, and many had already been fixed at the time the list was published - something the author of that list neglected to point out at first.
> Not to mention the criticism of Swift as a language and how it has evolved, including the original creator leaving.
People leave. Rob Pike has mostly stopped working on Go. Graydon Hoare left Mozilla - and worked on Swift for a time.
> And how complicated doing a fucking substring is:
I don't understand your reference. String manipulation on Swift has gotten markedly easier since Swift 3 (when that page was created), but it is still meant to be correct/safe unicode grapheme manipulations at its core. Swift's character type is essentially a variable length, special-case of string.
Most Swift string criticisms come down to - if you want to treat text as offsets into a (mutable) binary buffer, work with binary buffers and not unicode strings.
> In my opinion, Flexbox is a perfect way of laying out elements on a 2D screen. It's way less confusing than the complex constraints system that UIKit used. React Native's implementation of it works well. Kotlin and Swift as DSLs do not need to exist. They are solutions in search of a problem. Designed by big tech to moat their platforms.
AppKit and UIKit's original constraint system was simple, even simplistic.
The constraint system that was built on top was sophisticated, but is generally too fiddly. You pretty much need training in the interface builder to understand how to get constraints to apply and stick.
This was quite simply because it was a bolt-on constraint solver over a layout engine with multiple decades of legacy. No layout options went away when constraints were added - instead, the system had to adapt to having (workarounds) for all the different approaches to operate concurrently.
I don't quite understand what technical complaints if any you have of Kotlin DSL or of SwiftUI's layout systems, so I can't speak to that.
> Unless you're building an app that has a very non standard UI or a game, it doesn't make sense not to use React Native in my opinion.
I'm curious what makes something a 'standard UI' when doing native cross-platform development.
Calling John Gruber a "journalist" is reductive. He is the inventor of markdown and has a history as a software engineer himself. He is also one of the most notable people who tracks things that many would consider obscure like Apple UI frameworks.
>I don't understand your reference https://news.ycombinator.com/item?id=32325511
The standard library and API surface of Swift has changed dramatically every release. They don't have a real problem to solve, and they know they have a guaranteed userbase of their language, so it's gotten progressively weirder and shittier over the years.
>I'm curious what makes something a 'standard UI' when doing native cross-platform development.
Not that curious, because it's pretty easy to look up what React Native offers: https://reactnative.dev/docs/components-and-apis. Things like text inputs, buttons but also bigger conceptual stuff like list views and app navigation: https://reactnative.dev/docs/navigation. Those UI elements render differently in different mobile operating systems and React Native handles both gracefully.
He has plenty of people in his network who are professional developers with SwiftUI experience. However, he was talking about his gut feel from a core system service having so many UI nits from Apple, likely associating that with issues he has heard of from developers who have tried to adopt SwiftUI in their existing and/or new projects.
So thats the basis of my opinion - a quote or two from those full-time developers would added greatly to the article, significantly more his personal reaction.
As a developer with some client-side experience, I'd say the nits speak far more to Apple's MacOS development process these days than to the quality of SwiftUI. A decision was made to add it to the 13 beta and commit to shipping it, rather than hold it back for macOS 14.
Yikes, I hope you're not calling Kotlin or Swift antiquated. That's utterly false.
The same Xamarin app i built in 2014, still runs, on .net7. MS nailed crossplatform in a way that an ad company is never going to invest in. They needed to nail cross-platform to keep themselves as a company relevant; they lost the platform war, then redefined it.
Just launched more apps on the platform this year, love it to death. SAme skills i learnt in silverlight, still relevant 10yrs later. Share 90% of code across every platform; and that 10% is built on native wrapped libraries which are generated off every release. MS has the infrastructure and investment like no ad or book store would ever.
https://news.ycombinator.com/item?id=17619609
Looks like they're doubling-down further still:
https://news.ycombinator.com/item?id=32310392
Looks like Shopify also picked up RN:
Recently Discord finally ported their Android app over. Even if you separate the "change is bad" factor, many users report it's quite laggy and a major regression from their previous native version.
I find it funny when people cite high profile companies as success stories without having a benchmark for failure. "The users didn't abandon the product in droves" is a very low bar when you have externalities that would prevent them from leaving even if they wanted to. You could find the Amazon app total garbage, but just how bad does it have to be to pass on free two day shipping?
It's labor-saving and over-engineering combined into one seemingly respectable package. And I'm saying this as a manager and a former web developer.
Flutter seems to have more respect for the craft of mobile engineering, which alienates managers and developers looking for an easy fix for their jobs and their careers.
Sometimes many people in different places have had concerns, or ideas for a better way forward, for some time but have either but spoken up or have had the "everyone else seems to be dealing with it" reaction.
In such cases it takes a certain critical mass of information supporting the change to get movement, that critical mass builds slowly but once it is reached the immediate reaction can appear explosive, and there are sometimes aftershocks back & forth, much like an earthquake caused by plate movement.
So while there is some self fulfilling chain reaction feeding into it, there is usually some true need involved for a lot of the teams concerned.
By the time the new idea has its new problems, the company you followed (or one similar) has probably already posted about solving it, or shared a newer new idea you can try.
But I am more of a writer and decisions are driven by fashion
> Till the year 2012, Airbnb was just a React website.
React wasn't released until 2013.
It's a compliment to the tech of how useful and prevalent it is.
I stopped reading after this.
Websites released in 2012 were typically PHP, server-rendered, written with jQuery. Angular JS was considered cutting edge and go-to option for SPA projects. React was released later and only popularised around 2017-2018, and even at that time I remember most frontend developers were hesitant to use it in production due to the licensing ambiguity at that time (It wasn't MIT).
The parent comment is broadly correct though. AirBnB couldn't have been a React website in 2012 if React's initial release was May 29th, 2013.
I was gonna say, it's also weird because the text of the article seems nearly-native quality.. but actually when I went back and looked more closely it's semi-broken English as well. I guess it's in big wordy paragraphs that you skim and don't notice the grammar of.
Like the examples they give include:
> "What this is made from?"
> "Who you have come to see?"
> "I asked him where does he work."
> "I wonder where is he."
They all sound strange to me but are apparently common in some Englishes.
There were many other giveaways in the article that you'd never see in everyday American English usage:
"Oh yes, it happened!" (who says that)
"giant Online American Vacation Rental Business" (...it's just a vacation rental website)
"the, excessive use, of commas, everywhere"
"Sam enjoys the paper" is fine.
"Sam enjoys the paper?" sounds weird, like you're questioning the sentence itself rather than asking Sam if they enjoyed the paper.
"DOES Sam enjoy the paper?" adds an auxiliary (does) and makes it more natural sounding, I guess, to our ears.
"Sam enjoys the paper?" could have emphasis on "Sam" and sound fine - it is asking if it is Sam or someone else who enjoys the paper.
"Sam enjoys the paper?" could have emphasis on "enjoys" and sounds fine - it is asking if Sam enjoys the paper or feels some other way.
"Sam enjoys the paper?" could have emphasis on "paper" and sounds fine - it is asking if Sam enjoys the paper or something else.
And "Does Sam enjoy the paper?" sounds fine too - it is asking a more specific yes/no question.
Otherwise, it's just easier/clearer to phrase it like "Who was enjoying the paper?" or "How does Sam feel about the paper?" or "What does Sam like to read?"
But those constructions don't necessarily apply to other regional variants of English (especially if English is a second language for them). In that case they may be adapting their English grammar to be closer to the syntax of another language they speak.
Several of us here, including myself, are guessing that the blog author may be Indian (I'm not sure, it's just a guess). If so, there are papers studying this phenomenon or something close to it (I'm not really sure... I'm interested in languages, but I'm not at all a linguist and this is way over my head...). I'll quote (emphasis added) one paper: https://www.researchgate.net/publication/265785678_Embedded_...
> The corpus study reported here challenges a conventional assumption in the World Englishes literature concerning the grammar of L2 English in India: that auxiliary inversion with wh -movement (henceforth wh -inversion) is exactly the opposite of standard U.S. and U.K. English, being impossible in main clauses yet obligatory in embedded clauses (Bhatt, 2000 ; Mesthrie & Bhatt, 2008 ; Trudgill & Hannah, 2008 ). 2 If the prevailing account were valid, this language variety would constitute a rogue grammar in the sense of Thomas ( 1991 ). However, the results suggest that, in this respect, the grammars of L2 users of English in mul-tilingual societies, just like those of monolingual speakers of standard varieties, fall within the compass of Universal Grammar (UG).
In other words... what you're saying makes perfect sense to me and presumably other speakers of some broad "American English" because we're used to those formulations. English elsewhere in the world, possibly including wherever the blog author came from, does not necessarily follow the same rules all the time, especially if English is just one of a matrix of languages they use throughout a week, mixing and matching languages and grammars according to who and what they need to communicate.
As an aside... if stuff like this interests you, the movie Arrival might be interesting? It's that rare pop-sci movie that tries to actually deal with alien linguistics instead of hand-waving it away with a universal translator/babelfish.
https://www.merriam-webster.com/dictionary/dump
"He dumped his clothes on the bed. She dumped the contents of her purse on the table. I dumped the old coffee down the drain."
Correct: He dumped his clothes on the bed.
Incorrect: Why he dumped his clothes on the bed?
Correct: Why did he dump his clothes on the bed?
It's a widely-used living language, and one without a central authority (language regulator, unlike many other languages: https://en.wikipedia.org/wiki/List_of_language_regulators)
So English just kinda grows and grows haphazardly. There are more people in India who speak English (Wikipedia estimates 30% of 1.38 billion, which is 400 million) than there are Americans or UK residents. IMO their particular usage isn't any more or less correct, any more than American English is more or less correct than British English.
It's not a matter of being politically correct or anti-racist or whatever, just the observation that English has always been a hodgepodge of regionalisms and will continue to be for the foreseeable future, and by speakers/population alone, probably the American and British varieties will continue to shrink as other Englishes take over. Probably it's us Westerners that will need to adopt to the new Englishes rather than the other way around.
Grammar prescriptivists and grade school teachers might disagree, but well, they are overwhelmingly in the minority already and will become increasingly more so.
Seeing "Why he dumped his clothes on the bed?" you can guess that they MEANT to say was "Why did he dump his clothes on the bed?"
But there's a bit of uncertainty there, was that really what they meant to say? Or did they mean to say something like "Why did he dump his clothes on the bed IS MY QUESTION" but somehow the rest of the sentence got lost.
Syntactically correct sentences have typically a much more precise semantics than syntactically incorrect ones. One could argue that incorrect syntax means the meaning is anybody's guess.
Point is when we read or hear language we must interpret it by assuming what we think the speaker wants to say. But if syntax is incorrect that becomes much more difficult. Therefor correct syntax is a god-send for getting your point across.
Think about the way browsers interpret HTML. They allow you to deviate from the standard somewhat. But that causes different browsers to produce different visible output. Not a good thing. Maybe the coder thinks they are getting their point across, but depending on the audience, what browser they are using, the "point" can get lost. Best bet is to use standard syntax.
Each English-speaking region comes up with their own rules, perhaps initially descended from a group of British or American emigrants, but evolving over time to form their own variants. It happened from the slave trade, it happened from the age of sail, it happened in Hawaii, in the American South, in the American West, in the Philippines, in India, in South Africa... they all speak subtly different variants, with different rules.
There is no universally correct use of English. There are various rules documented in various dictionaries and grammar/style guides, and reinforced by teachers and higher-class people of various societies, but those are descriptive, after-the-fact illustrations that follow the evolving language, not the other way around.
It's one thing to say that a child's usage of language is incorrect because they haven't learned it yet, within a certain cultural context. It's another thing entirely to presume that your region's usage of English is the only "correct" one. There's no such thing.
Examples (American vs British):
"Data is" vs "data are"
"Do you have a car?" vs "Have you got a car?"
"I already saw that film" vs "I've already seen that film" etc.
color vs colour, trunk vs boot, etc. more examples here: https://www.thoughtco.com/differences-between-american-and-b...
For the blog title in question (which isn't an American vs British difference, to be clear, but possibly an Indian English construction -- not sure), the sentence is perfectly clear, with or without the "did". There isn't some weird ambiguity about it, especially in the context of a tech blog. I agree that it sounds strange to American/British ears, but it's not really "incorrect", it's just a regional stylistic difference -- or so we surmise. Give it 50 years' worth of population growth and migrations, and that construction might very well become the more common one, leaving the American and British versions sounding quaint and foreign.
Now, maybe a related question is whether the writer should've written in the American style, kinda like how many foreign English singers will emulate an American accent. In that case it's not a question of correctness anymore, but of adapting your communications for a cross-cultural context and targeting a specific group of English users and their traditions. I'm not arguing that the author should or should not have done that, just that their choice wasn't "incorrect". Just different from what we're used to.
Problem is if it's not clear (to your audience) which language you are using. I'm not saying that is what happened here. I'm concerned about the general principle "it does not matter really". Yes it doesn't, so much that we should nitpick about it. But it does in giving us guidance as to what we should strive towards. If the audience is international it is best to not use use a specific dialect from a specific region of the world.
It's not "incorrect" or "correct". The question is would it be easier to transfer the information you are trying to transfer by using the most common, most shared dialect of English.
It maybe used to be the case that the internet was primarily American English, but that can't be assumed anymore.
When a British person writes "colour", it looks wrong to me but it's not my place to "correct" them. That would be rude, dumb, arrogant, and ignorant all at once. "Two countries divided by a common language", so they say, except now there are far more than two. Blame colonialism, I guess?
As for the blog audience, maybe they were targeting an international viewership, or even a primarily Indian one (their immigrant tech peers)? In that case, it would be weird to speak American instead of their native English. Like whatever the Indian version of an Uncle Tom would be.
In this case I think this construction is both common enough and clear enough that maybe it's the Americans who should get used to it, rather than demanding that a country five times bigger change their habits to meet our preferences...
> Many of the difficulties we encountered were due to the hybrid model approach we took
They had about 220 screens in RN, 880 native screens total. They found it difficult to juggle that, essentially developing 3 platforms instead of 2.
Personally I prefer to do pure RN, with native extensions. Not a lot of native screens, because yes, you then are developing your targets plus RN.
Also keep in mind they were early adopters and they probably had to do a lot of heavy lifting. RN has matured a lot since then, both thanks to Airbnb and to the rest of the community.
But it probably takes a dedicated developer focused team to manage hybrid. And in terms of pure react native…I don’t know if react native is now able to feel as good as a native app, but even for a few years after Airbnb’s post react native would not have been up to the task of rendering all the little animations and transitions that Airbnb had in their mobile app.
(Though these days I would 100% write a new, less fancy mobile app in react native/expo - it’s constantly improved throughout the years)
Generally a small team is going to do pure RN, with limited extensions and views. A larger team you really have to know how to split everyone up while still being able to bridge views simply.
JS triggered animations and other native features are performant now via JSI, nowadays most people use react-native-reanimated to achieve this.
I think most of the issues Airbnb had were growing pains of RN and have long been resolved.
Airbnb Is Moving Off of React Native (2018) - https://news.ycombinator.com/item?id=23558730 - June 2020 (61 comments)
Airbnb is 'sunsetting' React Native, reinvesting all efforts back into native - https://news.ycombinator.com/item?id=17365451 - June 2018 (20 comments)
React Native at Airbnb - https://news.ycombinator.com/item?id=17348215 - June 2018 (248 comments)
I don't think Airbnb made a bad choice at the time they did it. They tried embracing a technology that was at the time half baked. When you are operating at the scale of Airbnb where there are lots of engineering hurdles and a high quality bar, it's challenging to absorb nascent tech.
Since then a couple things have happened:
- Devices have gotten much faster and this has covered up a nice chunk of the performance tax that existed previously
- The framework has gotten more mature and performant
Having said that, there are still a number of rough patches so it really depends on what you need. Shopify, for example, seems to be quite happy with it. But as usual, it depends on what you're making. If you want something with heavy animations, lots of gestures / high touch responsiveness, really fast startup time, etc. - RN might not be the best choice (but still way better than it was before because of lots of great work). If you're creating something that is more on the CRUD side, RN is more than suitable and a great choice.
This would entail working in a new fork of React Native to add implementations for the underlying Android and iOS SDKs where the native functionality exists. That might include language bindings at multiple levels, e.g. from JS to Java, and potentially Java to C if NDK is required (and that’s just for android)
In my experience, writing those bindings is very bug-prone and user-friendly documentation can be hard to come by.
We wrote some Python extensions in C for a very simple functionality where we wanted native speed. Could definitely see it having been easier to just write the dang program in C, since you had to understand C as well as some fundamentals about how the Python runtime works in C along with its special data types and execution patterns. And if they mainly hire app developers and not interpreter/OS developers that could become entirely untenable
In the early days of the web there was such a thing as "text-based browser". (Don't recall its name right now). You could interface with the WWW via a text-console. The point was user-interface shouldn't be the main thing of the application, it should be just a shell around it.
Not only on the engineering aspects, but on the people as well. You will have a lot of attrition with devs not wanting to switch
I would say that the only 100% safe way to succeed in this endeavour is to fire ALL your native developers and rewrite the app from scratch instead of introducing RN gradually. Obviously that is impossible for any app that is already big
So unless you are willing to do a full rewrite and fire all your native developers and hire some people with RN knowledge (you need at least a few people with RN specific knowledge even if you have web-only devs) you will most likely fail
Also if you DO want to share code between your RN apps and your web app that is ALSO somewhat harder and might need significant rewrites of your web codebase
So in short, DONT DO IT, it is very unlikely you have the in-house experience and political will within your company to pull it off
Honestly the hard part was making ios and android maps feature-compatible. We wanted heatmaps and apple maps and google maps have completely different algorithms to render heatmaps
I never understood why one needs 20 separate apps (100 Mb each) instead of just using a single standard pre-installed web browser. Mobile UI everywhere is fine and functionality is the same.
Appbrain still lists React Native in the list of SDKs for the current version.
https://www.appbrain.com/app/airbnb/com.airbnb.android
Seems if it was all that bad it would be gone by now.
* React Native caused problems for AirBnB because they needed more complete and efficient support for native geolocation/mapping features than RN provides
* More generally, frameworks like RN and Flutter are a good choice if your app doesn't need extensive/precise/efficient access to native platform features and a bad choice if it does
With JSI now you can get efficient access to native platform features. Before you were able to bridge pretty much any native feature with a native view or extension, but you were bottlenecked by the JS bridge. Nowadays you can use JSI for anything intensive.
As far as Airbnb, it was more they were trying to mix 80% native views with 20% RN views and they found they were doing more work than pure native. If you do mostly RN though you don't have that problem.
JSI indeed makes things more efficient, but you still have to maintain code to translate between native and JS.
Unless you're doing something uncommon, there's most likely a 3rd party lib for that functionality.
But yes, if you want to use a native platform feature that the standard lib doesn't expose of course you need native code either by you or someone else, that's the flexibility of React Native.
+1, if you only ever do superficial platform features RN isn't a problem. However if you want to implement the platform features, like Widgets, Siri/Shortcuts support, Apple Watch support, Spotlight search integration now you're going to start having to maintain extensive bridges to communicate between native and JS.
Why?
A proper web app would be sufficient.
Why does anyone care what technology AirBnB uses for their mobile apps or websites?
AirBnB is an incredibly successful company because of their marketing, ability to scale, and the fact they offered the right thing at the right time.
Their website however, is slow and clunky. Their apps are slow and clunky.
What about that side of their company is worth emulating?
People care especially if they feel a very successful business has slow and clunky apps. It's research.
How did they end up in the position they're in? What good/bad decisions do they feel they made?
Obviously it's interesting to people in the space. Where is anyone saying it's because they want to emulate it?
It'd be a bit like customer service people diving into how google does it because they're so successful. They are. But not because of their customer service.