Many comments here are comparing this transition to the one Airbnb did a few years back. These two transitions could not be more different.<p>Coinbase decided to greenfield their new apps, Airbnb (attempted) to brownfield it. I've worked with a number of clients that have gone down the same path that Airbnb did, from a business perspective it makes perfect sense, keep what you have and slowly move over, but the technical reality is this will be a complete dumpster fire and you will probably fail.<p>When you try to convert a native app to React Native everything that makes React Native wonderful to work with just seems to break. Hot reloading either barely works or not at all, load up times increase exponentially, the app just becomes a pain in the ass to work with because nothing seems to work like it should.<p>Whenever companies propose this I always shoot down the idea and recommended a rebuild in React Native from the ground up. Doing so will take just as much time as browfielding because when you try to do a native -> react-native conversion it always seems to go south somewhere, either slowness, having to write 3x the code, or other problems.
If I wanted to do android development again, I have no idea which skillset to optimize for<p>React Native?<p>Kotlin?<p>An old version of Java that just got lambdas?<p>Are we doing Model-View-Presenter (MVP) no matter which? Or are we still doing Massive-View-Controller (MVC backronym)<p>Are there adequate networking, database ORM, and image loading libraries for all frameworks?<p>Last time I interviewed for any mobile development role was 2 years ago and every team (FAANG, Fortune 500, Series B startups) wanted something different and acted like that was the normal skillset to expect
Long story short, terrible idea unless you're in a position like coinbase.<p>The article is from a high level engineering standpoint about productivity and trying to be efficient. The thing the article doesn't mention is the best react native developer also is an expert in native mobile development. It is crazy hard finding these people.<p>All techno fluff aside, any component mobile developer knows once you have a solid foundation it is super easy to build on core features. Given how frequently aplkenabd google breaks things which makes reactive native upgrades a mega PITA, the only proper use at a technical level is to utilize the code at a framework level. React native is still on its knees to cocoapods, which as of now is virtually nonpreferred for future projects.<p>Sorry for the rant, I just think A.:) Coinbase made the wrong decision in the long run because they limited themselves on a technologist that's infamously know to not favor solid user experiences<p>B:) they underestimated the specific qualifications they need to get the people that are grounded enough to know native mobile development and its capabilities, abs the react native component. Even though they are coinbase the article acts like it doesn't matter.
I'm skeptical of most "we switched from X to Y" posts, but the thought process here seems pretty solid.<p>* They had a much harder time hiring mobile developers than web developers, and per-person productivity was also lower<p>* They prototyped an app before committing to a new technology<p>* Similarly, they tested a change to the existing app before switching<p>* They specifically invested time to cross-train people, and tested how long it took web developers to get productive on React Native<p>* They interviewed Airbnb, who had also invested a lot of effort into React Native before dropping it<p>* At each step, they considered whether to rewrite from scratch or incrementally switch that part of the codebase<p>This makes a lot of sense. It shows the kind of careful consideration we should apply when seriously considering switching to a new technology.
The Airbnb / Udacity story is simple. Brown-fielding RN is not the way to go.<p>Here's where green-fielding <i>would</i> have also made sense (and a difference) by using a recent example of a new famous product that is NOT using cross-platform tech like React Native / Flutter, and that's Clubhouse.<p>Last year, they launched their mobile-only native iOS app and everyone was wondering about where the Android app was. It was finally released this month and it took them a year in total. By that time, the hype was already dead, everyone already moved on and didn't care about their app since their competitors copied them to death (And took the Android users with them.)<p>Had they used React Native or Flutter to build their app, they would have been able to release both platforms quicker and at the same time and become feature complete rather than releasing the Android app feature incomplete with iOS and the Android users still waiting for a year and leaving for the competitors instead as the hype already died.<p>Now they are stuck with implementing their features on both platform <i>twice</i>. Discord already cloned them as a feature very quickly (using React Native) and now Clubhouse has to catch up with them to bring their lost users back. Given how fierce competing with social networking / messaging companies are, I do not think using native in 2020 / 2021 for a new product was a good idea in this case and green-fielding a RN or Flutter app would have made sense to iterate quickly.
I've been doing a RN app lately after not using it for almost two years. It's still a very fast way to iterate on both Android & iOS but it also still feels extremely brittle. I've tried and failed to upgrade to the latest version of RN several times now but every time gotten tangled up in dependency hell. I also haven't been able to get it to build on my M1 Mac at all.<p>RN is good for fast prototyping and market value fit testing but I'm not sure I'd use it for something like Coinbase.
Hi all - I support all Retail engineering at Coinbase and was one of the folks who helped shepherd this change through from inception to rollout.<p>I'm happy to answer any questions that folks have - just thread here, and I'll either answer or pull in our team to give more detail.
I want to write small review regarding replies on this link. I am working as an mobile engineer for more than 8 years now. I have worked on native iOS, Android, Xamarin, Unity, Titanium, Flutter and React Native. Long story short I have never been happier since I switched to React Native and Expo made everything so much better. I am not comparing it to native but I can compare it to Flutter.<p>First of all Flutter has major performance problems on iOS.
Using native views (MapBox, ArcGIS) inside Flutter app has subpar performance.
Flutter has weird styling compared to anything I have ever worked with.
Styling in Flutter is very unintuitive (ex: Global theme for button width).
You can’t OTA update Flutter code.
Weird scroll behaviour.
I can go on and on but personally I would never use Flutter ever<p>Most comments under the link:<p>React Native bad because Flutter good.<p>React Native bad because native good.<p>React Native bad because Y is good.
I'm never touching mobile development and especially React Native again!<p>I'm a web developer and a few years ago, I had the opportunity to develop a mobile app. What a nightmare...<p>Among the new versions of React Native or Gradle breaking everything, all the npm packages suddenly not maintained anymore, the virtual phones not always starting or refreshing, the custom code you add to do in Java and Objective C because RN cannot do everything, and certainly the worst, the deployment on the app store.
There are some long term trends that should work in React Native’s favor.<p>The pace of mobile changes is slowing and will probably slow further. This is the usual case of an initial innovation transitioning to incremental improvements. This means that React will eventually catch up or come close to catching up with mobile developments (if they have enough technical expertise to do so).<p>Competition has consolidated the market into two platforms. This means that only two platforms need to be supported.<p>Due to competition between iOS and Android, the two platforms are undergoing convergent evolution. This will also make it easier to support the two platforms since new features will be similar.
With regards to UI elements and layouts nothing beats React and Flexbox CSS on mobile. Also, when it works correctly Expo is a pure bliss.<p>C'mon iOS devs you can't tell
you enjoy the byzantine layout model of the native iOS apps and working in xCode.<p>Some parts of React Native are problematic but creating screens is simple and intuitive.
2025: Coinbase successful transition from React Native to Native apps.<p>Seriously haven't we seen how this play-out way too many times already?<p>There is absolutely no incentive for Apple and Google to make sure ReactNative controlled by Facebook is the way to develop apps for their platforms. Till that is true, its absolutely nuts for any company other than facebook to develop their apps in ReactNative.<p>Edit:
Example: <a href="https://softwareengineeringdaily.com/2018/09/24/show-summary-react-native-at-airbnb/" rel="nofollow">https://softwareengineeringdaily.com/2018/09/24/show-summary...</a>
I wonder if they considered Flutter. I joined a startup that’s using React Native and I have to say, I dislike all the complexity around state management, styling in separate CSS files, JSX syntax for components, etc.<p>I much prefer the unified approach of Flutter (everything is in Dart and not scattered in 3 different places) and batteries included component library.<p>Not to mention, if you have a small team, Google Cloud Firestone plus Flutter is a very productive and elegant way to launch an app with a small team ... or even solo.
Would be great if Coinbase also contributes back to the React Native ecosystem, like how Shopify pledged to do. That would be a net positive for everyone involved.
Let's wait for a few years and they will make the Airbnb and Udacity style U-turn. Even Facebook doesn't use react native as a primary technology for building Messenger, Instagram or Facebook app.<p>Shameless plug: my opinionated beliefs <a href="https://ashishb.net/all/react-native/" rel="nofollow">https://ashishb.net/all/react-native/</a>
Sort of off topic.<p>In your opinion, What is the best React Native App, that is also extremely popular which could be used to show case the tech?<p>I think if you look at the best and you are already unimpressed that we could wait another few years for others to figure out first rather than jumping on to the hype. Sort of like Facebook demonstrating HTML5 during the start of the iPhone App Store era.
Does anyone know if Flutter was in the consideration set? It's gaining some momentum as a slightly more stable crossplatform ecosystem to React Native. but of course, there is the prospect of Google and Dart.
Anyone got experience with both RN and Flutter willing to chime in on how they compare?<p>So far I've been fairly satisfied with Flutter, however there are some glaring performance issues (though it sounds like these will be addressed in due course).
The Coinbase iOS app looks nice and the attention to detail looks to be at a good level. It's a nice surprise that it's written in React Native. Well done to their team!
I’ve done iOS native development only and was exploring transitioning to RN due to single code base/multi-platform support. However, one of my constraints for target customer market is the final app size. Right now, I have a native iOS app talking to our API and using AVKit/MapKit with a final complied size of 3MB. Can a RN project yield similar size app?
Great writeup! I don't use Coinbase or any cryptocurrencies, but I'm tempted to sign up just to see this React Native application in action. Are there any other great React Native applications you have used on Android? From what I've seen it's mostly Facebook, Instagram, shopping apps, etc... which I don't use.
You have three options.<p>Optimise for user experience (go native)<p>Optimise for cost (whatever the cheapest developers, or a cross platform solution, like phonegap/pwa/react native)<p>Optimise for developer experience (use whatever your developers know, maybe native, maybe react native)<p>In my personal opinion, always optimise for user experience.
Shared code should be in the backend, not in your mobile app. Your mobile app (ignoring camera filters & games, as they should use an engine; unity etc) should just be a JSON viewer, with a small bit of data entry.
80-90% of your efforts should be on UI and user experience, but obviously architecture requirements scales up with the team size.
Anything else is over-engineering, generally.<p>The amount of leads I get in for mobile apps, that eventually transpire to the client not knowing the app was built in react native, because they heard “native” and assumed Swift/Kotlin, is increasing by the day.
They can’t find enough good developers that know react native, and they don’t have the funds to rewrite.
They’re stuck.
Obviously I, as a native developer, only hear the horror stories from these experiences and not the times it works out.<p>But in the last 2-3 years, it has killed 2 startups that I know of, and cost 3 a lot of money to rewrite (two of them made that decision before they contacted me, one after they spoke to me, and they were shocked to find out that they didn’t have a Swift app).
I am now having to rescue more clients from react native, than from clients that outsourced to the cheapest agency on Fiverr. Wild!<p>Side note: why has every app got to expand until it adds messaging? Let a calculator be a calculator, it doesn’t need venture capital and network effects to sell.
I'm currently building a cross platform app with vue, framework7 & capacitor and it feels like a superpower.<p>I learnt vue in a weekend and the framework7 generator generated a boilerplate app for me. I used react years ago but this stack seems far easier and faster to develop in.
Not too surprising. Mobile native engineers are quite expensive and coinbase has been cutting costs recently <a href="https://news.ycombinator.com/item?id=27119787" rel="nofollow">https://news.ycombinator.com/item?id=27119787</a>
isn't using RN over native ultimately just optimizing for their developers and not the product? RN is great for start-ups that need to build and launch quickly for multi-platform, but for an established giant like Coinbase it seems like a misstep.
Two years from now, it will be 'why did we decide to move on from React as it was not working out' blog post<p>It is like the circle of life with native vs semi-native (which react is), and just html apps.<p>Teams build a fast new version, looks great as it is new code, without much baggage, and over time it gets bloated and people complain that it takes too much to debug/develop on it.<p>Some people in a internal team write a new demo/prototype in a new tech, some director/vp buys in, and the circle of life continuous, in the new tech, and a new blog post is made again.<p>At Spotify, we had few interactions of these, back and forth... like clockwork.<p>Ps. If you are junior engineer reading this, don't pay too much attention of these type of blog posts, as they usually are just PR for internal teams, so someone gets a promotion.
Just work on the tech stack that you like working on, and exites you the most.
Especially for personal projects. Don't do something because everyone else is doing, but do it because you do enjoy it.
Having just finished an 8 month Expo RN contract I'm excited to never touch it again. For personal projects keen to see how far I can go with Svelte PWA + Capacitor.<p>Google + Microsoft should really double-down on PWA apps. I think at one point Microsoft was crawling the web and automatically listing any PWA in their app store. If that became the norm then maybe Apple will make their PWA install UX less deliberately clunky.
> <i>Thinking from this perspective led us to...</i><p>> <i>the average mobile engineer’s velocity remained stagnant</i><p>> <i>this could dramatically reduce our overall staffing requirements...also have to deliver improved quality and performance for our customers</i><p>Honestly it sounds like Coinbase is quickly turning into a shitty place to work. Sounds like all the ingredients for a race to bottom in culture. It's so easy to tell that this was cooked up by primarily non-technical management types whose only actual "first-principle" is penny pinching.<p><i>Obviously</i> you can get work done faster across multiple platforms on a per-engineer basis if you use a single technology. The cost of that speed is quality to the end user, and being in a perpetual state of "1 step behind" the capabilities of native app development. There will be regular instances of shoehorning in functionality as each underlying platform makes updates to their respective operating system. The unforeseen issues are that their engineering department will eventually turn into a technology echo-chamber...and this close-mindedness in regards to technology will likely lead to losing out on top engineering talent.<p>Also, expecting ever-increasing velocity for each employee is insane. (not to the penny pinching execs tho) There's a finite amount of time and mental energy a human has each week. It's one thing to say you want to build software that can accommodate massive business growth...but it's another thing entirely to represent that by measuring rate of acceleration of velocity per engineer. That in and of itself isn't scalable.
What an attrocity.<p>You could've just said that you no longer want to invest in mobile talent.<p>Just opened Coinbase Android app:
* Overall slow
* Jank in transitions
* When dialog pops up and you close it, there's a dangling shadow in the air
* You open privacy policy and application is killed in background and you see splash screen again with no state restoration, what the f?<p>Hot garbage, the time you spent on this could be spent on rewriting to proper native standards.
HTML is the best cross-platform document and application specification ever conceived.<p>It's a product of a very special place and time where companies were not able to succeed in growing their own locked-down fiefdoms. Microsoft got hammered by the DOJ, AOL gave way to better competition. It was a good time.<p>About the time the DOJ stopped caring and members of Congress became invested in tech, a new device category arrived on the scene. It took over general purpose computing, becoming perhaps the only computer and gateway to the Internet for many.<p>Two companies form a duopoly, and they look nothing like the web of the 90's and 00's. App developers have to write and maintain two separate code bases, go through app approval, and have to hold hands to get their software released. It's an asinine retreat from the freedom we once had.<p>The web, too, has come under attack. The most popular browser is controlled by an ad giant that created an advantageous monoculture, removed ad blocking, and embrace-extended into things like AMP.<p>We've taken the wrong path.<p>The W3C should have written a native app spec, described native widget tool kits, and kept the duopoly at bay.<p>We were all distracted as to what was really going on.<p>Think about all of the wasted human productivity writing and maintaining two versions of the same software. Instead of working on actual problems, we have to doubly employ to satisfy the powers that be. It's so incredibly dumb that so many work so hard just so that two parties can soak up all the benefit. It's a fluke of evolution that wouldn't have happened if the regulators hadn't fallen asleep at the wheel (or bought into FAANG stock).