Live data from Hacker News

Transition to React Native

blog.coinbase.com

191–200 of 221 posts

Re: Transition to React Native

#191

Earlier quoted context omitted.

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?

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

Re: Transition to React Native

#192
post #187
post #48

Earlier quoted context omitted.

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…

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.

Re: Transition to React Native

#193

Earlier quoted context omitted.

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

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

Re: Transition to React Native

#194
post #159

Earlier quoted context omitted.

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.

Re: Transition to React Native

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

Re: Transition to React Native

#196

Earlier quoted context omitted.

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.

Re: Transition to React Native

#197
post #171

Earlier quoted context omitted.

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.

Re: Transition to React Native

#198

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…

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.

Re: Transition to React Native

#199

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…

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.

Re: Transition to React Native

#200

Earlier quoted context omitted.

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…

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

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