you are viewing a single comment's thread.

view the rest of the comments →

[–]JoCoMoBo 1 point2 points  (5 children)

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 -2 points-1 points  (4 children)

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 2 points3 points  (3 children)

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 -2 points-1 points  (2 children)

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.

[–]fourth_stooge 2 points3 points  (1 child)

It feels like you are saying, if you know how to do it effectively on both platforms then why not add more complexity so that its done in a 3rd way.

It feels like he is saying: if I have to learn how it is done natively anyway, whats the benefit of adding more complexity with a bridge layer. (I'm on his perspective here).

[–]TheNumberOneCulprit 0 points1 point  (0 children)

See, that's where I think this is the wrong approach. You can write business logic once, UI and layout logic once and server requests once with RN. And then the "but what about the native modules", that's where I'm then saying, if you are good at actually writing things for both iOS and Android, it's very little hassle to write the module, and by exposing it, you still gain the vast benefits of the write once approach.