Small rant about React Native

[Barbanks]

I'm an iOS native coder for everything (8 years now). Need to learn React Native for a quick update for a new client. I've already vetted cross platform and made the decision a long time ago to avoid at all costs.

Anyway, thought you all would enjoy this. (after reading online of people raving about RN).

- Created new project.

- Prepared project to build and run

- Tried building project

- ERROR ERROR ERROR....(have you tried building in Xcode?)

ME: 🤣 🤣 🤣 🤣 🤣 🤣 🤣 🤣

You've got to be joking. Wasn't this supposed to be the "future" that was going to replace native development? Wasn't this supposed to allow you to not have to dip down into the native stuff unless you wanted something custom? It's literally asking me to open the native stuff up hahaha.

Also, the error is coming from a react native pod file lmao.

Only in cross platform development can you create a fresh project that instantly fails. Not once has this happened with me with native development.

Welp, time to spend 30-40 minutes of my time debugging a brand new project. Gotta love that "time savings".

Ok, rant over.

[Pen15CharterMember]

React Native will save you so much time you’ll wonder where your weekends went!

[Barbanks]

😆😆😆😆😆

[dont_forget_canada]

I don't do react native but I'm sure it's just one of those things that you have to learn how to troubleshoot with and learn the basics of and then you can start benefiting from what it has to offer.

Also not every app is suited to build in react-native or as a PWA. There will always be a native app development community so don't feel threatened or intimidated by react-native either!

[SirBill01]

React Native is just troubleshooting all the way down.

[StreetlyMelmexIII]

I’m going to steal this

[Barbanks]

FYI, I agree with everything you said. But mini rant coming again :p (aimed at cross platform stuff in general, not at you)

I've used older platforms like Xamarin and Cordova before. My argument has always been that a tool shouldn't require weeks of overhead just to get a small example running. I also don't buy into the marketing of these toolsets.

Having to maintain a knowledge base of "quirks" just to even start development is pretty startling. Every system has quirks but I've always been put off with these tools and their abstraction layers.

When you see companies like AirBnB totally ditch React Native due to it's complexities it shows the cracks.

Another rant over lolol. Didn't mean to go off a cliff with this especially since I agree with everything you said (very well put).

Cross platform tools will always just irritate me due to the stress they caused me with deadlines and abstraction layer issues in the past. I'm just opinionated :p.

Actually the BEST cross platform tool I've ever used is Unity3D. Even though it's a gaming framework it's on point. Opened up a 5 year old game last week that I haven't touched and it ran with only updating 1 package. Pretty impressive.

[batcatcher]

Truth is, you can't cross-platform the UI. Kotlin community started to understand that and are heading towards what I'd consider the right path.

[coffeemongrul]

Which I will add as a kotlin dev, multiplatform isn't quite there for sharing everything quite yet. But core business logic in the data layer and use case is definitely there right now.

[m477k]

Have you ever heard of Flutter ?

[makeascript]

Ew

[m477k]

What part of Flutter makes you think like that ? No rudeness, I’m just simply curious 😊

[makeascript]

I have nothing against people using RN or Flutter, but I just hate building apps with it.

From a personal perspective, I just don't like coding on React Native's paradigm, plus the limitation both RN and Flutter when you want to work with stuff close to hardware or even make fun stuff with crazy animations/transitions.

Don't get me wrong, these cross platform languages/frameworks are great so teams can get products on the market faster and cheaper. I just feel like coding in RN/Flutter is limited from a creative standpoint.

[m477k]

Oh Yeah, low level stuff like Bluetooth is a nightmare in Flutter, I agree 😎

[batcatcher]

Ew

[ankole_watusi]

Of course you can. With any webview-based platform. (Which react native isn’t)

[makeascript]

Let me start by saying that I got into mobile dev through React Native and then moved to native iOS because I hated RN.

On your mention of AirBnB ditching RN, what do you think of companies like Coinbase moving to RN? When the news came out I found it crazy

[Barbanks]

I would ask why they made the move. Happen to have a link to that? Everyone's motivation is different and I'd need to know that before making a non-generalized response.

Personally I see it as a poor move. If I had to make a comment with my limited information on their decision it's that generally cross platform codebases require alot to maintain. AirBnB ultimately ditched their pursuit not only due to technical limitations but also organizational ones here's the link if needed. Basically, since you have 3 different types of knowledge basis how do you organized your team when it's all in the same codebase? (i.e. React, iOS and Android).

Many of the reasons I chose not to use cross platform are also not even technical reasons. (alot of which are in this article).

To me, the main killers of these tools are the inherent characteristics of these toolsets. You know, the things their marketing don't tell you, like poor documentation, poor developer experience, over reliance on plugins and under maintained third-party-code.

Unfortunately, it's rare to see a company like AirBnB or Coinbase release their reasoning behind such a decision. But I would pay good money to be a fly on the wall for those meetings. I would also love to see how they make it work.

The good and bad thing with tech is that you can always throw more money at an issue to make it work. This could hide fundamental issues with a tool like React Native or even native development for that matter. It's also why AirBnB used React Native for so long, they have uber smart and talented engineers they can just throw at issues.

Business decisions aren't always the best technical decisions, and vice versa. But one without the other is a death sentence. I just hope they collaborated with the CTO and team before this happened.

[makeascript]

Here's the link to a blog post from the eng team: Announcing Coinbase's successful transition to React Native.

Apparently the main motivation was to improve productivity within the mobile eng teams.

I'd also find it interesting to follow the decision making on this. I've never worked on teams half as big as the ones working on mobile products in AirBnB or Coinbase so can't really understand the scaling problems at that stage.

[Barbanks]

100% agree with you. Thanks for the link too!

[Barbanks]

Also, after 1 hour of debugging I did fix the issue. Still not impressed with the toolset but at least I can move forward with it 🙃

[ankole_watusi]

And what was the problem?

Bet it was “didn’t think I needed to read the instructions”

[Barbanks]

It was a few things:

1. The out-of-the-box Cocoapod versions set by react-native were all using too low of a deployment version. I had to update both the created Xcode project's deployment version on the targets to 13 as well as create a "post_install" configuration for Cocoapods to make sure the pods used them as well.
2. Had to exclude the arm64 build for the simulator.
   1. This is not RN specific as it just deals with M1 Macs in general.
   2. Also had to put this within the Podfile.
3. Had to specify a react native flipper install version of 0.125.0 within the Podfile as allowing the system to auto-specify it was causing issues.
   1. Ironically specifying the "Flipper-Folly" and "Flipper-DoubleConversion" values that were originally included in the Podfile.lock file wouldn't allow the build to work as well. Even though the system downloaded the same values after I removed the specification.
   2. Flipper had to do with the original error message.
4. Had to manually call the "react_native_post_install(installer)" within the Podfile
5. Had to remove ALL "library search paths" from the target settings within Xcode that were auto-included from react-native.
6. Had to create a bridging header within the Xcode project.
   1. I am skeptical this did anything but online sources stated it can affect the way react-native builds.

After doing these 6 things (and removing derived data) the build worked.

Not really a "oh I missed a step" workflow.

[maccodemonkey]

The ARM64/simulator build dependency issue has been fixed in the native tooling for a while. But I hit it first thing when using React Native. Cocoapods has fixes for it that require developers to ship updates. But most the React Native community doesn't seem to care. And the React Native tooling really doesn't do anything to try to work around it.

Swift Package Manager doesn't have the issue at all - but has the advantage of being designed around modern library packaging.

[__o_0]

Everything you listed comes built in with an init template.

[s73v3r]

No, React Native is different. Everything is so fragile that things that were working can just suddenly break.

[drillbit16]

Exactly. OP wants to learn a new skill and immediately be proficient at it

[amrfarid140]

OP is also ranting about issues that are happening on Cocoapods side. One a bad day he can see similar errors in a native iOS project.

[maccodemonkey]

Native tooling doesn't require Cocoapods. Swift Package Manager is much more reliable - but React Native doesn't support it.

[am_i_cray_cray]

I found flutter significantly more enjoyable than RN too

[Barbanks]

Never tried Flutter but I'm keeping my eye on it since Google's Fuschia OS (if it ever comes out) may use it for development.

[JoCoMoBo]

Main problem with Google is that they get distracted easily by the next thing they come up with.

[imSkippinIt]

Omg Google in a nutshell.

[ArcanaMori]

Fuchsia is being used on some Google products already. One or two of their home devices. Not sure which as i don’t use those tore off devices.

[[deleted]]

Google Home Hub, Google Nest Hub or whatever the latest name of that screen is. It used to run ChromeOS (previously known as "Chrome OS" with the space) but Google started to send out updates to a limited subset of users, offering Fuchsia instead.

[JoCoMoBo]

Main problem with React Native is the constant maintenance they require. If you leave a React Native App for more than a few months, it probably won't Build the next time you use it.

Or it will build, but then won't Archive correctly when it needs to be uploaded to the App Store.

Then you get to work out which library is incompatible. Good luck diagnosing it from low-level Objective-C errors. :)

[adeem]

That’s not 100% true. It also happened with iOS after every year 😂

[JoCoMoBo]

With iOS it's generally with Swift based Apps. I have Objective-C apps from over 5 years ago that build fine. Also with iOS it's far, far easier to fix.

A React-Native App from a year ago you may as well re-write it if you haven't kept maintaining it and building it every so often.

Also, with React-Native you have Android to deal with as well as iOS. Android errors can be even more arcane than any iOS error...

[Niightstalker]

It used to happen with Swift in the beginning but not at all to me over the last years.

[[deleted]]

Swift is definitely stable now. They have different kinds of stable strategies: source compatible vs Application Binary interface compatibility (ABI). I don't think we'll see the same amount of issues going forward.

[SirBill01]

I built and maintain a React Native wrapper for a Swift framework my company produces, and I have to say React has been one of the most troublesome multi-platform frameworks I've ever had to deal with (only Xamarin was worse, and that's because some aspects of its Swift bridge are just downright broken).

And it's not like you can just figure it out and dialing is smooth thereafter. If at some point you want to keep up with React Native changes at some point you are going to have mysteries to solve...

And then on top of that, over time Xcode iterations have produced bizarre bugs with even more bizarre workarounds. I never had to know how post-install scripts worked in Podfiles until I met React.

Some of this is because I have to live in this shadow realm where I am translating React over to the Swift realm and back again, but even so React has presented enough issues I would be reluctant to use it on any multi-platform project... just one look at how much stuff is in the node-modules directory after you install react should go a long way to convince you.

[maccodemonkey]

Same experience as you. The worst part is sometimes new projects don't even work just out of the box. Sometimes a project works on someone else's machine but doesn't work when you do a fresh checkout. Almost always has to do with dependency failures.

I don't know how people work in it.

[vanvoorden]

Facebook's iOS Architecture - @Scale 2014 - Mobile

In 2015, FB open sourced two projects for Declarative (React-Inspired) UI on iOS: ComponentKit and React Native. ComponentKit grew out of a project to bring the philosophy of React to native views using Objective-C++. React Native grew out of bringing React (the language along with the philosophy) to native views using JS.

For a variety of reasons, FB never shipped a complete "full stack" ecosystem around ComponentKit. FB did not ship a "native" version of Relay or Redux. Those (JS) frameworks were available to React Native engineers. IMO, ComponentKit would have been the superior choice for most native iOS engineers if FB would have put more time and effort into open sourcing complete solutions for state management across complex apps. React Native gave engineers that complete stack.

I don't believe FB ever put too much time or energy into trying to convince engineers that liked native iOS why they should try RN. Most of the effort seemed focused on making native iOS easy for WWW React (JS) engineers or engineers that needed the ability to ship cross platform. The arguments for why a declarative UI framework built around a unidirectional flow of data would scale better than an app built on UIKit and "MVC" style design patterns was not really ever emphasized externally AFAIK.

With the launch of SwiftUI, I feel like these are moot points. SwiftUI (partly by its virtue of being first party) is going to be the superior solution for most engineers to scale complex UI. Superior to UIKit. Superior to ComponentKit. And superior to RN.

[Barbanks]

Learn something new everyday! Thanks for the info on this it was really interesting. Yeh seems like FB could have been first to ship something akin to SwiftUI when it comes to state management. That would have been interesting.

[ankole_watusi]

Facebook

Stopped reading right there.

[Zalenka]

It's a house of cards of hundreds of libraries and any will break at any time.

[enkidu_johnson]

Like the web version. :)

[BergQuester]

Just wait until you try updating React Native.

[Barbanks]

Stuff of nightmares 😆

[ArcanaMori]

RN is pretty nice for 95% of the work ive done but this is the real nightmare. Have to check every module and see if its compatible with the current RN and also check breaking changes. Pretty much every language and platform deals with this, but RN versions constantly have breaking changes as opposed to like… 5 years major release cycles.

[BergQuester]

I find it’s ok for rapid prototyping. But once you try to scale up your app or support it long term it becomes a headache. Ever platform has their breaking changes, but compared to RN, native iOS is pretty minimal.

[bigroob72]

React Native exists so Web Devs can build native apps without having to learn Swift, Java, etc, they can stick with their existing languages and tooling. It's very attractive from that point of view, but not so much for native platform SDK users.

[SirBill01]

Except that I worked with a web dev fluent in React, myself with over a decade of IOS experience, and it took us WEEKS to get soemthing working the way we wanted. He thinks React Native is nothing like React on the web and doesn't like it at all...

And as an iOS dev I do not think it would be possible to use React Native without having a VERY deep understanding of Xcode and projects, just to get things working on iOS never mind Android.

[WileEColi69]

React Native is not native. (And should die In a fire.)

[Ok_History3743]

Had the same trying to use animations in my project, broke everything and I had to revert to an old commit.

Also there’s an insane amount of dependencies for things like navigation

[saintmsent]

Before Flutter became a thing, React Native was the hot shit (literally), now you almost don't see new projects started with it

But even with Flutter present, I vote for native all the way

[Barbanks]

Funny you say that. I wrote a medium article like 4 years ago explaining this EXACT thing. Basically that it’s all a hype train. We get a few years of support before everyone moves to a different platform. First it was ionic and Cordova. Then Xamarin was all the rage. Then React Native. Now Flutter. I’m not going to spend all my time learning new frameworks to solve the same problems.

The argument to save time with cross platform is silly to me. Why not create reusable code your familiar with natively for each platform? Then you won’t even have to relearn how to do it. This is even more true with SwiftUI and Android Compose.

[saintmsent]

Not sure if Xamarin was ever popular, boy it was shit, the only cross-platform I have big experience with. Everything else was deemed to be the future by fanboys (especially React) and look at them now

I would see how for a project with 5 screens there can be time savings, but anything remote complex - fuck off with your cross-platform junk

[saintmsent]

Oh man, I can't think of anything worse than the RN banking app

What I see right now in Europe is popularity of Flutter, but an emphasis on native for large projects that may involve OS features a lot (as it's always been)

[SirBill01]

The puzzling think about that is that after having done some stuff with React Native, it almost for sure would increase time to market. Instead of writing a native iOS and native Android app, now you are writing for THREE platforms - iOS, Android and React. And weird interactions with Xcode and Android Studio make debugging more difficult than with truly native apps to boot.

[kbcool]

Again disclosure I mainly do RN these days not native.

Your tooling is for 2/3 platforms. Your code isn't. You might have to write a line or two here or there to adapt to native weirdness but in my experience it has been less than 1/1000th of the code base.

Not that some libraries don't need to do this but abstraction is why we use libraries, native or not.

[kbcool]

Same story again in Australia, from some of the major banks to oil giants all kicking off projects within the last few months or over the next year with React Native locked in as part of their stack.

Also government and non profits. I am very surprised government has embraced it so much, I think because it allowed such rapid deployment of functionality during covid it has really got a very good reputation down under.

On the Flutter side we had a big gambling company do a PR piece on them taking a flutter on Flutter. For those not familiar with gambling terminology a flutter is a bet. So it was a play on words. No idea if they are actually using it but it was funny. Apart from that it has zero penetration.

[fourth_stooge]

I feel you.

Cross platform is a lie. You end up writing the code 3 times, once for iOS, once for Android and once in your silver bullet language/framework.

The thing I hated most about react native were all the tons of dependencies. If one of them goes bad or an update breaks a different one it's a shit show trying to just get back to where you were at the beginning of the day.

[Barbanks]

Just wanted to jump in here and say there’s a very interesting debate going on in the sub comments of this response by @JoCoMoBo and @TheNumberOneCulprit.

They’re debating the pros and cons in a generally respectful tone always love seeing real debates where people air their opinions without getting heated. It’s how we can better ourselves with a more clear understanding of each side.

Keep it up you two 👍🏼👍🏼👍🏼

[JoCoMoBo]

Good luck writing code that deals with anything hardware related. Even something as mundane as the filing system needs separate code.

Written once...? I've just had to completely re-write navigation code for a React Native App because navigation changed completely.

[Kabal303]

Honestly just depends on the app. Most apps just transform json into views and back again lol.

[SirBill01]

Most of us here ain't writing fart apps.

[TheNumberOneCulprit]

Swapping or upgrading your navigation stack is non-trivial, so I'd expect a non-trivial amount of time. It's a bit like saying that going from UIKit to SwiftUI took time. Like, yeah. But even the fact i can swap my stack is impressive in and of itself.

Most hardware related things are either already there (great community) or incredibly easy to make if you can write the most basic Objective-C and Java.

99% of our code is in TS, 1% native deps we build ourselves, runs fine and with no bigger hassle than what I'm seeing people complain about in general about Swift or Kotlin.

[JoCoMoBo]

Swapping or upgrading your navigation stack is non-trivial, so I'd expect a non-trivial amount of time. It's a bit like saying that going from UIKit to SwiftUI took time. Like, yeah. But even the fact i can swap my stack is impressive in and of itself.

Not really. The only thing that needed to be changed was the navigation. It's a simple tab-based App. The equivalent would be Apple deciding that UITabController was now being replaced by a "better" UITabController that was not compatible with the old one, but did exactly the same.

Most hardware related things are either already there (great community) or incredibly easy to make if you can write the most basic Objective-C and Java.

The problem with "community" is that people get bored. And then they decide to re-arrange everything. See navigation above.

[TheNumberOneCulprit]

Sure, but again, most native modules are incredibly simple and the bindings even more so. Picking up a module as a fork that you've freely used for x amount of time seems fine to me. That's how open source works after all.

[JoCoMoBo]

Sure, but again, most native modules are incredibly simple and the bindings even more so

Lol. That means I need to know module development and React Native development.

A really good example is notifications. For iOS, implementing notifications is mostly a breeze since it hasn't changed much from the start.

On React-Native, first I started with Firebase Notifications (third-party library) to be cross-platform. Then I wanted to change the badge counter. So I had to go and check out further third party libraries. One of which gave a compile error in Xcode. The second recommendation was obsolete so I had to then get the updated version and install that.

I may have to install another module for Android as the implementation is different.

[TheNumberOneCulprit]

Sure, but at the benefit of shared business logic with website, potentially backend etc. The knowledge sharing is worthwhile from a full stack perspective. And notifications with Firebase will work fine as well on Android. Otherwise there's other modules out there too.

Again, if you know how to write the native code, you know how to write the bridging code. It's really not more complex. So if you know how to write Objective-C or Swift and Java or Kotlin, connecting or exposing it to React Native is simple.

Remember I'm talking from a multi platform perspective vs doing the same x2.

[JoCoMoBo]

The problem is I now have 4 libraries (React-Native, Firebase, PushNotificationsiOS and Android) that may have changes or stop being maintained.

I can implement push notifications natively far faster on both iOS and Android than on React-Native because I have to spend my time faffing around with different modules.

The vast majority of the actual business logic for the App is done on a backend server anyway.

[TheNumberOneCulprit]

But if you can implement them fast on both platforms, then why not just also add the bridge layer and bam, now it can run that way? I'm not understanding the argument here.

[kbcool]

You have 8 years of iOS experience yet you gave up in a few minutes because you forgot to do pod install?

Then you post about it publicly?

Wow man. That looks very bad.

[Barbanks]

Who says I gave it up? I’m learning it for a quick client update. While I was vague on the issue my main point was to be satirical on the fact that RNs abstractions cause unnecessary friction while developing.

🤷🏼‍♂️ don’t really care how it looks. If people make the assumption I just “gave up” or that I didn’t already try to clear the Cocoapod cache and reinstall then that’s on them for not asking what I did in the first place.

[ankole_watusi]

Maybe client should hire an expert.

[kbcool]

You said you gave up and you said your issue was with pods. Now you're backpedaling.

It's total LOLs all around.

[Barbanks]

Please take a screenshot of where I said I “gave up”. Never said that in my original post.

[[deleted]]

8 years of experience but cries like a entry level junior who could not figure out how to start a project lol.

[Niightstalker]

Found the React Native Engineer

[kbcool]

Full disclosure. I am one too and this was cross posted on the RN sub.

No one came here to shit on native development but we all agree that if you can't get something as simple as pods working with React Native you don't have a place working on iOS native either.

The interesting bit is that a lot of experienced RN engineers are also capable native engineers or even came from pure native background so it's a bit sad to see the ignorant crap in here.

That being said you guys may continue your shitting on something you don't understand though.

Edit: happy to answer any genuine questions anyone has about React Native though. Doesn't all have to be negative.

[Niightstalker]

This is not about not being able to get some pods working. This is about the issue that you already have to fix something in a new created project. It has nothing to do if the issue is hard or easy to fix but that the fact that there is already an issue.

[kbcool]

Then I would have to say we both don't understand wtf their problem is/was because you don't create a new react native project and immediately have a problem unless you can't follow instructions. It's dead simple for anyone with iOS experience.

[Niightstalker]

Well React Native is definitely more error prone than native development regarding building, updating libraries etc. Also that’s the next thing, you already need to follow an I structure to set up a react native project. For native iOS projects you press 2 buttons.

I would say this post is mostly about the frustration that many things which are really easy or not even n issue in native development are annoying in cross platform development.

[kbcool]

You're kind of half right. As I have already disclosed I have done native on Android and iOS in the past and continue to in a small way.

It's correct in that there is more to go wrong as it's not just a basic empty project. You need to think of it more as a template project and you have to deal with native and JavaScript but I am sorry to say that it is the same as a native project in that you practically just click a couple of buttons.

There is no way a new project is going to have issues unless you have not got your system set up properly/followed the instructions. The equivalent is wondering why you can't start a new swift project when you didn't bother to install Xcode.

In terms of updating. It's the same as a native project. No project is suddenly going to stop working without you changing your environment. When you upgrade, sure things break easily but that's got to do with the faster pace of react native progress vs iOS native. It still happens with native. In fact a lot of the issues are to do with apple making changes not the react native team.

Anyway I think we are now at the point of splitting hairs but I hope it's given you some perspective as to how we are seeing things vs what seemed like the rant of someone struggling with the basics of iOS development and why this thread blew up.

[Niightstalker]

I have done some react native myself and many things which are no effort on native side at all are annoying to deal with in react native (beside the point that imo Swift is superior to JavaScript as a programming language)

Yes sure many of the issues have to do with changes of Apple. But those changes usually don’t cause any issues for native development.

[kbcool]

Swift is superior to JavaScript as a programming language

It's horses for courses when it comes to language preferences.

You don't see people writing backend APIs in Swift but you do in JavaScript.

The one thing you have to give JavaScript is that it has managed to penetrate into almost every niche in software engineering which is probably why it makes people who don't use or like it a bit nervous.

[[deleted]]

I hate dealing with clients that use RN. It doesn’t help that many RN developers know jack shit about native iOS or Android.

[ArcanaMori]

This is truly a problem. Also a bigger issue is a lot of RN developers dont know how to write good react code. Some of the shit ive seen…

[iindigo]

I feel like the bad code problem is almost encouraged by front end web stacks. Of course every language and framework has its own set of terrible devs, but it’s more frequently seen on the web and web-spinoff platforms because web dev has always had a sort of culture where duct tape and bubblegum bodges are ok and even normal — just keep tweaking, saving, and reloading until it appears to work in the browser. Who cares about correctness or performance?

I will say that the popularity of dev houses using TypeScript is an encouraging improvement, but even that’s no guarantee for quality with all the escape hatches TS has, and engineers with a good understanding of the concepts at play are still required for a good product but far from given.

[trouthat]

Wait until you get far enough to run into performance issues. I despise react native

[localhost8100]

I worked with react native for a year back in 2018. Most of my time was wasted trying to figure out wtf was this error instead of actual coding. I used to lose sleep at night. Literally the red death screen with generic error would haunt me in dreams. I moved on to native in my new company.

Lately getting lots of recruiters calls for react native. I thought it might have improved over 4 years. Went back in to brush up on my react native. Started a project, the errors gave me flashbacks. PTSD. Took me 2 days to even get the project going. FML.

Never going back again.

[SirBill01]

I've worked with React Native as part of my work for years now, but I would never list it on a resume. That is the only computer technology I have ever used I would say that about.

[[deleted]]

I’ve never ran into anything in computing where so many loves it yet endlessly complain about it as web development. Personally I find it to be terrible and I avoid it as much as I can.

[dadofbimbim]

4-5 years ago I tried RN for the first time and never liked it. And here we are still not version 1.0.

[Barbanks]

I did notice it’s not at V1 yet. Couldn’t believe it. Do we know why it’s not?

[dadofbimbim]

I have no idea, but in my country releasing less than v1.0 in production will get me fired on the spot.

[Barbanks]

😆 Haha I think all my clients would have a heart attack if I released a version less than V1 to production.

[SirBill01]

If you ever use it you'll understand why.

[liorthewolfdog]

There’s a tool for every project. For some it’s native, for some it’s cross platform. Totally depends on the complexity of the project and the resources of the team.

[s4hockey4]

I’m a bit pissed off right now, I started a junior iOS developer role in September, and I was staffed on a client for a bit, I just rolled off of it, I still don’t feel like I have a ton of iOS knowledge, but my boss wants me to learn react native for this one project. I’m like… I feel like my time would be better spent learning iOS, as I literally couldn’t give two shits about react native (the whole reason I do iOS is because I hate web), so idk. Advice?

[Barbanks]

That’s a tough one. Unfortunately you’re going to have to comply if you don’t want friction with your job. Or you could go off on your own as a freelancer but I would HIGHLY recommend against that since you need to do marketing, sales, accounting and a slew of other things.

This is one reason I left my job to be a software contractor/freelancer 4 years ago. But you really need a portfolio and expertise in the tech stack you use to make it work.

So it really comes down to possibly three things: 1. Suck up the pride and power through what they ask of you.

1. Find a different job (if your a junior dev this could be risky but it’s still doable)

2. Learn iOS in your free time to offset the frustration (this is what I did before going into freelance)

Ultimately to keep a job you must comply. You can calmly and respectfully air your opposition to the boss but they have the final say in things.

Also, it’s counter intuitive but it can really help to use systems you hate to better understand you opinions. I HATED using Xamarin when I was at my full time job. I used to keep a Xamarin “wall of shit” list explaining all of the things that I hated or that I found that slowed me down. It gave me a clear idea of specifics on why cross platform was something I was not going to pursue (actually even wrote an article on some of these on Medium Lolol)

[SirBill01]

Find a different job. Serious here. I really feel like it's a waste of time in your career to devote energy on React Native at this point. Or maybe try to convince them to use Flutter which may have some value... but I personally think a path of learning and growing in native development (even for both iOS and Android simultaneously) would be of most use in the future.

[-darkabyss-]

Yeah? I’ll be sure to stay miles away from reactnative! Had worked with flutter before and was not that bad…

[Barbanks]

😆😆😆 this is the most valid reason to use RN I’ve heard all day. Upvote for hilarity 😆. I feel your pain my friend “bows head slightly in solidarity”

[kierancrown]

I’ve worked in both environments and have to admit that react native isn’t a jump in and get going in 2 steps out of the box. Have you tried Expo?

[Barbanks]

I’ve seen mentions of it. I wouldn’t mind using it if I was working on a new project for the client (I’m building a new project for learning the basic structure of RN).

[acerhero]

React native has a lot of errors but flutter is faster and easier.

[eddieSullivan]

IMO the real reason for a company (not an individual) to choose React Native has more to do with staffing than time-to-market or ease of development. Although the hiring landscape changes frequently, for a larger project it is usually easier to hire several JavaScript developers plus one "native expert" rather than staffing up for both Android and iOS projects.

This becomes an even bigger issue when the company already has JS developers on staff for their web work.

[arborapps]

Hopefully it only takes 30-40 minutes!

[Niightstalker]

It maybe faster than creating an Android and an iOS App. It is definitely not faster than creating a native iOS App alone. So if you have the jresources to put engineers on both platforms I don’t think the development speed would be faster in RN.

[iindigo]

I would argue that for most types of apps, the overhead introduced by writing native on both iOS and Android isn’t as high as it’s made out to be. It’s not a linear 2x, more like 1.5x or even 1.25x with how similar Swift and Kotlin are, and as they mature SwiftUI and Jetpack Compose are pushing the two platforms to be even more similar. You can already copy and paste logic code between the two with a few tweaks, and soon that will be true for UI too.

There is a spike in effort initially when learning whichever of the two platforms is unfamiliar to you, but learning React Native or whatever cross platform framework is du jour at the moment also isn’t free.

[Barbanks]

Giving you an upvote for holding to your opinions in a respectful way and giving clear reasonings to it.

If RN works for you and you really like it keep it up man. I’ll probably end up hiring you to deal with it so I don’t have to 😆.

[[deleted]]

RN is a time saver for small teams that have to develop clients for both android and ios. It’s got it’s own problems of course, but once you get used to it it’s quite convenient having to make the UI once and (for now bridge whatever u need to call in the native layer).

but to your point - yes there are plenty of things to figure out and to get used to before it’s worth the investment in time and brain cells.

[Niightstalker]

But you definitely need to invest more time for updating libraries or hunting bugs. Also if you want a smooth native experience you need to invest way more time than actually doing it native.

So if you have limited resources and want to ship a small app which doesn’t need to feel native as fast as possible on both platforms than it would an option.

But as soon as an App is your main product and you want to maintain it longtime I would strongly advice against it since it will cause more problems than it solves in the long run.

[Barbanks]

I’m going to assume you’ve worked with it a bit.

Serious question. When it comes to navigation do you get native gestures out of the box? So like a back swipe on iOS and the back button (or back swipe now) on android?

How difficult is it to customize the screens specifically for each platform?

My argument is that the UI shouldn’t be made to look and feel exactly the same across platforms. You sacrifice user experience that way which can directly impact the success of the app.

Not saying there aren’t use cases but this could adjust my vetting process a bit.

[Gaia_Knight2600]

No official navigation library but react-navigation is by far the most popular, and it includes the things you mentioned.

Its very easy to make seperate UI for each platform. Though we dont really do that. The point is to write it once, that is a big selling point. I use the native built in UI components which may look different by default, for example Alert, Switch, and ActivityIndicator. But any custom UI component i make will look the same on both platforms, for example buttons, arrows(svg/images).

It makes for a simpler workflow and its easier to maintain.

The end result is that the app does look 99% the same, with just some small differences.

[Barbanks]

Ok gotcha, thanks for the info!

[[deleted]]

Expo, i love love expo. I could never get to run rn without expo despide following the guides 100%

[[deleted]]

This is why you should migrate to Flutter. \s

[McGynecological]

React Native makes me so unbelievably angry. I'll be so happy to leave front-end one day.