Live data from Hacker News

Transition to React Native

blog.coinbase.com

171–180 of 221 posts

Re: Transition to React Native

#171
post #53

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…

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.

Re: Transition to React Native

#172
post #56

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…

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

Re: Transition to React Native

#174

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.

So what is your native mobile engineering team doing now?

Re: Transition to React Native

#175

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 technic…

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.

Re: Transition to React Native

#176
post #99
post #95

Earlier quoted context omitted.

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 wi…

> 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 aff…

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

Re: Transition to React Native

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

Re: Transition to React Native

#178

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 developmen…

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 is…

Is react native is easy to learn?

Re: Transition to React Native

#179

Earlier quoted context omitted.

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…

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.

Post reply on HN