18 ms·

Transition to React Native

192 points by northstar702 5y ago

sigmaprimus 5y ago
Just in time to handle the "Huge Increase" in withdrawls I suppose.
dheera 5y ago
Is there a ReactCoin? #moon
- kvirani 5y ago
  HN !== Reddit
jabo 5y ago
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.
- jessepollak 5y ago
  We are doing this already and plan to increase the investment over time. Stay tuned!
echelon 5y ago
HTML is the best cross-platform document and application specification ever conceived. 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. 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. 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. 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. We've taken the wrong path. The W3C should have written a native app spec, described native widget tool kits, and kept the duopoly at bay. We were all distracted as to what was really going on. 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).
- petmon 5y ago
  I disagree. An application platform establishes UI conventions. It's not "wasted productivity" to build software so that it participates in the conventions that users expect. That empowers users: they can do more with your app, by bringing their knowledge from other apps. The web erodes UI conventions. Find, bookmarks, back button, copy and paste, undo, select all, etc. are worse on the web, compared to 5 or 10 years ago. And those are just basic functionality, table stakes for any app. Web apps are making us all less computer literate: they do less, and so we expect less from our software. That's the wrong direction!
vmception 5y ago
If I wanted to do android development again, I have no idea which skillset to optimize for React Native? Kotlin? An old version of Java that just got lambdas? Are we doing Model-View-Presenter (MVP) no matter which? Or are we still doing Massive-View-Controller (MVC backronym) Are there adequate networking, database ORM, and image loading libraries for all frameworks? 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
- WrtCdEvrydy 5y ago
  React Native or Flutter depending on your desired target.
- hardwaresofton 5y ago
  None of those! The real answer is Nativescript -- https://nativescript.org https://nativescript.org It doesn't get the buzz, and the ecosystem is somewhat old (it's surprisingly common to run into a repo that hasn't been touched in a year) but it's the superior platform to React Native and you get none of the capriciousness of the React ecosystem (if anything the Nativescript community might need a jolt). Nativescript is incredibly productive and you can bring along frameworks that do their best to move the work to compile time (like Svelte). I think the best options form a spectrum like this: (PWA)-------(NativeScript/React Native)------(Flutter)------(Kotlin/Alternative iOS environments)--------(Objective-C/Swifth/Java "fully native") If you choose essentially anything on the right side of flutter, performance will be relatively good out of the gate, and anything to the left (including flutter) and you have to be a little careful. I think Flutter is actually the worst of both worlds because I'm heavily biased against Dart after using it, but it is obviously backed by a behemoth, and the render-every-pixel model makes it insanely portable. If you want to write-once-run-everywhere (generally a bad idea, but if it works for you who cares), then flutter is the best by a longshot.
  - vmception 5y ago
    NativeScript is obviously the wrong answer I want to pass interviews and do android development for employers Thanks for the spectrum, which one would I lead with and expect to answer the most questions in and complete project time trials on
rapsey 5y ago
How does the app perform now?
- htormey 5y ago
  Theirs an image in the article that compares business and performance metrics before and after: https://miro.medium.com/max/7200/0*L6GxhXWiTckqwMYL https://miro.medium.com/max/7200/0*L6GxhXWiTckqwMYL Ratings and some perf metrics(start time) improved, no regressions.
  - rapsey 5y ago
    Ok but was it good before the rewrite? :)
- mcny 5y ago
  I don't know anything about react native and from my (limited) experience with titanium, I'm not a fan of js based "native" apps. That being said, I didn't know the iOS app was react native. I don't use coinbase much but it feels pretty good. I'm wondering in hindsight if titanium wasn't so bad and I just didn't have a firm enough grasp on js and CSS.
  - slow_donkey 5y ago
    IMO before react native came on the scene there were no well performing hybrid app frameworks except possibly xamarin. So it likely wasn't your fault
- EvilEy3 5y ago
  Android performance is garbage. Source: just downloaded app.
  - intev 5y ago
    I call BS. I just downloaded it and it works fine. Literally every single one of your comments has it out for this transition. I trust my own experience and their data.
kumarm 5y ago
2025: Coinbase successful transition from React Native to Native apps. Seriously haven't we seen how this play-out way too many times already? 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. Edit: Example: https://softwareengineeringdaily.com/2018/09/24/show-summary-react-native-at-airbnb/ https://softwareengineeringdaily.com/2018/09/24/show-summary...
- codingslave 5y ago
  React native is just better, and it has been for years.
  - EvilEy3 5y ago
    Better than what?
- ec109685 5y ago
  They addressed Airbnb's experience in the blog post. In addition to abandoning React Native, Airbnb created their own templating language best suited for their app and rolled it out to both platforms so they didn't have to handspin every screen.
  - EvilEy3 5y ago
    No, they didn't address anything. They only said that it didn't work for Airbnb because it wasn't greenfield. The real reason it doesn't work out, is because React Native is a dumpster fire. If you really want to go cross platform way, then go with Flutter or wait for JetBrains Compose to target iOS.
    - intev 5y ago
      Oh yes. You know best. Their CTO did no due diligence before making such an important transition. They didn't even bother talking to AirBNB about their experience. Nothing has changed since AirBnB made their transition. You my friend, know all the ins and out more than the silly, tech illiterate Coinbase team.
nmfisher 5y ago
Anyone got experience with both RN and Flutter willing to chime in on how they compare? 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).
- gfarah 5y ago
  My team's anecdotal experience: In February of last year we moved from RN to Flutter. We are super happy with the switch. Our app in Flutter is used by around 1.3M users in 3 different countries. Our Flutter app is more stable (less crashlytics bugs), faster (performance wise) and keeps our mobile team happy (better developer experience). We also use Flutter Web for one app used by around 25k users, even though it is cool reusing some things from the mobiles apps, it still needs to improve in performance and stability.
  - mikevm 5y ago
    What about the currently janky iOS animations with no fix in sight? https://github.com/flutter/flutter/issues/60267 https://github.com/flutter/flutter/issues/60267 I'd warn anyone targeting multiplatform mobile from using Flutter until this is resolved.
    - nmfisher 5y ago
      Yeah, this is admittedly a serious issue. If anyone hasn’t seen it, install Google Pay on iOS and go through the signup/intro screens. The lag is awful (and I say this as someone whose app in built on Flutter). I know it’s only a “first-time” thing, but it’s a horrible first impression.
- eagsalazar2 5y ago
  We do a lot of RN but recently had a large project that required Flutter. We were all curious because you hear good things about Flutter but, in the end, no one thought the dev experience of Flutter was better than Typescript+RN. One data point.
ardit33 5y ago
Two years from now, it will be 'why did we decide to move on from React as it was not working out' blog post It is like the circle of life with native vs semi-native (which react is), and just html apps. 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. 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. At Spotify, we had few interactions of these, back and forth... like clockwork. 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.
- ec109685 5y ago
  How utterly dismissive. They rebuilt their apps, increased the number of developers able to contribute to their codebase and improved metrics. That should be praised. Their point about brownfield development was a good one. In my experience the intersection between RN and Native (both code and people) is the biggest impediment.
  - ardit33 5y ago
    AirBnb went exactly through this transition and back... Coinbase is just behind by a couple of years. Perhaps Coinbase' engineers, are better, or a different breed from Airbnb' ones, or perhaps React Native has matured more since 2019. Can't give you an answer. Linkedin had the exact iteration years ago. They had one of the first NodeJS Apps, driven mobile apps, and made some glossy block posts, praising it. Then quietly went back to native. Facebook went back and forth with HTML 5 sound the same time, etc.. etc.. It is like seeing the same movie over and over, with just some minor plot twists, they tend to play out the same. Since the Java's Applets promise 'write once, run everywhere', this story instead has been always the 'write once, debug everywhere'. "Sunsetting React Native Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing." https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a https://medium.com/airbnb-engineering/sunsetting-react-nativ...
cageface 5y ago
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. RN is good for fast prototyping and market value fit testing but I'm not sure I'd use it for something like Coinbase.
- dstaley 5y ago
  If at all possible, I can't recommend Expo enough. I hated building RN apps prior to it, and now I hate building apps without it.
  - FlashBlaze 5y ago
    Isn't the apk size much larger if you use Expo? Or is that not the case anymore?
    - dstaley 5y ago
      With the EAS Build system, it's no longer a concern. Available to paying customers at the moment.
  - macando 5y ago
    When Expo works like it should it's like the best dev experience ever. Supporting all React Native 3rd party components without ejecting and ditching the Expo app will be a huge step forward.
    - _fat_santa 5y ago
      Expo is great for prototyping and small apps with limited scope. However anything bigger and expo just doesn’t work. At some point you will need to mess with the native side of thing, most of the time to initialize things like Firebase or adding a lib with a bridge. When you have to make native changes, no matter how small, Expo will get majorly in the way
Softcadbury 5y ago
I'm never touching mobile development and especially React Native again! I'm a web developer and a few years ago, I had the opportunity to develop a mobile app. What a nightmare... 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.
- k__ 5y ago
  I would do it again. Mobile is generally shit, but RN made it bareable. But, yes, much bigger overhead with all the native stuff. I'd recommend everyone to use web tech whenever possible.
  - amelius 5y ago
    Also, why support the duopoly if you can develop for the open web instead?
    - chrisco255 5y ago
      Because mobile Safari still sucks and they take forever to support new web standards.
SatvikBeri 5y ago
I'm skeptical of most "we switched from X to Y" posts, but the thought process here seems pretty solid. * They had a much harder time hiring mobile developers than web developers, and per-person productivity was also lower * They prototyped an app before committing to a new technology * Similarly, they tested a change to the existing app before switching * They specifically invested time to cross-train people, and tested how long it took web developers to get productive on React Native * They interviewed Airbnb, who had also invested a lot of effort into React Native before dropping it * At each step, they considered whether to rewrite from scratch or incrementally switch that part of the codebase This makes a lot of sense. It shows the kind of careful consideration we should apply when seriously considering switching to a new technology.
- deepsun 5y ago
  >They had a much harder time hiring mobile developers than web developers... It's not hard at all to find mobile devs, just offer more money. Mobile devs cost more, that's right. But I think that's because mobile development is significantly harder (personal first-hand experience).
- EvilEy3 5y ago
  > They had a much harder time hiring mobile developers than web developers, and per-person productivity was also lower That's what happens when you pay peanuts.
  - intev 5y ago
    Oh? You know everyone's salaries?
    - EvilEy3 5y ago
      I don't see shortage complaints from FAANG companies.
      - intev 5y ago
        Are FAANG companies the median for tech salaries? If that's the case most companies are doomed. It's pretty common knowledge that FAANG pays really well. One of the big reasons people work there are for the extremely generous salaries. Everyone else is underpaying if you're comparing them to FAANG. Also by your definition, Apple and Amazon are notoriously cheap too. Really you're only comparing to Google, Facebook and Microsoft (less so).
deleted 5y ago
[deleted]
macando 5y ago
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. C'mon iOS devs you can't tell you enjoy the byzantine layout model of the native iOS apps and working in xCode. Some parts of React Native are problematic but creating screens is simple and intuitive.
- jamil7 5y ago
  SwiftUI is higher level again for layout and I would pick it over flexbox CSS on mobile any day.
  - macando 5y ago
    SwiftUI is a strong competitor I admit.
treelovinhippie 5y ago
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. 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.
- FlashBlaze 5y ago
  Are there any disadvantages of using PWA + Capacitor instead of RN? Did you use Ionic for it?
  - treelovinhippie 5y ago
    PWA + Capacitor would basically be a web wrapper with access to native APIs: https://capacitorjs.com/docs/v3/plugins https://capacitorjs.com/docs/v3/plugins I'm chasing the holy grail of "build once, run anywhere". I want to basically use Svelte and Tailwind and spit out web, iOS and Android apps. But I also want to use normal HTML components. RN, Flutter and NativeScript all have their own unique components which is another thing you need to learn. Will see how far the PWA approach can go when I find the time.
- macando 5y ago
  What were the issues with Expo and why haven't you ejected to vanilla RN?
  - treelovinhippie 5y ago
    They ejected toward the end but that just makes development more difficult, particularly the deployment process. Expo is nice but the whole DX is just painful. The iOS Simulator will crash often. You need to do a hard 'expo start' relaunch often. What looks great in iOS will often be broken on Android. Trying to get pixel perfect UI and the desired UX is painful. Expo is full of bugs and limitations. RN is old and unmaintained.
_fat_santa 5y ago
Many comments here are comparing this transition to the one Airbnb did a few years back. These two transitions could not be more different. 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. 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. 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.
- raspasov 5y ago
  Right on point. I have done a lot of React Native but never tried to mix native + React Native (with the exception of the occasional native feature in a mostly RN project). Mixing an old native project with RN, doing a so called "slow transition" sounds like a really bad idea. Data communication between the native part and React Native will become an issue, you're effectively going to be running a mini distributed system within your device. There's probably 100 other problems that I can't even start to imagine. Perhaps a super experienced, world class expert in both JS and mobile development + runtimes can pull it off but I wouldn't be comfortable trying to do it (been doing mobile development directly since 2016 and have been close to mobile dev since ~2011). Re-write is a better option.
- ryndshn 5y ago
  if i remember correctly, Airbnb had many issues with RN that were not related to their incremental migration, such as the issues they had with things like debugging, where it was almost impossible to fix certain bugs due to RN using different JS engines depending on platform and context (for ex running with a debugger causes RN to use V8 whereas running locally on iOS / Android it uses JavaScriptCore or Hermes, respectively). RN is awesome but imo has some pretty serious pain points.
ashishb 5y ago
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. Shameless plug: my opinionated beliefs https://ashishb.net/all/react-native/ https://ashishb.net/all/react-native/
raspasov 5y ago
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!
hitekker 5y ago
Not too surprising. Mobile native engineers are quite expensive and coinbase has been cutting costs recently https://news.ycombinator.com/item?id=27119787 https://news.ycombinator.com/item?id=27119787
babesh 5y ago
There are some long term trends that should work in React Native’s favor. 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). Competition has consolidated the market into two platforms. This means that only two platforms need to be supported. 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.
- pixel_tracing 5y ago
  You couldn’t be further from the truth. Mobile is undergoing a substantial evolution in development experience. SwiftUI and Compose are changing the development world for Mobile. The compiler itself is being optimized to show UI with hot reloading.
  - babesh 5y ago
    I think SwiftUI is just as much about platform lock-in by bundling Mac, AppleTV, iPad, and iPhone together as an app fortress. Furthermore it enforces more standard UI/UX which commoditizes apps. Stepping back, I think we are just seeing a battle of commoditizing your complements. For Coinbase and Facebook, Apple is the complement. For Apple, Coinbase and Facebook are the complement.
    - pixel_tracing 5y ago
      You are vendor locked in regardless whether you build it in RN or SwiftUI or compose - you are still building a mobile app and any serious mobile app will need some degree of native integration. Better to make it natively than to support an extra platform which is RN.
jfisk87 5y ago
Long story short, terrible idea unless you're in a position like coinbase. 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. 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. 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 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.
- _fat_santa 5y ago
  I highly disagree that an expert RN dev also needs to be an expert mobile dev. Articles like these make it seem that react native development requires native knowledge but that simply isn’t the case. With almost all greenfield RN apps, 99.9% of the code is RN and only very specific feature are helped out by native code.
  - Jare 5y ago
    You don't need to be an expert in native to write a RN app. However, you need to be very capable in native to have a responsive, performant, smooth RN app, and to keep it that way for years. Large teams can afford to have a subset of platform devs and a large body of RN app devs to make this plan work (note: you now have 3 platforms: iOS, Android, and RN itself). Smaller teams will struggle. Most often, small teams will end up putting their weight on the RN side (develop new features!), and slowly slide downhill in performance, responsiveness and overall UX like the proverbial boiling frog.
jb775 5y ago
> Thinking from this perspective led us to... > the average mobile engineer’s velocity remained stagnant > this could dramatically reduce our overall staffing requirements...also have to deliver improved quality and performance for our customers 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. Obviously 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. 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.
- reducesuffering 5y ago
  And look at what Shopify CEO just said: "But we all have to re-qualify for our jobs every year. The red-queen race of Shopify's historic 40% or better growth is that everyone has to show up at least 40% better every year to qualify for our current jobs. I expect you to hold yourself and your teams to this standard."[0] [0]https://archive.is/Hql0j#selection-2991.215-2991.490 https://archive.is/Hql0j#selection-2991.215-2991.490
- JMTQp8lwXL 5y ago
  > being in a perpetual state of "1 step behind" the capabilities of native app development. For a basic CRUD app with simple data visualizations, this doesn't seem to be a huge issue compared to apps that might need to take advantage of whatever new capabilities arrive on mobile phones, though those have largely plateaued in recent years.
ryndshn 5y ago
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.
cedel2k1 5y ago
There are no winners when fighting over technologies.
EvilEy3 5y ago
What an attrocity. You could've just said that you no longer want to invest in mobile talent. 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? Hot garbage, the time you spent on this could be spent on rewriting to proper native standards.
- intev 5y ago
  What has gotten you so upset about this transition? I don't understand. All your comments are so vicious with no backing. >You could've just said that you no longer want to invest in mobile talent. How does this even track? They had to retrain their engineers. I call complete BS with your app experience. I have a Redmi and the app works flawlessly. They seem to have internal data to prove it. They were under no obligation to make the blog post if they didn't think it was successful. If anything they are going against the grain here so they know there are lots of people watching.
  - EvilEy3 5y ago
    > All your comments are so vicious with no backing. I literally listed my experience with the app. And I didn't even create account yet. > How does this even track? They had to retrain their engineers. To leverage Web developers, right. > I call complete BS with your app experience. I have a Redmi and the app works flawlessly. Which Redmi? I'm testing on Xiaomi Mi A1. It probably works better on my Samsung S10. But then majority of people have phones closer to my Xiaomi. > They seem to have internal data to prove it. They were under no obligation to make the blog post if they didn't think it was successful. If anything they are going against the grain here so they know there are lots of people watching. Because the blogpost makes it seem like there are only upsides to technology and the only downside is that it's not fit for brownfield. I had very bad experience with RN and give my opinion on tech. What's the problem?
    - intev 5y ago
EvilEy3 5y ago
Just when there are two arguably most important migrations in mobile world happening(Compose and SwiftUI), they decided to migrate to inferior tech.
- intev 5y ago
  *According to you. Every 5 or so years there's an "important" transition happening. That's tech. There's been many stories written about companies that live on the bleeding edge. I don't remember any of them ending particularly well.
  - EvilEy3 5y ago
    > Every 5 or so years there's an "important" transition happening. Name at least one change in Android SDK that can come close to revolution that is Compose. And same for iOS/Mac and SwiftUI. Compose and SwiftUI are doing to mobile what React did to web. It arguably single most important change that happened since the inception of mobile platforms. > There's been many stories written about companies that live on the bleeding edge. I don't remember any of them ending particularly well. What?
    - intev 5y ago
      I agree the current one is a major change but it's not mature yet. It hasn't stood the test of time. Twitter was built on RoR when that was the coolest new thing to build things on and Uber's booking engine was on Node.js when everything was being run on Node. I'm sure there's more I'm missing. .
      - EvilEy3 5y ago
        You seem to be missing my point. Compose and SwiftUI are React of mobile world. React certainly stood the test of time.
        intev 5y ago
        That's to be seen. I very clearly remember when Angular first came out, that was clearly the way to move forward. People switched in droves. Then React came along and changed everything. React has also remained more popular than Angular has, but we didn't know that till years later. Some chose to remain in Angular (my old company) thinking it will blow over and we can swap to the next paradigm instead. Turned out React was flexible enough to last a while. Somehow you can perfectly see this is the React of mobile and not Angular?
4eleven7 5y ago
You have three options. Optimise for user experience (go native) Optimise for cost (whatever the cheapest developers, or a cross platform solution, like phonegap/pwa/react native) Optimise for developer experience (use whatever your developers know, maybe native, maybe react native) 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. 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. 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! 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.
- sofixa 5y ago
  > n my personal opinion, always optimise for user experience If you have unlimited money, that is. If you don't, a suboptimal UX is better than no UX. > 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. Anything else is over-engineering, generally. Ideally, yes, but depending on the app the frontend can still be heavy - e.g. with Coinbase, all the graphing and real-time stuff, done 3 times over, are probably a not insignificant effort.
- throw14082020 5y ago
  There's a lot that goes on in a mobile app, please read https://developer.android.com/docs/ https://developer.android.com/docs/ and https://developer.apple.com/documentation https://developer.apple.com/documentation It certainly is different to backend development, but not everything is a "JSON viewer", even if you exclude camera filters and games. Only the truly awful apps are "JSON viewers". There is a lot of complexity, and I've heard arguments from people that 'they don't want to be a front-end dev because that is just visual stuff': they're talking about pre-javascript days or talking about something they've never done to a good level. Using a backend (adding network cost)/ sharing code should be the last on your mind for mobile apps. I've had once, where the logic for feature would take less than a day to implement (which I subsequently did), but inexperienced non-mobile developers decided it would be a good idea (and said exactly what you said) to put everything in the backend to share code between iOS and Android. The interface cost (network code) cost more time in development, and made a much worse user experience. Not to mention, I had to use the code written by the inexperienced person, which had bugs. You might not understand mobile, but there's a lot more that goes on in a mobile app.
aorth 5y ago
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.
pupdogg 5y ago
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?
TheMagicHorsey 5y ago
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. I much prefer the unified approach of Flutter (everything is in Dart and not scattered in 3 different places) and batteries included component library. 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.
swyx 5y ago
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.
- halfmatthalfcat 5y ago
  To be honest, it's only gaining momentum because of the PR behind it. I've yet to see or hear of a major hybrid app getting shipped in Flutter.
  - k__ 5y ago
    I know a few freelancers that specialized in Flutter the last year. But I wasn't convinced either.
  - surajrmal 5y ago
    https://flutter.dev/showcase https://flutter.dev/showcase seems to show a lot of major applications using flutter.
- jessepollak 5y ago
  We did consider Flutter, but (1) we already had a very strong javascript talent base that we wanted to leverage; (2) at the time when we made the decision, Flutter was still relatively early in its lifecycle. That said, we've spent a lot of time talking with teams using Flutter and we think it's awesome!
  - halfmatthalfcat 5y ago
    Could you say which teams you were talking to? Curious about companies adopting Flutter and why over other solutions.
    - jessepollak 5y ago
      Mostly teams within Google that have had success with it.
alexandr1us 5y ago
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. 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 Most comments under the link: React Native bad because Flutter good. React Native bad because native good. React Native bad because Y is good.
- powerapple 5y ago
  Thank you for the info. I am starting a project and was thinking choosing Flutter or React Native. I have used both Flutter and RN for some small toy projects. I really liked Flutter with fastlane. Does fastlane still work? Do people actually use Unity for apps? I am actually building an app for kids, Unity can be really interesting for me.
  - alexandr1us 5y ago
    I used to use Unity for apps since it made perfect sense for simple game like apps
- jpeter 5y ago
  What was the worst framework? Xamarin?
  - alexandr1us 5y ago
    Titanium was worse
jessepollak 5y ago
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. 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.
- halfmatthalfcat 5y ago
  What does your CI/CD look like? It took me a long time to fully flesh out a RN pipeline that was (mostly) completely automated. Are you leveraging Fastlane? Are you buliding both Android and iOS on OSX VMs? How do you deal with shipping canary versions and is that process also automated? Thanks!
  - jessepollak 5y ago
    We talked a good amount about this [here](https://twitter.com/dan_coff/status/1393599897119592456 https://twitter.com/dan_coff/status/1393599897119592456). We are using Fastlane. We are building iOS on OSX, but Android on more standard EC2 hardware. We ship canaries with every commit to master, fully automated.
- zitterbewegung 5y ago
  Not really a question but more of a statement that Discover also transitioned from Native to React Native successfully and I believe they also didn't do a brownfield implementation. There was a presentation about this at React Chicago but I can't seem to find it.
- pixel_tracing 5y ago
  So what is your native mobile engineering team doing now?
  - mekkkkkk 5y ago
    Which native mobile engineering team?
ksec 5y ago
Sort of off topic. In your opinion, What is the best React Native App, that is also extremely popular which could be used to show case the tech? 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.
deleted 5y ago
[deleted]
rvz 5y ago
The Airbnb / Udacity story is simple. Brown-fielding RN is not the way to go. Here's where green-fielding would 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. 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.) 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. Now they are stuck with implementing their features on both platform twice. 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.
SilurianWenlock 5y ago
Why does all this stuff have to change so much?
nprateem 5y ago
I'm currently building a cross platform app with vue, framework7 & capacitor and it feels like a superpower. 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.
robertlagrant 5y ago
I'm still plumping for Kotlin Multiplatform as the highest-quality, best value approach.

192 points by northstar702 5y ago

sigmaprimus 5y ago

Just in time to handle the "Huge Increase" in withdrawls I suppose.

dheera 5y ago

Is there a ReactCoin? #moon

kvirani 5y ago
HN !== Reddit

jabo 5y ago

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.

jessepollak 5y ago
We are doing this already and plan to increase the investment over time. Stay tuned!

echelon 5y ago

HTML is the best cross-platform document and application specification ever conceived. 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. 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. 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. 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. We've taken the wrong path. The W3C should have written a native app spec, described native widget tool kits, and kept the duopoly at bay. We were all distracted as to what was really going on. 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).

petmon 5y ago
I disagree. An application platform establishes UI conventions. It's not "wasted productivity" to build software so that it participates in the conventions that users expect. That empowers users: they can do more with your app, by bringing their knowledge from other apps. The web erodes UI conventions. Find, bookmarks, back button, copy and paste, undo, select all, etc. are worse on the web, compared to 5 or 10 years ago. And those are just basic functionality, table stakes for any app. Web apps are making us all less computer literate: they do less, and so we expect less from our software. That's the wrong direction!

vmception 5y ago

If I wanted to do android development again, I have no idea which skillset to optimize for React Native? Kotlin? An old version of Java that just got lambdas? Are we doing Model-View-Presenter (MVP) no matter which? Or are we still doing Massive-View-Controller (MVC backronym) Are there adequate networking, database ORM, and image loading libraries for all frameworks? 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

WrtCdEvrydy 5y ago
React Native or Flutter depending on your desired target.
hardwaresofton 5y ago
None of those! The real answer is Nativescript -- https://nativescript.org https://nativescript.org It doesn't get the buzz, and the ecosystem is somewhat old (it's surprisingly common to run into a repo that hasn't been touched in a year) but it's the superior platform to React Native and you get none of the capriciousness of the React ecosystem (if anything the Nativescript community might need a jolt). Nativescript is incredibly productive and you can bring along frameworks that do their best to move the work to compile time (like Svelte). I think the best options form a spectrum like this: (PWA)-------(NativeScript/React Native)------(Flutter)------(Kotlin/Alternative iOS environments)--------(Objective-C/Swifth/Java "fully native") If you choose essentially anything on the right side of flutter, performance will be relatively good out of the gate, and anything to the left (including flutter) and you have to be a little careful. I think Flutter is actually the worst of both worlds because I'm heavily biased against Dart after using it, but it is obviously backed by a behemoth, and the render-every-pixel model makes it insanely portable. If you want to write-once-run-everywhere (generally a bad idea, but if it works for you who cares), then flutter is the best by a longshot.
- vmception 5y ago
  NativeScript is obviously the wrong answer I want to pass interviews and do android development for employers Thanks for the spectrum, which one would I lead with and expect to answer the most questions in and complete project time trials on

rapsey 5y ago

How does the app perform now?

htormey 5y ago
Theirs an image in the article that compares business and performance metrics before and after: https://miro.medium.com/max/7200/0*L6GxhXWiTckqwMYL https://miro.medium.com/max/7200/0*L6GxhXWiTckqwMYL Ratings and some perf metrics(start time) improved, no regressions.
- rapsey 5y ago
  Ok but was it good before the rewrite? :)
mcny 5y ago
I don't know anything about react native and from my (limited) experience with titanium, I'm not a fan of js based "native" apps. That being said, I didn't know the iOS app was react native. I don't use coinbase much but it feels pretty good. I'm wondering in hindsight if titanium wasn't so bad and I just didn't have a firm enough grasp on js and CSS.
- slow_donkey 5y ago
  IMO before react native came on the scene there were no well performing hybrid app frameworks except possibly xamarin. So it likely wasn't your fault
EvilEy3 5y ago
Android performance is garbage. Source: just downloaded app.
- intev 5y ago
  I call BS. I just downloaded it and it works fine. Literally every single one of your comments has it out for this transition. I trust my own experience and their data.

kumarm 5y ago

2025: Coinbase successful transition from React Native to Native apps. Seriously haven't we seen how this play-out way too many times already? 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. Edit: Example: https://softwareengineeringdaily.com/2018/09/24/show-summary-react-native-at-airbnb/ https://softwareengineeringdaily.com/2018/09/24/show-summary...

codingslave 5y ago
React native is just better, and it has been for years.
- EvilEy3 5y ago
  Better than what?
ec109685 5y ago
They addressed Airbnb's experience in the blog post. In addition to abandoning React Native, Airbnb created their own templating language best suited for their app and rolled it out to both platforms so they didn't have to handspin every screen.
- EvilEy3 5y ago
  No, they didn't address anything. They only said that it didn't work for Airbnb because it wasn't greenfield. The real reason it doesn't work out, is because React Native is a dumpster fire. If you really want to go cross platform way, then go with Flutter or wait for JetBrains Compose to target iOS.
  - intev 5y ago
    Oh yes. You know best. Their CTO did no due diligence before making such an important transition. They didn't even bother talking to AirBNB about their experience. Nothing has changed since AirBnB made their transition. You my friend, know all the ins and out more than the silly, tech illiterate Coinbase team.

nmfisher 5y ago

Anyone got experience with both RN and Flutter willing to chime in on how they compare? 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).

gfarah 5y ago
My team's anecdotal experience: In February of last year we moved from RN to Flutter. We are super happy with the switch. Our app in Flutter is used by around 1.3M users in 3 different countries. Our Flutter app is more stable (less crashlytics bugs), faster (performance wise) and keeps our mobile team happy (better developer experience). We also use Flutter Web for one app used by around 25k users, even though it is cool reusing some things from the mobiles apps, it still needs to improve in performance and stability.
- mikevm 5y ago
  What about the currently janky iOS animations with no fix in sight? https://github.com/flutter/flutter/issues/60267 https://github.com/flutter/flutter/issues/60267 I'd warn anyone targeting multiplatform mobile from using Flutter until this is resolved.
  - nmfisher 5y ago
    Yeah, this is admittedly a serious issue. If anyone hasn’t seen it, install Google Pay on iOS and go through the signup/intro screens. The lag is awful (and I say this as someone whose app in built on Flutter). I know it’s only a “first-time” thing, but it’s a horrible first impression.
eagsalazar2 5y ago
We do a lot of RN but recently had a large project that required Flutter. We were all curious because you hear good things about Flutter but, in the end, no one thought the dev experience of Flutter was better than Typescript+RN. One data point.

ardit33 5y ago

Two years from now, it will be 'why did we decide to move on from React as it was not working out' blog post It is like the circle of life with native vs semi-native (which react is), and just html apps. 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. 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. At Spotify, we had few interactions of these, back and forth... like clockwork. 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.

ec109685 5y ago
How utterly dismissive. They rebuilt their apps, increased the number of developers able to contribute to their codebase and improved metrics. That should be praised. Their point about brownfield development was a good one. In my experience the intersection between RN and Native (both code and people) is the biggest impediment.
- ardit33 5y ago
  AirBnb went exactly through this transition and back... Coinbase is just behind by a couple of years. Perhaps Coinbase' engineers, are better, or a different breed from Airbnb' ones, or perhaps React Native has matured more since 2019. Can't give you an answer. Linkedin had the exact iteration years ago. They had one of the first NodeJS Apps, driven mobile apps, and made some glossy block posts, praising it. Then quietly went back to native. Facebook went back and forth with HTML 5 sound the same time, etc.. etc.. It is like seeing the same movie over and over, with just some minor plot twists, they tend to play out the same. Since the Java's Applets promise 'write once, run everywhere', this story instead has been always the 'write once, debug everywhere'. "Sunsetting React Native Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing." https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a https://medium.com/airbnb-engineering/sunsetting-react-nativ...

cageface 5y ago

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. RN is good for fast prototyping and market value fit testing but I'm not sure I'd use it for something like Coinbase.

dstaley 5y ago
If at all possible, I can't recommend Expo enough. I hated building RN apps prior to it, and now I hate building apps without it.
- FlashBlaze 5y ago
  Isn't the apk size much larger if you use Expo? Or is that not the case anymore?
  - dstaley 5y ago
    With the EAS Build system, it's no longer a concern. Available to paying customers at the moment.
- macando 5y ago
  When Expo works like it should it's like the best dev experience ever. Supporting all React Native 3rd party components without ejecting and ditching the Expo app will be a huge step forward.
  - _fat_santa 5y ago
    Expo is great for prototyping and small apps with limited scope. However anything bigger and expo just doesn’t work. At some point you will need to mess with the native side of thing, most of the time to initialize things like Firebase or adding a lib with a bridge. When you have to make native changes, no matter how small, Expo will get majorly in the way

Softcadbury 5y ago

I'm never touching mobile development and especially React Native again! I'm a web developer and a few years ago, I had the opportunity to develop a mobile app. What a nightmare... 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.

k__ 5y ago
I would do it again. Mobile is generally shit, but RN made it bareable. But, yes, much bigger overhead with all the native stuff. I'd recommend everyone to use web tech whenever possible.
- amelius 5y ago
  Also, why support the duopoly if you can develop for the open web instead?
  - chrisco255 5y ago
    Because mobile Safari still sucks and they take forever to support new web standards.

SatvikBeri 5y ago

I'm skeptical of most "we switched from X to Y" posts, but the thought process here seems pretty solid. * They had a much harder time hiring mobile developers than web developers, and per-person productivity was also lower * They prototyped an app before committing to a new technology * Similarly, they tested a change to the existing app before switching * They specifically invested time to cross-train people, and tested how long it took web developers to get productive on React Native * They interviewed Airbnb, who had also invested a lot of effort into React Native before dropping it * At each step, they considered whether to rewrite from scratch or incrementally switch that part of the codebase This makes a lot of sense. It shows the kind of careful consideration we should apply when seriously considering switching to a new technology.

deepsun 5y ago
>They had a much harder time hiring mobile developers than web developers... It's not hard at all to find mobile devs, just offer more money. Mobile devs cost more, that's right. But I think that's because mobile development is significantly harder (personal first-hand experience).
EvilEy3 5y ago
> They had a much harder time hiring mobile developers than web developers, and per-person productivity was also lower That's what happens when you pay peanuts.
- intev 5y ago
  Oh? You know everyone's salaries?
  - EvilEy3 5y ago
    I don't see shortage complaints from FAANG companies.
    - intev 5y ago
      Are FAANG companies the median for tech salaries? If that's the case most companies are doomed. It's pretty common knowledge that FAANG pays really well. One of the big reasons people work there are for the extremely generous salaries. Everyone else is underpaying if you're comparing them to FAANG. Also by your definition, Apple and Amazon are notoriously cheap too. Really you're only comparing to Google, Facebook and Microsoft (less so).

deleted 5y ago

[deleted]

macando 5y ago

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. C'mon iOS devs you can't tell you enjoy the byzantine layout model of the native iOS apps and working in xCode. Some parts of React Native are problematic but creating screens is simple and intuitive.

jamil7 5y ago
SwiftUI is higher level again for layout and I would pick it over flexbox CSS on mobile any day.
- macando 5y ago
  SwiftUI is a strong competitor I admit.

treelovinhippie 5y ago

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

FlashBlaze 5y ago
Are there any disadvantages of using PWA + Capacitor instead of RN? Did you use Ionic for it?
- treelovinhippie 5y ago
  PWA + Capacitor would basically be a web wrapper with access to native APIs: https://capacitorjs.com/docs/v3/plugins https://capacitorjs.com/docs/v3/plugins I'm chasing the holy grail of "build once, run anywhere". I want to basically use Svelte and Tailwind and spit out web, iOS and Android apps. But I also want to use normal HTML components. RN, Flutter and NativeScript all have their own unique components which is another thing you need to learn. Will see how far the PWA approach can go when I find the time.
macando 5y ago
What were the issues with Expo and why haven't you ejected to vanilla RN?
- treelovinhippie 5y ago
  They ejected toward the end but that just makes development more difficult, particularly the deployment process. Expo is nice but the whole DX is just painful. The iOS Simulator will crash often. You need to do a hard 'expo start' relaunch often. What looks great in iOS will often be broken on Android. Trying to get pixel perfect UI and the desired UX is painful. Expo is full of bugs and limitations. RN is old and unmaintained.

_fat_santa 5y ago

Many comments here are comparing this transition to the one Airbnb did a few years back. These two transitions could not be more different. 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. 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. 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.

raspasov 5y ago
Right on point. I have done a lot of React Native but never tried to mix native + React Native (with the exception of the occasional native feature in a mostly RN project). Mixing an old native project with RN, doing a so called "slow transition" sounds like a really bad idea. Data communication between the native part and React Native will become an issue, you're effectively going to be running a mini distributed system within your device. There's probably 100 other problems that I can't even start to imagine. Perhaps a super experienced, world class expert in both JS and mobile development + runtimes can pull it off but I wouldn't be comfortable trying to do it (been doing mobile development directly since 2016 and have been close to mobile dev since ~2011). Re-write is a better option.
ryndshn 5y ago
if i remember correctly, Airbnb had many issues with RN that were not related to their incremental migration, such as the issues they had with things like debugging, where it was almost impossible to fix certain bugs due to RN using different JS engines depending on platform and context (for ex running with a debugger causes RN to use V8 whereas running locally on iOS / Android it uses JavaScriptCore or Hermes, respectively). RN is awesome but imo has some pretty serious pain points.

ashishb 5y ago

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. Shameless plug: my opinionated beliefs https://ashishb.net/all/react-native/ https://ashishb.net/all/react-native/

raspasov 5y ago

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!

hitekker 5y ago

Not too surprising. Mobile native engineers are quite expensive and coinbase has been cutting costs recently https://news.ycombinator.com/item?id=27119787 https://news.ycombinator.com/item?id=27119787

babesh 5y ago

There are some long term trends that should work in React Native’s favor. 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). Competition has consolidated the market into two platforms. This means that only two platforms need to be supported. 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.

pixel_tracing 5y ago
You couldn’t be further from the truth. Mobile is undergoing a substantial evolution in development experience. SwiftUI and Compose are changing the development world for Mobile. The compiler itself is being optimized to show UI with hot reloading.
- babesh 5y ago
  I think SwiftUI is just as much about platform lock-in by bundling Mac, AppleTV, iPad, and iPhone together as an app fortress. Furthermore it enforces more standard UI/UX which commoditizes apps. Stepping back, I think we are just seeing a battle of commoditizing your complements. For Coinbase and Facebook, Apple is the complement. For Apple, Coinbase and Facebook are the complement.
  - pixel_tracing 5y ago
    You are vendor locked in regardless whether you build it in RN or SwiftUI or compose - you are still building a mobile app and any serious mobile app will need some degree of native integration. Better to make it natively than to support an extra platform which is RN.

jfisk87 5y ago

Long story short, terrible idea unless you're in a position like coinbase. 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. 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. 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 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.

_fat_santa 5y ago
I highly disagree that an expert RN dev also needs to be an expert mobile dev. Articles like these make it seem that react native development requires native knowledge but that simply isn’t the case. With almost all greenfield RN apps, 99.9% of the code is RN and only very specific feature are helped out by native code.
- Jare 5y ago
  You don't need to be an expert in native to write a RN app. However, you need to be very capable in native to have a responsive, performant, smooth RN app, and to keep it that way for years. Large teams can afford to have a subset of platform devs and a large body of RN app devs to make this plan work (note: you now have 3 platforms: iOS, Android, and RN itself). Smaller teams will struggle. Most often, small teams will end up putting their weight on the RN side (develop new features!), and slowly slide downhill in performance, responsiveness and overall UX like the proverbial boiling frog.

jb775 5y ago

> Thinking from this perspective led us to... > the average mobile engineer’s velocity remained stagnant > this could dramatically reduce our overall staffing requirements...also have to deliver improved quality and performance for our customers 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. Obviously 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. 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.

reducesuffering 5y ago
And look at what Shopify CEO just said: "But we all have to re-qualify for our jobs every year. The red-queen race of Shopify's historic 40% or better growth is that everyone has to show up at least 40% better every year to qualify for our current jobs. I expect you to hold yourself and your teams to this standard."[0] [0]https://archive.is/Hql0j#selection-2991.215-2991.490 https://archive.is/Hql0j#selection-2991.215-2991.490
JMTQp8lwXL 5y ago
> being in a perpetual state of "1 step behind" the capabilities of native app development. For a basic CRUD app with simple data visualizations, this doesn't seem to be a huge issue compared to apps that might need to take advantage of whatever new capabilities arrive on mobile phones, though those have largely plateaued in recent years.

ryndshn 5y ago

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.

cedel2k1 5y ago

There are no winners when fighting over technologies.

EvilEy3 5y ago

What an attrocity. You could've just said that you no longer want to invest in mobile talent. 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? Hot garbage, the time you spent on this could be spent on rewriting to proper native standards.

intev 5y ago
What has gotten you so upset about this transition? I don't understand. All your comments are so vicious with no backing. >You could've just said that you no longer want to invest in mobile talent. How does this even track? They had to retrain their engineers. I call complete BS with your app experience. I have a Redmi and the app works flawlessly. They seem to have internal data to prove it. They were under no obligation to make the blog post if they didn't think it was successful. If anything they are going against the grain here so they know there are lots of people watching.
- EvilEy3 5y ago
  > All your comments are so vicious with no backing. I literally listed my experience with the app. And I didn't even create account yet. > How does this even track? They had to retrain their engineers. To leverage Web developers, right. > I call complete BS with your app experience. I have a Redmi and the app works flawlessly. Which Redmi? I'm testing on Xiaomi Mi A1. It probably works better on my Samsung S10. But then majority of people have phones closer to my Xiaomi. > They seem to have internal data to prove it. They were under no obligation to make the blog post if they didn't think it was successful. If anything they are going against the grain here so they know there are lots of people watching. Because the blogpost makes it seem like there are only upsides to technology and the only downside is that it's not fit for brownfield. I had very bad experience with RN and give my opinion on tech. What's the problem?
  - intev 5y ago

EvilEy3 5y ago

Just when there are two arguably most important migrations in mobile world happening(Compose and SwiftUI), they decided to migrate to inferior tech.

intev 5y ago
*According to you. Every 5 or so years there's an "important" transition happening. That's tech. There's been many stories written about companies that live on the bleeding edge. I don't remember any of them ending particularly well.
- EvilEy3 5y ago
  > Every 5 or so years there's an "important" transition happening. Name at least one change in Android SDK that can come close to revolution that is Compose. And same for iOS/Mac and SwiftUI. Compose and SwiftUI are doing to mobile what React did to web. It arguably single most important change that happened since the inception of mobile platforms. > There's been many stories written about companies that live on the bleeding edge. I don't remember any of them ending particularly well. What?
  - intev 5y ago
    I agree the current one is a major change but it's not mature yet. It hasn't stood the test of time. Twitter was built on RoR when that was the coolest new thing to build things on and Uber's booking engine was on Node.js when everything was being run on Node. I'm sure there's more I'm missing. .
    - EvilEy3 5y ago
      You seem to be missing my point. Compose and SwiftUI are React of mobile world. React certainly stood the test of time.
      - intev 5y ago
        That's to be seen. I very clearly remember when Angular first came out, that was clearly the way to move forward. People switched in droves. Then React came along and changed everything. React has also remained more popular than Angular has, but we didn't know that till years later. Some chose to remain in Angular (my old company) thinking it will blow over and we can swap to the next paradigm instead. Turned out React was flexible enough to last a while. Somehow you can perfectly see this is the React of mobile and not Angular?

4eleven7 5y ago

You have three options. Optimise for user experience (go native) Optimise for cost (whatever the cheapest developers, or a cross platform solution, like phonegap/pwa/react native) Optimise for developer experience (use whatever your developers know, maybe native, maybe react native) 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. 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. 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! 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.

sofixa 5y ago
> n my personal opinion, always optimise for user experience If you have unlimited money, that is. If you don't, a suboptimal UX is better than no UX. > 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. Anything else is over-engineering, generally. Ideally, yes, but depending on the app the frontend can still be heavy - e.g. with Coinbase, all the graphing and real-time stuff, done 3 times over, are probably a not insignificant effort.
throw14082020 5y ago
There's a lot that goes on in a mobile app, please read https://developer.android.com/docs/ https://developer.android.com/docs/ and https://developer.apple.com/documentation https://developer.apple.com/documentation It certainly is different to backend development, but not everything is a "JSON viewer", even if you exclude camera filters and games. Only the truly awful apps are "JSON viewers". There is a lot of complexity, and I've heard arguments from people that 'they don't want to be a front-end dev because that is just visual stuff': they're talking about pre-javascript days or talking about something they've never done to a good level. Using a backend (adding network cost)/ sharing code should be the last on your mind for mobile apps. I've had once, where the logic for feature would take less than a day to implement (which I subsequently did), but inexperienced non-mobile developers decided it would be a good idea (and said exactly what you said) to put everything in the backend to share code between iOS and Android. The interface cost (network code) cost more time in development, and made a much worse user experience. Not to mention, I had to use the code written by the inexperienced person, which had bugs. You might not understand mobile, but there's a lot more that goes on in a mobile app.

aorth 5y ago

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.

pupdogg 5y ago

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?

TheMagicHorsey 5y ago

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. I much prefer the unified approach of Flutter (everything is in Dart and not scattered in 3 different places) and batteries included component library. 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.

swyx 5y ago

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.

halfmatthalfcat 5y ago
To be honest, it's only gaining momentum because of the PR behind it. I've yet to see or hear of a major hybrid app getting shipped in Flutter.
- k__ 5y ago
  I know a few freelancers that specialized in Flutter the last year. But I wasn't convinced either.
- surajrmal 5y ago
  https://flutter.dev/showcase https://flutter.dev/showcase seems to show a lot of major applications using flutter.
jessepollak 5y ago
We did consider Flutter, but (1) we already had a very strong javascript talent base that we wanted to leverage; (2) at the time when we made the decision, Flutter was still relatively early in its lifecycle. That said, we've spent a lot of time talking with teams using Flutter and we think it's awesome!
- halfmatthalfcat 5y ago
  Could you say which teams you were talking to? Curious about companies adopting Flutter and why over other solutions.
  - jessepollak 5y ago
    Mostly teams within Google that have had success with it.

alexandr1us 5y ago

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. 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 Most comments under the link: React Native bad because Flutter good. React Native bad because native good. React Native bad because Y is good.

powerapple 5y ago
Thank you for the info. I am starting a project and was thinking choosing Flutter or React Native. I have used both Flutter and RN for some small toy projects. I really liked Flutter with fastlane. Does fastlane still work? Do people actually use Unity for apps? I am actually building an app for kids, Unity can be really interesting for me.
- alexandr1us 5y ago
  I used to use Unity for apps since it made perfect sense for simple game like apps
jpeter 5y ago
What was the worst framework? Xamarin?
- alexandr1us 5y ago
  Titanium was worse

jessepollak 5y ago

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

halfmatthalfcat 5y ago
What does your CI/CD look like? It took me a long time to fully flesh out a RN pipeline that was (mostly) completely automated. Are you leveraging Fastlane? Are you buliding both Android and iOS on OSX VMs? How do you deal with shipping canary versions and is that process also automated? Thanks!
- jessepollak 5y ago
  We talked a good amount about this [here](https://twitter.com/dan_coff/status/1393599897119592456 https://twitter.com/dan_coff/status/1393599897119592456). We are using Fastlane. We are building iOS on OSX, but Android on more standard EC2 hardware. We ship canaries with every commit to master, fully automated.
zitterbewegung 5y ago
Not really a question but more of a statement that Discover also transitioned from Native to React Native successfully and I believe they also didn't do a brownfield implementation. There was a presentation about this at React Chicago but I can't seem to find it.
pixel_tracing 5y ago
So what is your native mobile engineering team doing now?
- mekkkkkk 5y ago
  Which native mobile engineering team?

ksec 5y ago

Sort of off topic. In your opinion, What is the best React Native App, that is also extremely popular which could be used to show case the tech? 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.

deleted 5y ago

[deleted]

rvz 5y ago

The Airbnb / Udacity story is simple. Brown-fielding RN is not the way to go. Here's where green-fielding would 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. 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.) 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. Now they are stuck with implementing their features on both platform twice. 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.

SilurianWenlock 5y ago

Why does all this stuff have to change so much?

nprateem 5y ago

I'm currently building a cross platform app with vue, framework7 & capacitor and it feels like a superpower. 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.

robertlagrant 5y ago

I'm still plumping for Kotlin Multiplatform as the highest-quality, best value approach.