5 ms·

Yes, we regret it. Our app is just a wrapper around a webview, and handles things like in-app payments and SDK integrations like Facebook login, in a team of ~1

Yes, we regret it. Our app is just a wrapper around a webview, and handles things like in-app payments and SDK integrations like Facebook login, in a team of ~10. Our version of React Native is quite far behind which makes using libraries not already in the project difficult: you have to track back through versions to find a compatible version, which then may not be doing what you want since it's an older version. We're also having trouble upgrading the version of React Native due to versions having breaking changes. I know it's technically still not v1.0, but in reality a lot of companies are using it so having a stable version would be nice. Since it's unstable, many libraries haven't updated to compensate so you run into the same problem as above, tracking down precise versions of dependencies which also still do what you want. The build process feels pretty rickety and seems to rely on a lot of global state - I spent a while checking how we could update dependencies, but when I rolled back to a stable version I was unable to build even after re-installing node modules etc. I was only able to fix it after opening Xcode, removing all pod libraries and re-adding them; I have no idea why that worked, and there are very few clues on Github or Stack Overflow as to what specific errors mean. Fixing my build step took the best part of a day. Overall, for a small app like ours, we're just spending far too long on non-development overhead, like fixing build systems or checking dependency versions, and will probably move to native versions at some point in the future. It may be a pain maintaining two separate versions, but we'll have solid integrations with payment gateways and lots of documentation and info on Github/SO for problems. I like React and the idea of React Native, but at the moment it just feels far too unstable and unpolished to use. I'd like to use it in the future, but probably not until it's had a major version release.

woah 9y ago
Why are you using RN if your app is just wrapping a web view?
- johnwheeler 9y ago
  If you have to ask questions like this, you haven’t been working in the industry long enough.
  - jnbiche 9y ago
    It's a reasonable question. It's not clear how much interactivity is required outside of the webview, but if there's very little or none, then it would be perfectly reasonable and simple to use the native mobile APIs to wrap the webview. And thus avoid all the problems mentioned above.
    - whostolemyhat 9y ago
      Yep, that's our long-term plan, but saying we want to get rid of our working app and re-write it as two new apps from scratch doesn't go down particularly well with the business.
  - gt_ 9y ago
    Haven't been in the industry long enough to do what? Ask questions? It appears you have been working in the industry too long to answer them, which is much worse.
    - libria 9y ago
      > Haven't been in the industry long enough to do what? Ask questions? To be jaded. It's merely a jab at the way we tend to overcomplicate solutions to simple problems. I think.
      - johnwheeler 9y ago
        Yes, that’s right
  - websitescenes 9y ago
    I was wondering the same thing. It seems like the this may be a case of choosing the wrong tool for the wrong job. Some clarification around the context of the problem could eliminate that possibility. Seems like a fair question.
  - SCdF 9y ago
    OK. Let's say that's completely true. Is snarkily telling someone they're not good enough helpful? Seems like a moment where you could share what you know (as someone, presumably, has been in the industry long enough) and help someone. (FWIW it sounds like a decent question to me: but then again undoubtedly I have not been in the industry long enough!)
- ballenf 9y ago
  A different way to ask that would be, if it's just a webview why not strip out RN instead of struggling with breaking change upgrades?
- muse900 9y ago
  On top of that my question to the OP would be, why do they need to search around for libraries that are older than RN. In a team of 10 you can most likely create your own ones, or fork already made libraries and upgrade them to fit your purpose. One of the greatest things with RN so far for my team has been that we can actually write native components and bridge them. Yes RN is changing quite fast in general and most libraries out there might not fit your exact purpose, but I find it quite easy to integrate what I need in our app. (Team of 3, been on production for 8 months, its pretty alright so far)
  - whostolemyhat 9y ago
    The main problem we're having is that newer versions of RN use React 16. React 16 has breaking changes, particularly the changes to PropTypes and createClass, which some of our dependencies have already fixed but others haven't. This means to upgrade RN, we need to either submit fixes for all these libs or use a version of RN which still uses React 15, both of which have their own problems, especially since React 16 is still a release candidate and not a full release. We're not creating our own libraries for a couple of reasons: firstly, this was supposed to be a quick project to see if an app is viable (but has now lasted long enough that we've run into this issue), and secondly we've already got forks of key libraries, which is taking more time away from implementing actual features since we now need to maintain them and pull in updates from the original repos. Yes we should have kept dependencies up-to-date, but constant breaking changes are just taking too much time away from development time, so it's not a good fit for our project as it stands.
    - muse900 9y ago
      Imho, I think you got it wrong here. I don't think you are supposed to make a production RN app out of the bat, by just using 3rd party dependencies. RN isn't wordpress where someone can employ you and say I want this and that and then you go off install 50 plugins and thats it, your project is completed. If you are installing a lot of RN 3rd party dependencies for a production environment then you are doing it wrong. The best thing RN has to offer is being able to write React for parts and write Native code for heavy tasks. You do need to go down and write your own components natively, sure if someone has done it before and its well maintained and you tested it and works for you then fine use that library, if not then don't install it but make your own. For js components only components, then again if its very well maintained then use it, but nothing stops you for making the component that works for you. RN is a bit less work than writing a Native app, but not too far apart. It's not meant to be for webviews and for people that just want to make a complex production app using 3rd party dependencies in very little time. Its meant for dev teams that JS is their main language but do have someone that has an understanding of native code.
- whostolemyhat 9y ago
  In-app payments and integration with Facebook login, Stripe, Apple subscriptions etc. It was in the first sentence ;)
- todd3834 9y ago
  When using RN with a web view you can easily communicate with RN using the postMessage API. From there, you can use RN for all of the native specific functionality. Most of the "native" code is shared between ios and android at that point. If you only need to support iOS then this is less valuable. This is the reason why things like Cordova exist. However, I find the communication between webviews and RN far more enjoyable to using Cordova + plugins.
antoniuschan99 9y ago
Sounds like Ionic is a better solution for your app.

woah 9y ago

Why are you using RN if your app is just wrapping a web view?

johnwheeler 9y ago
If you have to ask questions like this, you haven’t been working in the industry long enough.
- jnbiche 9y ago
  It's a reasonable question. It's not clear how much interactivity is required outside of the webview, but if there's very little or none, then it would be perfectly reasonable and simple to use the native mobile APIs to wrap the webview. And thus avoid all the problems mentioned above.
  - whostolemyhat 9y ago
    Yep, that's our long-term plan, but saying we want to get rid of our working app and re-write it as two new apps from scratch doesn't go down particularly well with the business.
- gt_ 9y ago
  Haven't been in the industry long enough to do what? Ask questions? It appears you have been working in the industry too long to answer them, which is much worse.
  - libria 9y ago
    > Haven't been in the industry long enough to do what? Ask questions? To be jaded. It's merely a jab at the way we tend to overcomplicate solutions to simple problems. I think.
    - johnwheeler 9y ago
      Yes, that’s right
- websitescenes 9y ago
  I was wondering the same thing. It seems like the this may be a case of choosing the wrong tool for the wrong job. Some clarification around the context of the problem could eliminate that possibility. Seems like a fair question.
- SCdF 9y ago
  OK. Let's say that's completely true. Is snarkily telling someone they're not good enough helpful? Seems like a moment where you could share what you know (as someone, presumably, has been in the industry long enough) and help someone. (FWIW it sounds like a decent question to me: but then again undoubtedly I have not been in the industry long enough!)
ballenf 9y ago
A different way to ask that would be, if it's just a webview why not strip out RN instead of struggling with breaking change upgrades?
muse900 9y ago
On top of that my question to the OP would be, why do they need to search around for libraries that are older than RN. In a team of 10 you can most likely create your own ones, or fork already made libraries and upgrade them to fit your purpose. One of the greatest things with RN so far for my team has been that we can actually write native components and bridge them. Yes RN is changing quite fast in general and most libraries out there might not fit your exact purpose, but I find it quite easy to integrate what I need in our app. (Team of 3, been on production for 8 months, its pretty alright so far)
- whostolemyhat 9y ago
  The main problem we're having is that newer versions of RN use React 16. React 16 has breaking changes, particularly the changes to PropTypes and createClass, which some of our dependencies have already fixed but others haven't. This means to upgrade RN, we need to either submit fixes for all these libs or use a version of RN which still uses React 15, both of which have their own problems, especially since React 16 is still a release candidate and not a full release. We're not creating our own libraries for a couple of reasons: firstly, this was supposed to be a quick project to see if an app is viable (but has now lasted long enough that we've run into this issue), and secondly we've already got forks of key libraries, which is taking more time away from implementing actual features since we now need to maintain them and pull in updates from the original repos. Yes we should have kept dependencies up-to-date, but constant breaking changes are just taking too much time away from development time, so it's not a good fit for our project as it stands.
  - muse900 9y ago
    Imho, I think you got it wrong here. I don't think you are supposed to make a production RN app out of the bat, by just using 3rd party dependencies. RN isn't wordpress where someone can employ you and say I want this and that and then you go off install 50 plugins and thats it, your project is completed. If you are installing a lot of RN 3rd party dependencies for a production environment then you are doing it wrong. The best thing RN has to offer is being able to write React for parts and write Native code for heavy tasks. You do need to go down and write your own components natively, sure if someone has done it before and its well maintained and you tested it and works for you then fine use that library, if not then don't install it but make your own. For js components only components, then again if its very well maintained then use it, but nothing stops you for making the component that works for you. RN is a bit less work than writing a Native app, but not too far apart. It's not meant to be for webviews and for people that just want to make a complex production app using 3rd party dependencies in very little time. Its meant for dev teams that JS is their main language but do have someone that has an understanding of native code.
whostolemyhat 9y ago
In-app payments and integration with Facebook login, Stripe, Apple subscriptions etc. It was in the first sentence ;)
todd3834 9y ago
When using RN with a web view you can easily communicate with RN using the postMessage API. From there, you can use RN for all of the native specific functionality. Most of the "native" code is shared between ios and android at that point. If you only need to support iOS then this is less valuable. This is the reason why things like Cordova exist. However, I find the communication between webviews and RN far more enjoyable to using Cordova + plugins.

antoniuschan99 9y ago

Sounds like Ionic is a better solution for your app.