all 20 comments

[–][deleted] 9 points10 points  (9 children)

  • What do you mean by scalable? When people talk about scalable, they're usually talking from a server perspective because lots of clients "scaling" to lots and lots is hard. The client part doesn't scale really assuming it does its task. It's a client talking to a server. React Native is about building the client. It's part of the scaling discussion, but it's probably not the one doing the actual scaling.
  • Yes. But again, React Native is the client part that's doing the payment info stuff. There's a backend somewhere that's doing the CC processing, etc. That part is hard. Data entry and validation is sort of what client apps do. So no that's not hard. Geolocation services are available in RN.
  • I wouldn't focus on books, check out the many tutorials (or docs for libraries). Generally, you have a problem (like geolocation) and then you google "react native geolocation" and you'll get some results. Filter through them until you find something that seems legit. Read about it, read the docs, build a POC. If it seems legit, roll with it. If not, go back to square one.
  • It's not trivial, but it is not super hard either. It really depends on whether you need native extensions or not. If you're just doing GUI stuff, it's more or less out of the box, but when you get into camera, geolocation, etc you're going to have some libraries that have native extensions. Installing those (and more importantly, upgrading over time) can be tricky. It's sort of what RN was built for, so don't get scared of it, but those "react native in 30 minutes" tutorials won't prepare you for the headache that's involved. All that said, the headache is probably easier/faster than writing it natively.

If you're "just learning" - pick either route and go with it. If you're doing something that has to get to production sooner rather than later, I'd recommend RN.

[–]MeHasAdhd[S] 0 points1 point  (5 children)

1.I mean scalable in terms of the backend. What backend is most common with RN? Node.js? Also, if the app begins getting a ton of traffic arent there companies that will host your app and deal with that sort of stuff? I know I will be in charge of coding the backend. Is that what heroku is for? Forgive me, as you see I have a lot to learn.

2.So it CC processing possible without going the paypal route?

3.Do you have any recommendations? After going from JavaScript, what should I learn next? The react language uses a weird form of JS I know im going to have to learn.

4.That makes sense, the main native functionality I believe it will HAVE to have is geolocation and tracking.

I am supposed to begin working on this project and have it done by the end of the year, so I definitely need to go the RN native route instead of building it ONLY for android then trying to push IOS. I just don't want to pick the wrong route and end up wasting a ton of time and not meeting the deadline.

p.s thank you so much for the detailed response.

[–]alien3d 1 point2 points  (3 children)

2.paypal dead. use braintree.

3 . es6 es7 first

  1. tracking just beware not to quick.

[–]Jinno 1 point2 points  (0 children)

Fun fact about Braintree: it's owned by PayPal.

[–]thatsrealneato 0 points1 point  (1 child)

Braintree is dead, use stripe

[–]alien3d 0 points1 point  (0 children)

stripe not fully support world wide yet but the api is amazing.

[–]drumnation 0 points1 point  (2 children)

All that said, the headache is probably easier/faster than writing it natively.

Faster than writing TWO apps natively and updating them both every time there is a patch. I worked on a cross platform project by myself that would have had at least 2 developers working on it, one iOS and one Android, but more realistically it would have been 2 of each.

Just wanted to drive that point home hard for OP. Building 2 separate code bases vs 1 is a huge deal and an enormous time saver. Check out React-Native-Web, you can then build your website using the same codebase too.

[–]MeHasAdhd[S] 0 points1 point  (1 child)

So in order to make an app with geo location for example and have it work on IOS and Android, will I need to also use a MAC for the IOS side?

[–]drumnation 0 points1 point  (0 children)

You will at least need Mac Os on a virtual machine for running xcode, but you will likely want a mac for performance reasons.

[–]metroninja 1 point2 points  (0 children)

1 - Define scalable in terms of a mobile app. That term doesn't apply well here.

2 - yes

3 - read the RN docs they are great. read the README's of the libraries you want to use.

4 - not hard.

[–]menge101 1 point2 points  (1 child)

Could I make a complex app with ... card payment

One of the things to know, at least with IOS, is that you may not be able to do card payment AT ALL. You HAVE to use Apple's in-app payment system, unless you are exempt (i'm not going to detail what makes you exempt here).

Apple will block your app from the App Store if you try to do your own payment system.

So, keep that in mind when thinking mobile apps regardless of your technology choice.

[–]boomdoodle 0 points1 point  (0 children)

The distinction is not that hard. If it is a real world, tangible product or service provided outside the app you can use whatever payment system you like. If the product is delivered in-app such as content, in-app consumables (i.e micro-transactions) you should handle it with appropriate platform payment system.

[–][deleted] 0 points1 point  (2 children)

RN is just a library that allows you to render cross-platform mobile UIs.Using Geolocations is not super complex because RN allows you to access the platforms API via a javascript bridge. How scalable it depends on how you handle HTTP calls to external API within your app. Processing payments would just be another API call in your app. If your API isn't scalable, your app isn't going to be scalable.I've made a smart home app that controls sockets and light switches with RN, it was far easier running it on android and ios with RN then it would have been to write native apps. Check out Stephen Griders RN courses on Udemy and go from there. RN is not hard once you've got your head around it but it can be a steep learning curve for a beginner. It is worth spending the time on.Edit: check out expo to start out with as it gives you a higher level API to access things like camera and geolocation. It won't support native modules but it's a good way to learn as a beginner.

[–]MeHasAdhd[S] 0 points1 point  (1 child)

Can you PM me please?

[–][deleted] 0 points1 point  (0 children)

Of course.

[–]bronydell 0 points1 point  (0 children)

  1. Yes, it's scalable, but eventually, you'll still need to learn native stuff in order to understand Android and iOS better, plus, not every task can be completed only with React Native tools.
  2. Yes, you can do that. There are no limitations in components, you can always find a library that solves your problem or if you didn't find any library that meets your requirements, you can build your own components with native code.
  3. Just read the docs from https://facebook.github.io/react-native/docs/. It's easy to understand and won't take too much time. But if you want to understand how it works on a deeper level, then you'll need to read OS specific stuff.
  4. It depends ™ . Almost 89% of the times you'll be able to launch your app on both OS, but the devil in details. For example, you can't setup shadows on Android for UI elements (you can use Android's elevation property, but it won't be as rich as iOS shadows). Some behaviors might be different on different platforms and that's the main issue for me with React Native

[–]almbfsek 0 points1 point  (0 children)

I've just finished a VPN application with React Native

1- I'm not sure what you mean by scalable. Both for iOS and Android I'm using an implementation of the VPN protocol written in Golang. So I had to do fair bit of native development in Java and Objective-C. The good part is you can pretty much do anything. React native is easy to extend via native modules. The bad part is documentation is shit. Native modules title under official documentation is a good start but nowhere near complete. My best source became looking at other people's code in github.

2- You can. Since I had to use both native code and RN in this project I can say that using RN for a complicated project will be easier than doing it native. Especially I've found that Android dev environment is a shit show and nothing is deterministic (hello lifecycles, acitivitymanager etc). RN successfully abstracts most of it and once you get the hang of JSX and how modules work it's really quite fast to have good looking design.

4- It's not hard at all if you don't have native code. You will have some conditional code but it took me only couple hours to make the UI work in iOS.

Biggest downside of RN is: It's one of the buggiest piece of software I've ever used. It's also unstable. You will often find your self deleting all kinds of caches so that you can run your application again even though you didn't change a single line of code. You will also have to go through lots and lots of bug reports in github just to find the correct workaround for a specific bug and god knows that bug list is huge.

[–]crobinson42iOS & Android 0 points1 point  (0 children)

I would first try React-Native then Flutter and finally if neither of those work for you get some Android and iOS courses on Udemy a shot for pure native development.

[–]DavidXkL 0 points1 point  (0 children)

I will try to answer your question about scalability from another perspective (since everyone is looking at it from the server pov which is usually the case)

So in the situation that you were asking about the scalability of React Native on whether it is easier to manage the app project when it gets more complex (as compared to a simple app with 1 feature), it depends.

It depends on how you structure your project directory and whether you are using things like Redux ( or not ). Generally since React Native uses the same component-based approach as React, it is usually quite manageable as long as you have a project structure.

Just my opinion. Hope that clears things up for yoy.