Transition to React Native | Hacker News Reader

Transition to React Native

blog.coinbase.com

192 pointsnorthstar702217 comments

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.

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.

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.

RN used to have a lot of issues years ago (~2015-2016 or so) with different layout rendering between iOS and Android. Since they re-wrote their layout engine to be the same codebase across Android and iOS this has been 99% fixed in my experience. You might very occasionally run into a difference of some sort but it will most likely be minor. Of course, I would say if you've never done a RN project before and you plan to release both iOS and Android, please DO test your app frequently on both as you code along. If you complete 90% of the code on, say, iOS only and then try to run it on Android, chances are you'll run into more WTH problems than if you were checking along the way.

none of the issues i described are different now. RN on iOS still uses JavaScriptCore by default, Android uses Hermes, and it still uses V8 if debugging, meaning it's possible you'll have some super weird edge case bugs. in Airbnb's situation i believe they said it was almost impossible to pinpoint the issue due to the differences in these engines. it's unlikely, but still an unavoidable thing that could be a serious roadblock

I've done and ran 2 medium sized apps on both iOS and Android and have never ran into such problems. While not impossible, that's akin to saying that if you run the JVM on MacOS vs Linux, there's a chance of different behavior. Possible, but unlikely. It shouldn't be a show-stopper for most situation.

ehh, not really. JVMs are all developed under the same roof but JS engines are a little more distributed and the spec has a little more room for interpretation. i agree it's unlikely, but still not ideal

Yes, fair enough. Not a perfect analogy.

Hermes runs on iOS now and besides missing Intl, I’ve not had any problems with it and flipper let’s you debug hermes.

What a trope that AirBnB story has become. They mixed their gigantic native codebase with React Native code.

Mixing native and React Native = bad.

Doing pure React Native (for everything but ultra high-performance and apps that interact tightly with hardware) = good.

I remember there were a ton of articles and hot takes around that time that dunked on RN with zero context, essentially saying that RN was dead because Airbnb couldn’t crack it.

I feel like all those takes completely misunderstood or ignored Airbnb’s technical constraints and the underlying reasons.

Anyone blamed it on the library. Not the dumpster fire implementation that ultimately killed the venture

Yeah a lot of it is context. I got the feeling from those articles that airbnb has some really strong platform specialists and if you already have two teams of people like that you can likely get more out of letting them focus on their respective platform.

There’s a huge incentive for the company to invest in this. Being multi-platform has a huge cost to small and big companies alike, as the blog post was alluding to.

The way I see it: in the early days of the web, JavaScript was very slow and browsers were operating on weak CPUs. But there was a turning point and suddenly JavaScript was now fast enough and Web 2.0 was born.

A similar thing is happening with React Native. It is kind of slow on older phones, and it felt very kludgy when it was first released. But things have gotten better and most important of all: phones have gotten substantially faster.

You still have to learn how to make high performance React Native apps, compared to React in the browser where it’s more forgiving. But this is no different than native. So I think there is reason to believe it has gotten to a point where this could be a long term decision.

> Hot reloading either barely works or not at all, load up times increase exponentially,

It works like this even on hello world apps.

The only platform where Hot Reload works reliably on mobile is Flutter.

You should check out next.js's live reload

On mobile?

Its a web framework you can test it on your mobile

The airbnb transition also had (from what I heard) a lot of politics around it. Often the things that make or break large projects aren't necessarily technical but human. For instance, if you hire a ton of native developers and force them to move to React Native without getting buy in from them, you're probably bound to fail.

There will always be technical challenges with any large project. But getting buy in from the right people can make those problems surmountable.

Artsy.net has had quite a bit of success with a brown field RN app. We adopted RN in our iOS app in 2016 and gradually used it to render more and more screens in the app. In 2020 we decided it would be nice to have an android app, and we spent the last year incrementally refactoring the app infrastructure from Objective-C to TypeScript to support that. Crucially we did the entire thing with a tiny team of 1-3 people and without blocking any product engineers from shipping new features.

We had occasional tooling issues like you describe but all fixable. I'd be happy to go through the same process again.

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

React Native or Flutter depending on your desired target.

None of those! The real answer is Nativescript -- 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.

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

> I want to pass interviews and do android development for employers

Definitely learn plain old Android-style Java, with the usual tools (android studio, etc) then. Most shops are going to be that, and if you want to pick up Kotlin for the shops that are a step ahead then do that.

> Thanks for the spectrum, which one would I lead with and expect to answer the most questions in and complete project time trials on

React Native in this scenario, unless the company already has at least one (and if it's one they have to be VERY competent) mobile engineers on both major platforms.

Fully native is the best results (there's essentially zero limitation) but is the most specialized work. PWA is the easiest, but paradoxically needs a tiny bit of specialization to get native enough that the business isn't embarrassed. Also, with PWA there's lots of hard limits on what the app can do (notifications are a particular bugbear).

I believe what you say about NativeScript but there’s not enough momentum in that solution. Learning NativeScript will give you access to a way smaller pool of projects or companies you can work for.

I think most developers would prioritize employability + traction/community/documention. There’s not even a comparison there. React Native is the superior solution.

Yeah -- I do agree with you, React Native is going to see the majority of the love.

I would like to point out that NativeScript works -- people mostly don't make buzz about it but it's out there powering apps that are delivering value, I've used it myself for a client and it was fantastic.

React Native is the superior solution only if you prioritize employability/traction/community (I disagree on documentation, NativeScript's documentation is excellent), but if you need to get an application out but are turned off by the React crazy-land and bad performance of React in a mobile context, give NativeScript a try, it's the better platform in a technical sense -- it has things React Native doesn't.

What made you dislike Dart? I find it a highly inoffensive language.

In no particular order:

- The type system was essentially like java but perhaps even worse -- in a world with Rust, Haskell, Julia, Kotlin, Scala, and even Golang this seemed egregious.

- No algebraic data types (sum/union),

- class-based inheritance

- nullable values

- using exceptions instead of errors-as-values approach.

I know they worked hard on the language (rewrites are hard, there are some good talks on there about it, link @ end), but it's like they ignored all the progress in PL over the last like decade+. Anyway, continuing on:

- JSON serialization/deserialization[1] was like the worst parts of Go and the worst parts of Java (again this has to

- SQLite driver[0] couldn't be used off device. I found this out while trying to write tests that ran off-device. Now there's sqlite3[1] so maybe it's no longer an issue

- Dart2 was a played down rewrite of Dart1, with JS interop removed. Typescript is a better language than Dart.

- BloC is overcomplicated and was rolled out poorly at the time (this has more to do with Flutter than Dart). The state management patterns felt like unbaked react (flux pattern) v1.

All this said, Dart will probably be around for a very long time. Fuschia makes a LOT of sense for Google to continue pursuing, which uses Flutter. Dart could be worse, and I think it's good enough for a bunch of usecases. If it were me, I wouldn't even choose it over Nativescript.

The Boring Flutter Development Show[3] was/is fantastic, I watched it religiously when I was learning and trying out Flutter -- having a big backer like google means there are always going to be dedicated resources and smart people behind Flutter which honestly probably matters more in the long run than Dart being a shit language. As Golang has shown us, you can just iterate to having a good language.

Feels like Dart2 has it's base to build from now, and I don't like the places it's started, but it will probably continue to succeed. At the very least you won't see bad PR about it, because most people who are willing to tweet about it are invested in it's success or want jobs at Google someday, and there is dedicated money for "dev rel".

Seeing Sony embrace flutter for embedded things is pretty big as well[4]. Sony has a surprisingly strong track record of making technologically competent products:

- PS Vita (generally regarded as ahead of it's time)

- Sony SmartWatch 1 & 2 (I owned both, they were ahead of their time, and were very good quality, easily hackable)

- Sony XPeria phones & tablets (embraced open source and easy bootloader unlock, I own a tablet that I'm extremely happy with)

[EDIT] - Separate some points about the language, also add a link to the strange loop talk on the rewrite[5]

[0]: https://pub.dev/packages/sqflite

[1]: https://pub.dev/packages/json_serializable

[2]: https://pub.dev/packages/sqlite3

[3]: https://www.youtube.com/watch?v=qXAUNLWdTcw&list=PLjxrf2q8ro...

[4]: https://github.com/sony/flutter-embedded-linux

[5]: https://www.youtube.com/watch?v=WjdrUphF5l4

Sony also a track record of letting developer communities down that aren't that relevant on their revenue stream, e.g.

- PS2Linux

- Linux on PS3

- Indie DevTooling for PSP

I'd argue most companies do this, but do the bit where they never even embraced the developer communities in the first place.

The fact that those things were even allowed to exist is awesome, and the best thing I've seen out of MS on this front is Kinect. Not sure if Nintendo has done things that developer friendly.

Most companies are intent on making full on walled gardens.

Depends on which idea you want to sell them, https://developer.nintendo.com/

Thanks for the elaborate answer! You probably have a higher standard on programming languages than I do. I understand that Dart is a very basic language, and comparing it to something almost academic like Haskell will probably make it seem real primitive and stupid. Coming from mostly frontend/UI product dev in C#/Java/JS I've had a blast with it though.

I do agree that some common patterns are contrived (BLoC, json serialization via codegen, etc), but I'm not sure it's fair to criticize the language itself for this.

Also FWIW sound null safety is now the preferred way to write Dart (given your deps have adapted to it), so that part is hopefully solved.

> Thanks for the elaborate answer! You probably have a higher standard on programming languages than I do. I understand that Dart is a very basic language, and comparing it to something almost academic like Haskell will probably make it seem real primitive and stupid. Coming from mostly frontend/UI product dev in C#/Java/JS I've had a blast with it though.

Well I spend a lot of my time yak shaving so :). Most of the time in the real world, Dart is good-enough (and is definitely better than JS without TS, from a safety/maintainability perspective).

You're absolutely right, Haskell is academic, but what impresses me about other languages was that they took little bits -- Rust took a lot, Golang took a tiny bit (protocols look more like type classes than class-based inheritance).

I'm somewhat surprised that you prefer it to C# though -- C# was supposed to be better Java, and I didn't think that Dart was better than C# outright. Maybe I'm wrong on that, if it feels more fun to use (i.e. easier so much so that it's enjoyable, but you're not frustrated).

> I do agree that some common patterns are contrived (BLoC, json serialization via codegen, etc), but I'm not sure it's fair to criticize the language itself for this.

BLoC isn't fair to criticize (it's more about Flutter), but JSON serialization is fair in my mind because it's the direct result of a too-weak type system. But yeah overall I'm making the typical HN ado about nothing. In the real world people would just pick flutter (for it's good parts) and commit.

> Also FWIW sound null safety is now the preferred way to write Dart (given your deps have adapted to it), so that part is hopefully solved.

First I've heard of this addition, and it's commendable that they're undertaking this herculean effort, but this is so meh. Typescript arguably has this problem (since it has to interop with JS), but the way you solve it is so simple there. Turn on strict mode, and you're done -- because they considered it from very early on (if not the beginning). Language designers should know what the state of the art is and make good decisions around it up front, this is like 10x worse than writing a bad framework, because you can't drop out (of the framework) -- there is nowhere to drop out to (I mean... yeah you could FFI or something ridiculous but...).

But anyway I'm just tilting at windmills -- people that have to get shit done will just get it done with Dart like they have with every other tool that is less-than-perfect. I'll just stay in my ivory molehill.

It's all good, I enjoy hearing your perspective! To be honest I've never been greatly interested in programming languages as a subject in its own right. As such, and as you correctly assume, I only got into Dart because of Flutter. Since then I've used it for backend services as well, and it's very pleasant to me.

A lot of it probably comes from the excellent devex, but it strikes a nice balance between dynamic get-shit-done-ness that you find in JS/Python, and the more verbose, safe, structured nature of C#/Java.

Global imports, method cascading, extensive list comprehensions, named arguments, inference being heavily encouraged, flexible constructors. It's been a while since I did any serious large scale coding in C#, but I just remember it being more of a verbose slog.

Are you optimizing for jobs/interviewing or for learning? If the former, just do native in Kotlin, if the latter, I like Flutter personally.

Most teams don't hire a "mobile developer", they hire an Android developer, and/or iOS developer, and/or React Native developer, and/or Flutter Developer. So unfortunately it requires some commitment, don't do all of them at once!

- React Native: Easiest to learn, good build tools/ developer experience, good amount of jobs already. Unfortunately, React Native is naturally intertwined with JS/ react, so you'll face issues with the complex world of javascript. I won't say its slow, but it certainly doesn't work for all types of apps. Also, avoid Expo completely.

- Flutter: Easy to learn, amazing build tools/ devex, very few jobs (though predictably growing). If you become a flutter developer, you can be confident the company that hired you has thought about the tech stack a little more. React Native is the defacto for quick and dirty apps (MVP), and Flutter is for more of a company thats investing in its technology, I would say.

- Android: Okay to learn, very good build tools/ devex, more jobs

- iOS: hardest to learn, okay build tools/ devex, fewer jobs

Difficulty is measured by how long it would take you to implement a feature you don't know, or just my rough feeling of building apps in all platforms, some of them professionally. Im very unusual to know all 4, and I have not met anyone else like me in my jobs.

I would pick Flutter, because you're not optimising for today, and Flutter will be there in 5 years, regardless of how big https://killedbygoogle.com/ gets E.g. The tech lead for Flutter worked on HTML, CSS, WebSockets.

Could elaborate on why to avoid expo? I found it super easy to use when I dipped my toes into RN development. Also, what alternative are you suggesting?

I’ll give two reasons. First, code bloat, expo bundles allllll their default libraries along with your app when packaged for release. Second, is flexibility. The most powerful part of react native is that it displays native views and with expo you are only given the native functionality they bundle for you, you cannot create your own.

The alternative is to just not use expo and add libraries as you need them. Then you can do things like add widgets and watchOS functionality to your app on iOS using native code. Or create your own custom native views and plugins that bind to the native sdks, giving you an edge over other bland RN apps. I love RN but only when used correctly.

If you do use Expo, you should eject as soon as possible and pick which libraries you explicitly want to include. I reduced my app size by like 60% after ejecting because of all the stuff I didn't need that was included.

I very much disagree that Android is easier to learn and iOS. The iOS SDK is incredibly simple to get started with compared to android. Dealing with extensions on iOS is really hard, but creating apps involves so much less boilerplate than in android. XCode isn’t great, but I am not a IntelliJ Jetbrains fan at all, their IDEs are way too heavy for my taste.

I concur. Another big benefit of iOS vs. Android is that the iOS SDK is both generally more capable (greatly reduced need for third party dependencies) and opinionated. The latter is hugely important because it means there’s a well supported “happy path” for almost everything, simplifying development. It’s a stark contrast to Android Framework where there’s 6 ways to do everything, 3 of which are deprecated, 2 that have odd gaps in functionality, 1 that’s the new shiny thing that’s too immature for production use, and none of which are generally “right”.

To explain further why I think iOS is harder

- Where will you learn it? Apple documentation is bad. remember this? "On Apple's Piss-Poor Documentation", 1180 points to date https://news.ycombinator.com/item?id=25046691 Android documentation is great. Yes there are at least 5 ways to do something e.g. schedule background work, load files, but its very clearly deprecated in their docs/ in the code. You can, read the code because it is open source. If you find a bug in Apple's library, what do you do?

- There are more developers, more stack overflow questions/ answers and more resources on the internet in general for Android. So even when Android has edge cases/ backwards compatibility issues, its more likely than iOS that someone has written about it.

- Apple tooling is bad: Xcode is not a good IDE to put it lightly. It gets 3 stars on the App Store. The actual code editing part is just a text editor, e.g. searching for function calls involves using the search function, as opposed to a keyboard shortcut that uses static code analysis. Most warnings for your code won't show up until you try to build it, therefore the feedback loop is extremely slow. Many iOS developers I've known admit they do not like Xcode. To upload your iOS app to the app store, you upload gigabytes of binaries. Code refactoring features do not exist on Xcode. Android Studio is one of the best IDE's I've used, and constantly adds support for more features: WorkManager inspector, deploy/debug multiple devices at once. Also, new features come out for Android Studio all the time, and Xcode seems to have not been updated with features that benefit me for a long time. Jetbrains IDEs generally work straight off the bat, and I'm very happy to see AppCode (Xcode competitor by Jetbrains) available, though it is thoroughly buggy at the moment, I still use it because writing code is nicer in AppCode.

- Basic things in the apple ecosystem are broken/ buggy: e.g. New developers in a team will have issues signing their application with the company team, the trick/ fix is to remove/ add a Xcode/ iOS capability to the project, and remove it immediately. Then signing will work. Signing the app is literally the first thing that needs to be done, why is this not fixed?

- Swift is much nicer than Objective-C to program in, but its not as nice as Kotlin. I don't want to get into programming language comparison (im sure there are connoisseurs here who can), but my opinion of reading Swift code is they are less readable and results in unusual architecture. Swift apps are also slower and bigger than Objective-C apps. Some Apple APIs are also designed in a painfully complicated way. It seems like they do not get much feedback from developers about their APIs, whereas Android is constantly getting feedback and improving. Some developers complain that Swift has changed, breaking older Swift code. I haven't heard this from Kotlin developers.

Sorry that felt like a rant. In the end you've can choose based on

- Comfort: Android is much more ergonomic for the reasons above

- Developer competition: You'll be competing with more Android developers worldwide: Android is more than 85% of the smartphone market

- Money: iOS costs $100 annually (not much but if you're starting out your first app, maybe it is). The upside is if you live in a rich country, many people use iPhones, and they also tend to spend more money on the app store.

- Market trends: iOS has added ATT/ privacy features. They've also got powerful chips but it seems like no one has learnt how to use them yet. They are ahead on hardware (M1, A14), they've got great market share in Western countries, and are poised to take even more with recent developments.

This is helpful overall but perhaps your Xcode experience is out of date, or at least several of your comments don’t match my experience of Xcode 12.5.

> The actual code editing part is just a text editor, e.g. searching for function calls involves using the search function, as opposed to a keyboard shortcut that uses static code analysis.

Xcode has indexed static analysis, symbol navigation, jump to definition, quick fixes, in-line quick help and a bunch of other features I use every day that lift it out of the ‘just a text editor’ class.

> Most warnings for your code won't show up until you try to build it, therefore the feedback loop is extremely slow.

This hasn’t been my experience - warnings that appear on build generally also appear when saving a file. There’s no need to trigger a build to get feeedback.

> Code refactoring features do not exist on Xcode.

Editor > Refactor reveals 13 refactoring options for me in Xcode 12.5.

I like Xcode, even as someone who switches between it and JetBrains editors (for frontend/backend work) every week. The only thing I really miss is stable vim emulation.

Good to know, thanks. Its been a few months since using Xcode, and recently have only done things in Xcode when it doesn't work in AppCode, preferring AppCode for actual coding.

I’m in the US. iOS is wayyyyy more important or else I’d have 50 users of my app instead of over 2000.

Android has a lot of documentation but there are so many more layers to Android development than iOS. On top of that, the best practices on iOS are very consistent while on android they change like twice a year, it’s exhausting. Finally, I personally dislike working in the Java ecosystem, so android is way less fun for me than web and iOS is

Oh yes, sorry, I think in the US, iPhone is dominant. Even more. I expect them to spend more money too. My perspective is the UK, where there is a 50:50 split of Android and iOS. A consumer app company I worked for previously made a lot more money from iOS users than Android.

In terms of market, do your research on jobs and skill demand in the area.

> the new shiny thing that’s too immature for production use

Both Android (e.g. Jetpack Compose, new privacy centric storage APIs that we are now forced to use) and iOS (SwiftUI) have this. I guess we'd need to list them down and compare.

> iOS SDK is both generally more capable

Yes, Apple provide more higher level functionality, at the expense of flexibility. Android also provides higher level features, but these are provided in external libraries which you can package in your app. When it comes to auxiliary features though (e.g. machine learning), I think Apple does the high level APIs much better. Android's features are quite a bit buggy.

Pity that those external libraries tend to get rotten without any path forward, e.g. SceneForm.

On that note, Android 12 just deprecated Renderscript and now Google expects App developers just to deal with NDK, and Vulkan compute to port their RenderScript C99 scripts on their own while learning about the NDK, downloading github repositories with stuff that should be in the SDK and naturally learning Vulkan as well, no big deal I guess.

Is react native is easy to learn?

If you're already a proficient React developer, yes.

>If I wanted to do android development again, I have no idea which skillset to optimize for

I prefer native, but I'm pretty biased, to be fair.

In native-land we're doing more or less all of our development in Kotlin these days. It's a really nice language. XML-based Views are still where it's at, but Google have been developing a new view toolkit called Jetpack Compose which is very likely where we are going next. It's based on the reactive view-paradigm popularized by React, but I think it's getting a lot of benefits from moving second and having been able to learn from what React has done. Also, it's not JavaScript, which is a big plus.

>Are we doing Model-View-Presenter (MVP) no matter which? Or are we still doing Massive-View-Controller (MVC backronym)

We're doing MVVM these days. Or whatever you would like to call the following description:

>There's an object called the ViewModel which survives activity recreation, from which in your view-layer you subscribe to some state. The ViewModel also facilitates access to the Model-part of your application with state and network access and whatever

>Are there adequate networking, database ORM, and image loading libraries for all frameworks?

I'd say so, yes. The Jetpack-family of libraries by Google are all pretty good.

For networking, you can use Retrofit by Square For database ORM you can use Room by Google. There's also SqlDelight by Square if you like a lighter approach to database interaction. For image loading the most recent contender is Coil, but Glide also works pretty well.

>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

I can't promise you that the entire android development scene has aligned on anything entirely yet. This may very well still be the case.

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.

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.

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.

> Large teams can afford to have a subset of platform devs and a large body of RN app devs to make this plan work

This has been my experience as well. I work on an app that supports multiple generations of iot products. We were forced to start developing for the next gen product in react native, and let the legacy stuff just use the exiting ios and android codebases. We made it about 9 months before throwing out the react native work and porting it all back to native. Management doesn't realize that moving to react native doesn't mean you now only have to support 1 platform, it means you're now supporting 3.

This is where Kotlin Multiplatform works well - you only need Android/Kotlin, and iOS/Swift skills. You save money where you can (e.g. shared code to do API calls / auth / calculations / etc etc) and still get the best-quality apps from the native code you're still writing.

Fun fact - your new word "aplkenabd" is a one-hit wonder on Google! What was it meant to say?

“Apple and”. Probably written (a bit too) fast on a phone without reading it back before hitting ‘reply’.

Web developers, no prior mobile experience, we launched a RN app just fine with minimal outside assistance. It did take some problem solving / trial and error at times dealing with, e.g. cocoapods issues though, yes.

> the best react native developer also is an expert in native mobile development.

It's not that bad. All they need is at least 1 iOS expert and 1 Android expert in the team.

> infamously know to not favor solid user experiences

I don't think that's necessarily the case. Discord is doing fine for me. Most of the apps don't need such high performance as video games.

People always rant about React Native and Electron. The reality those techs are just scapegoats because most of the companies chose them because they want to build something cheap. If they use the same budget to build the same set of functionalities using native technologies for each platform, the outcome could mostly be even worse.

The AndroidX transition breaking basically everything was worse than everything Apple did combined in my opinion. That was such a massive and messy headache.

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.

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

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

Oh? You know everyone's salaries?

I don't see shortage complaints from FAANG companies.

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

> Are FAANG companies the median for tech salaries? If that's the case most companies are doomed.

FAANG salary is the median for good developer salary, yes. After all, why would you work for less if you're good enough?

> Everyone else is underpaying if you're comparing them to FAANG.

You're getting somewhere.

> Also by your definition, Apple and Amazon are notoriously cheap too.

Pretty sure they're paying bigger salary than coinbase does. At least their product is more interesting than crypto dashboard, maybe that's how they compensate for "shitty" pay.

I just compared their salaries on glassdoor. There seems to be quite a few data points. Their salary seems to be higher than Microsoft but lower than FB. Overall, comparable. Where are you getting this Coinbase is paying everyone "shitty" pay? I hope you have something...but I'm not holding my breadth

Coinbase does not pay peanuts, look at the compensation:

https://www.levels.fyi/comp.html?track=Software%20Engineer&s...

It's definitely competitive pay.

This is an excellent summary of our approach - thanks for writing it up :)

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.

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.

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.

Isn't the apk size much larger if you use Expo? Or is that not the case anymore?

With the EAS Build system, it's no longer a concern. Available to paying customers at the moment.

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.

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

Honestly I think you'd be surprised just how far the managed workflow can get you these days. That being said, Expo is aware of the limitations and is actively working on addressing those.[1]

[1] https://docs.expo.io/introduction/why-not-expo/

It's too limiting right now. When the Expo team finishes the "Expo Application Services" it will be an option for almost every project. For now, it's limited to just the Expo APIs and for most projects you will ultimately end up ejecting.

I think also a requirement is to have experts in React, iOS, and Android. Plus maybe even someone who focuses fully on React Native internals. Those dedicated people ensure all components compile and other developers can be productive. With the headcount of Coinbase it seems to be worth it.

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.

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!

We talked a good amount about this [here](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.

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.

So what is your native mobile engineering team doing now?

Which native mobile engineering team?

The ones that were initially hired to work native Android / iOS?

We’re they down sized? Re trained? Etc. and so on. Can you speak about the process around this and so on. I understand you want to give a positive image externally here, but I’m more interested in what struggles occurred and how you resolved it / did not resolve it.

Sorry, I'm not the OP. I just tried to be funny. As in "there's probably no such team anymore".

All of them were cross-trained to be React Native engineers. Many of them are now working full time in React-land doing product engineering and some of them are working on lower level native infrastructure. We saw very little attrition and have emerged as a stronger, unified client engineering group (across mobile and web).

Sup Jesse!

Hi!

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.

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.

I used to use Unity for apps since it made perfect sense for simple game like apps

What was the worst framework? Xamarin?

Titanium was worse

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.

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.

Also, why support the duopoly if you can develop for the open web instead?

Because mobile Safari still sucks and they take forever to support new web standards.

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.

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.

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.

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.

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.

SwiftUI is higher level again for layout and I would pick it over flexbox CSS on mobile any day.

SwiftUI is a strong competitor I admit.

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 is just better, and it has been for years.

Better than what?

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.

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.

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.

> Their CTO did no due diligence before making such an important transition.

He certainly didn't do enough of it, right. They have traded long term prospects for short one.

In the long run you'll have more issues with React Native than upsides.

They cited issues with hiring native mobile devs, well now they've made it even harder for themselves. Since they need to find devs who know both native and React Native. And those guys cost even more than pure native devs.

That's actually a good idea for a career. Learn native, React Native and make big buck from companies that are stuck with React Native.

> He certainly didn't do enough of it, right. They have traded long term prospects for short one.

This is extremely presumptuous to say the least. It assumes they didn't do enough and that you know more.

Presumptuous is to think that their decision is impeccable and that I don't know shit when you have no idea who I am and what I do.

I never once said that their decision is impeccable. in fact I mentioned it probably has draw backs. What I did say was you don't have enough information about the decision making process and thoroughness. They cared enough to talk to the AirBnB devs which highlights how thorough they attempted to be.

> I don't know shit when you have no idea who I am and what I do.

Your words not mine. Re-read all of my responses without your blind hatred for what they did. All I am asking for is to give them the benefit of the doubt that they did their research and made a good decision. Of course it's clear you find that incomprehensible.

> Your words not mine. Re-read all of my responses without your blind hatred for what they did. All I am asking for is to give them the benefit of the doubt that they did their research and made a good decision. Of course it's clear you find that incomprehensible.

I think you're right. In their case this was the best course of action, unfortunately. Not every company has capacity to do things right.

React Native does suck big donkey though.

The Airbnb example could be written as why we transitioned back to Rails after trying Django. Obviously if it's a Rails shop and you try to introduced Django you're going to have a bad time. These are different developers. Same thing happens on mobile. If you hire a bunch of iOS devs they and try to introduce React Native it's not going to work.

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.

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.

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

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/

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.

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.

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.

I know a few freelancers that specialized in Flutter the last year.

But I wasn't convinced either.

https://flutter.dev/showcase seems to show a lot of major applications using flutter.

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!

Could you say which teams you were talking to? Curious about companies adopting Flutter and why over other solutions.

Mostly teams within Google that have had success with it.

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

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.

What about the currently janky iOS animations with no fix in sight? https://github.com/flutter/flutter/issues/60267

I'd warn anyone targeting multiplatform mobile from using Flutter until this is resolved.

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.

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.

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.

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.

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

There's a lot that goes on in a mobile app, please read https://developer.android.com/docs/ and 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.

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.

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

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.

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

Why does all this stuff have to change so much?

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

How does the app perform now?

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.

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

Theirs an image in the article that compares business and performance metrics before and after:

https://miro.medium.com/max/7200/0*L6GxhXWiTckqwMYL

Ratings and some perf metrics(start time) improved, no regressions.

Ok but was it good before the rewrite? :)

Android performance is garbage. Source: just downloaded app.

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.

Try to create account, input some gibberish, see "something went wrong" dialog and close it.

And define "fine" first. If you mean that it works, sure. But it works slower than truly native application, like Telegram.

By "fine" I mean it does what I expect it to, doesn't throw bizarre errors and hasn't crashed (so far). Could it be faster? Sure. Does it bother me? Not even the slightest. So many apps I use regularly run much slower than this.

This is the error that most web devs make. Their definition of fine is so low, that they can't comprehend reasoning why web tech is inferior on mobile.

LOL. So now my standards are not high enough? Everyone should program in C. Definitely one of the fastest. So we can all serve your highest standards.

Nope, on Android you'll have to interface with native toolkit anyway. Even if you write everything in C. Just follow the platform instead of fighting it.

There are no winners when fighting over technologies.

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.

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.

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

What then do you think is the “correct state” that they should skip all the experimentation and jump straight to?

Personally, I suspect the reason that big teams are experimenting (and finding successes despite some failures and trade offs) is because this is a difficult problem that isn’t solved and requires ongoing creativity and experimentation.

I am not dismissing React Native, and saying it is a bad technology, (it is pretty good for a certain type of apps) and it can work for some.

If you see my end note, "to more junior engineers", don't use React Native in your project because X company is using it, and it must be trendy.

Use it only if you do enjoy using it. If you are already good/skilled at building native apps, then you might not need it at all.

AirBnB tried to mix their big native codebase with React Native and end up with a Frankenstein.

The article specifically mentions that they spent a lot of time interviewing AirBnB about their experience and links to the same post.

"If you’ve read Airbnb’s excellent Sunsetting React Native article, these challenges may sound familiar. We spent many hours speaking with engineers from Airbnb and trying to learn from their experiences. We’re grateful to the team for sharing the details of their journey, as the information was invaluable in deciding the best path for Coinbase. One of our key takeaways was that the brownfield approach seemed to be core to many of the challenges they faced. While the idea of incrementally migrating is at first glance appealing — leveraging the benefits of React native for new features without the upfront cost of a full rewrite — it introduces significant technical and cultural migration risk over the long term."

You’re the one being utterly dismissive with your condescending tone and failure to acknowledge any points that op made. Sounds like they’ve been around long enough to have seen this cycle a few times. Used to be Ruby on Rails was the next coming of Christ.

You know what is dismissive? Switching to a lowest common denominator and offer subpar experience. This is what happens when you offer React Natives to users.

They dismissed advancements in native development and they'll pay the price the future.

It's literally laughable that they decided to transition to half dead tech when Compose and SwiftUI are ramping up.

It's literally laughable that you call react native a half dead tech. It's still *the* most actively developed ecosystem for cross platform apps. Don't believe me? See https://insights.stackoverflow.com/survey/2020

Moving such a mature company's codebase to bleeding edge tech is one of the stupidest decisions you can make. Is there some price to be paid to be in the future? I'm sure there will be, as there will be with any non native platform. Whether is will be a deal breaker is to be seen.

> It's still the most actively developed ecosystem for cross platform apps. Don't believe me? See https://insights.stackoverflow.com/survey/2020

Riiiight, and quickly followed by Xamarin and Cordova. Lol.

Of course it is not dead in terms of usage. It is more "dead" for anything complex.

I'm looking from a perspective of a best experience, best performance and best integration. If your only reasoning is "we can't afford proper mobile developers" that's probably not the best pitch for a technical folk.

Even Facebook, creators of React Native don't use it.

> Moving such a mature company's codebase to bleeding edge tech is one of the stupidest decisions you can make. Is there some price to be paid to be in the future? I'm sure there will be, as there will be with any non native platform. Whether is will be a deal breaker is to be seen.

Who says about moving now?

> Riiiight, and quickly followed by Xamarin and Cordova. Lol.

I'm confused - is this meant to be a disbelief of the survey? "quickly followed by"? Are we seeing the same thing? Did you see the %s? It is significantly lower. Of course there are Xamarin and Cordova developers still. Especially in Asia.

> Who says about moving now?

So wait years and see how everything plays out? So basically you have no solution. Clearly the issues were pressing enough that they needed a more immediate solution. A solution they thought was worth re attempting despite its previous failures.

> I'm confused - is this meant to be a disbelief of the survey? "quickly followed by"? Are we seeing the same thing? Did you see the %s? It is significantly lower. Of course there are Xamarin and Cordova developers still. Especially in Asia.

Oh, I'm sure there are many of them! Just as there are many Visual Basic developers, or people who do everything in Excel.

> So wait years and see how everything plays out? So basically you have no solution. Clearly the issues were pressing enough that they needed a more immediate solution. A solution they thought was worth re attempting despite its previous failures.

No, my solution to the problem would be to rewrite from scratch in native, without waiting for Compose/SwiftUI.

But for some reason it is so much easier to justify rewrite in X, because if it was written in Y, than of course Y is to blame for our shitty practices and lack of developer culture. They neglected best practices, piled crap upon crap and somehow it is native toolkit that is to blame.

Yea so your react native is dead argument is bs. You clarified it later saying you meant for complex projects but in another comment you claim that they're just a crypto dashboard. So which is it? Do they have a complex project (not a dashboard) and need something more than react native or they're a dashboard app and react native is fine? The things you say don't line up.\

> But for some reason it is so much easier to justify rewrite in X, because if it was written in Y, than of course Y is to blame for our shitty practices and lack of developer culture. They neglected best practices, piled crap upon crap and somehow it is native toolkit that is to blame.

Is it really incomprehensible that there's a valid reason to rewrite in X? Now you claim they have shitty practices and no developer culture? What did coinbase do to you? Have you worked there? Did you see their "crap" code? If you don't have anything to back it up, I'll add it to your bs list.

> Yea so your react native is dead argument is bs.

How so?

>You clarified it later saying you meant for complex projects but in another comment you claim that they're just a crypto dashboard.

Do I really need to chew everything for you? Crypto dashboard means that they have boring product, I never said it was simple or complex.

> So which is it? Do they have a complex project (not a dashboard) and need something more than react native or they're a dashboard app and react native is fine? The things you say don't line up.\

Native of course! With native applications you won't have issues like dangling shadow, or application being restarted under your nose when you open privacy policy. And I didn't even look at memory consumption and CPU utilization yet.

> Is it really incomprehensible that there's a valid reason to rewrite in X?

Nope, I can imagine that their use case is valid. But for a wrong reasons.

> Now you claim they have shitty practices and no developer culture?

Easy! If React Native application is more performant than your native application, then something really, really, reaaaaally wrong happened. And technology is the last to blame in this case.

> What did coinbase do to you? Have you worked there? Did you see their "crap" code?

What makes you think that if I criticize their technology choice, I have something against them?

> If you don't have anything to back it up, I'll add it to your bs list.

Lol.

> Even Facebook, creators of React Native don't use it.

Yes they do. https://www.facebook.com/careers/v2/jobs/710998039655439/

"Work closely with our PM and design teams to define feature specifications and build the next generation of products leveraging frameworks such as React & React Native"

The top contributors are Facebook Engineers: https://github.com/facebook/react-native/graphs/contributors...

>See https://insights.stackoverflow.com/survey/2020

What is this survey supposed to show?

To show how popular the framework is and that it is not "dead". Also to sure that it is not universally hated. 57.9% loved is not as good as the 68.8% of Flutter but it's not a huge margin.

> as they usually are just PR for internal teams, so someone gets a promotion

CEO of Shopify praised React Native in January 2020. I guess he was aiming for that postition of Senior CEO there.

Your comment reminds me of http://boringtechnology.club/ :)

RN is better from the business point of view. I have noticed that some devs don't like RN, because they can't write native code or they only can write native code to Android/iOS. So they can't do everything and are disappointed.

The airbnb cycle

Have you worked with React Native or done other mobile development?

I think it's possible to go native -> RN -> native without the whole being a failure. You may have a product that hasn't gained the traction that it should have because you have to build everything twice and just don't have the engineering resources to support that adequately. You move to RN, build out a whole new suite of features, gain momentum (and lots of revenue), and are then able to switch back to native now that you can afford to hire enough engineers to fully support each team.

Might Coinbase be rich enough to support native iOS and Android teams? Probably. I'm not trying to litigate Coinbase's decision.

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.

Are there any disadvantages of using PWA + Capacitor instead of RN? Did you use Ionic for it?

PWA + Capacitor would basically be a web wrapper with access to native APIs: 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.

What were the issues with Expo and why haven't you ejected to vanilla RN?

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.

> RN is old and unmaintained

Can explain the last commit being 2 days ago and the steady progress they've made on all fronts in the last year?

Try build a production app and you'll very quickly find the multi-year bugs in core components that require you to either build elaborate workarounds or 3rd party packages.

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

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

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

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

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

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

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

You seem to be missing my point. Compose and SwiftUI are React of mobile world.

React certainly stood the test of time.

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?

Unclear on what you mean here React will always be inferior to SwiftUI and Compose. All Apple has to do is release a new port of Javascript<Whatever> version 2 with limitations and boom goodbye React

Compose is literally React. It has different execution model, but the same programming model.

Maybe you should first read about subject before arguing for the sake of arguing?

https://speakerdeck.com/lelandrichardson/react-meet-compose?...

I don't care that it's literally React. The react model doesn't work for every platform. I do know the subject. I'm no expert but I've lived long enough to know that one paradigm on one platform is not the solution for all platforms. Stop making assumptions.

Name one where it doesn't work.

Arent they just a copy of React.js? But in native

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.

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.

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

> I literally listed my experience with the app. And I didn't even create account yet.

That's not all you did. You implied they pay their employees very little, that they didn't do their research before making the switch and called the whole thing an "atrocity" which is heavy to the say the least. That's not an app review.

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

I have a Redmi 8 (2019). Most people in the US have something similar to a low budget phone from 2017? I find that extremely difficult to believe. India, probably. US/UK etc? Highly unlikely.

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

Yes that is their experience so far. They wrote about it and have data to believe it. You don't have either except random anecdotal data and visions about the future.

> I had very bad experience with RN and give my opinion on tech. What's the problem?

Most of your claims don't have merit other than random anecdotal data which you are using to refuse their anecdotal data which is actually a lot less anecdotal that yours because they have many more developers and users.

> You implied they pay their employees very little

No implied. I stated it directly. Pay shit and get shit.

> that they didn't do their research before making the switch and called the whole thing an "atrocity" which is heavy to the say the least. That's not an app review.

I'm not an app reviewer, I'm a techie. And sorry that I didn't sugarcoat it enough for your sensitive ears.

> Most people in the US have something similar to a low budget phone from 2017? I find that extremely difficult to believe. India, probably. US/UK etc? Highly unlikely.

I'm sure Electron devs use the same reasoning when developing their stuff. After all, who has 8GB of RAM now?

> Yes that is their experience so far. They wrote about it and have data to believe it. You don't have either except random anecdotal data and visions about the future.

What data, again? "Internal metrics"? They provided literally zero data. The only thing they provided is improved startup on iOS and no data (sic!) from Android.

>Most of your claims don't have merit other than random anecdotal data which you are using to refuse their anecdotal data which is actually a lot less anecdotal that yours because they have many more developers and users.

I never said that my opinion is objective. If you can't handle critique, maybe you should quit online forums.

> I'm not an app reviewer, I'm a techie. And sorry that I didn't sugarcoat it enough for your sensitive ears.

What are you talking about? Why all this rage? In your previous reply you claim to innocently just talk about your experience with your app. That was a very clear lie and I pointed it out. And now you claim I have sensitive ears? Jeez...

> I'm sure Electron devs use the same reasoning when developing their stuff. After all, who has 8GB of RAM now?

haha way to move the goal posts after you get caught with some other bs you said! First you claimed most people had something similar to your phone so it should be working well on yours. But when I pointed out that this has incorrect assumptions suddenly the goal post is the app should be able to run really well on a a low budget entry device.

> What data, again? "Internal metrics"? They provided literally zero data. The only thing they provided is improved startup on iOS and no data (sic!) from Android.

That's significantly more than anything you've provided. All you have been doing is pointing at random things and saying "I know better than them".

> I never said that my opinion is objective. If you can't handle critique, maybe you should quit online forums.

I've come this far, doesn't a genius to tell whether or not I can handle critique. Question is can you handle being called out without kicking and screaming about knowing better and moving the goal posts of the topic in discussion? TBD

Is there a ReactCoin? #moon

HN !== Reddit

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

Reply on news.ycombinator.com