6 ms·

We have a 15-person engineering team and converted our mobile app to React Native at the beginning of this year. We do not regret it. Our pace of delivery is mu

We have a 15-person engineering team and converted our mobile app to React Native at the beginning of this year. We do not regret it. Our pace of delivery is much faster with React Native than what we were able to achieve building natively. Our app has over 100 screens, and only needing to implement features once to have them on both platforms is nice. The feedback loop when making code changes is much faster, especially when writing unit tests. There are some rough edges, but the benefits far outweigh the costs for us. Our iOS app: https://itunes.apple.com/us/app/root-car-insurance/id1021256908?mt=8 https://itunes.apple.com/us/app/root-car-insurance/id1021256... Our Android app: https://play.google.com/store/apps/details?id=com.joinroot.root&hl=en https://play.google.com/store/apps/details?id=com.joinroot.r...

g00gler 9y ago
How do you manage 100+ screens? I started building a react native app but decided against it because switching activities seemed to be very hacky compared to native development. Seemed like it'd really get out of hand with 10+ screens. Wix's "React Native Navigation" was too opinionated / inflexible.
- chrisco255 9y ago
  The best nav experience I've had with RN is React Navigation: https://reactnavigation.org/ https://reactnavigation.org/
  - g00gler 9y ago
    Looks very good, will have to try it out.
  - danpalmer 9y ago
    I've had an ok experience with React Navigator, but still feels very immature (I was unable to implement relatively straightforward animations on the parent view in a transition), and it also feels like interface builder/storyboards leaves it in the dust in terms of wiring together interfaces and getting a high-level overview of the information architecture of an app.
  - cheapsteak 9y ago
    How does it compare with react-native-navigation? Kind of difficult to parse the adoption/ecosystem based on download trends[1] for these two [1]: https://i.imgur.com/etEa7WT.png https://i.imgur.com/etEa7WT.png
    - htormey 9y ago
      I recently gave a talk at Chain React in Portland (first ever React Native only conference) where I compared these two nav stacks: https://www.youtube.com/watch?v=kFyaj5HmMEY&t=1059s https://www.youtube.com/watch?v=kFyaj5HmMEY&t=1059s The situation with navigation and React Native is a bit of a mess right now. Basically all navigation stacks can be broken down into two categories, those that are native (i.e built on top of the OS's existing navigation stack) and those that are not (pure javascript, emulates what the native stack does). Examples of Native navigation stacks: -> React Native Navigation (wix) -> Native Navigation (Airbnb) Examples of Javascript navigation stacks: -> React Navigation -> React Native Router Flux -> React Router Native An example app I wrote with React Navigation + Redux: https://github.com/hgale/ReactNavigationDemo https://github.com/hgale/ReactNavigationDemo Same app but built with React Native Navigation + redux: https://github.com/hgale/ReactNativeNavigationDemo https://github.com/hgale/ReactNativeNavigationDemo The main differences are that the native nav stacks have better performance, stuff like accessibility works right out of the box and they work the same way that the underlying native system works. The main downside to using Native navigation stacks right now is that setting then up & upgrading them can be a real pain. It can also require native knowledge when things go wrong. I would recommend staying with react navigation (Javascript based nav stack) unless you absolutely need some feature from one of these native nav stacks. It's going to be a lot easier to upgrade and you won't run into issues doing over the air updates with your production apps. It's also the one that Facebook promotes in their docs: https://facebook.github.io/react-native/docs/navigation.html https://facebook.github.io/react-native/docs/navigation.html Right now both React Native Navigation and React Navigation are under heavy development. No matter which one you choose, budget for some pain in the next year when upgrading.
      - danudey 9y ago
        I would think that having to learn a little about iOS/Android would be a small price to pay for decent performance and accessibility. The idea that those are only sometimes important rather than a necessity is alien to me as a software developer and as a user.
- dean177 9y ago
  I found quite the opposite, it's much easier to manage many activities, I am guessing you were using your own 'routing'? Take a look at react-navigation or react-router (it supports react-native too)
  - g00gler 9y ago
    I was looking for libraries that use native code but react-native-navigation was too opinionated and Air BnB's solution wasn't and isn't production ready. I pretty much put the project down after that and started learning Swift (I already do Android). Now I decided to go all out on iOS dev with the hope of making a career change from web.
- JohnHaugeland 9y ago
  One control per screen It's actually quite easy
andrethegiant 9y ago
Do you share any of your code base with a web app?
- dan_manges 9y ago
  We don't right now. We're a car insurance carrier that uses our mobile app to gather data as people drive. Since all of our customers have our app installed, we haven't looked to building a web app version yet. Although we could reuse some logic on the web, the overlap would be minimal. Most of the code is centered around the UI, and a web app would likely have a very different interface. It would be nice to share some business logic functions, although we tend to not put much of that in the client anyway. Most of it happens server-side, with client hitting APIs to check business rules.
snarfy 9y ago
It benefits your dev team, but does it benefit your customers? How's the battery usage of your RN app vs a real native app? Does your app require the latest phone hardware to run with decent performance?
- sodawater 9y ago
  Forget features or rates - snarfy chooses car insurance because their app uses less battery and is _buttery_ smooth.
- GBKS 9y ago
  As one of the designers of this app, I was skeptical initially if there would be restrictions on customizing common UI components, the smoothness of animations/interactions, usability, performance, etc. You definitely have to put in a bit of extra work (isn't that always the case with making things nice though), but you can get very nice results (and battery usage) with RN for sure on both Android and iOS. Personally, I think it does benefit customers to be able to quickly roll out iterations across operating systems at a high quality. YMMV though, what works for one team, industry and customer base naturally doesn't automatically work for everyone. Do you maybe have experience or data points on RN vs. native in terms of battery usage and performance? Would love to hear any insights you can share. Thanks.
  - snarfy 9y ago
    One of the reasons I brought this up was a recent article about energy efficiency of programming languages.[1] JavaScript is ~2x less energy efficient than Java, so it will eat twice the battery. [1] https://sites.google.com/view/energy-efficiency-languages/results https://sites.google.com/view/energy-efficiency-languages/re...
    - b_t_s 9y ago
      "so it will eat twice the battery" may be nearly true on headless boxes running CPU heavy workloads. Mobile apps are about as far from that as you can possibly get. Sure it's probably a measurable impact, but I would expect it's less of an impact than things like how bright the backlighting is, whether you keep GPS usage to a minimum, how well you minimize and batch network communication, etc, etc. CPU is a small part of a phone's power budget and mobile apps spend a lot of time with the cpu largely idle.

g00gler 9y ago

How do you manage 100+ screens? I started building a react native app but decided against it because switching activities seemed to be very hacky compared to native development. Seemed like it'd really get out of hand with 10+ screens. Wix's "React Native Navigation" was too opinionated / inflexible.

chrisco255 9y ago
The best nav experience I've had with RN is React Navigation: https://reactnavigation.org/ https://reactnavigation.org/
- g00gler 9y ago
  Looks very good, will have to try it out.
- danpalmer 9y ago
  I've had an ok experience with React Navigator, but still feels very immature (I was unable to implement relatively straightforward animations on the parent view in a transition), and it also feels like interface builder/storyboards leaves it in the dust in terms of wiring together interfaces and getting a high-level overview of the information architecture of an app.
- cheapsteak 9y ago
  How does it compare with react-native-navigation? Kind of difficult to parse the adoption/ecosystem based on download trends[1] for these two [1]: https://i.imgur.com/etEa7WT.png https://i.imgur.com/etEa7WT.png
  - htormey 9y ago
    I recently gave a talk at Chain React in Portland (first ever React Native only conference) where I compared these two nav stacks: https://www.youtube.com/watch?v=kFyaj5HmMEY&t=1059s https://www.youtube.com/watch?v=kFyaj5HmMEY&t=1059s The situation with navigation and React Native is a bit of a mess right now. Basically all navigation stacks can be broken down into two categories, those that are native (i.e built on top of the OS's existing navigation stack) and those that are not (pure javascript, emulates what the native stack does). Examples of Native navigation stacks: -> React Native Navigation (wix) -> Native Navigation (Airbnb) Examples of Javascript navigation stacks: -> React Navigation -> React Native Router Flux -> React Router Native An example app I wrote with React Navigation + Redux: https://github.com/hgale/ReactNavigationDemo https://github.com/hgale/ReactNavigationDemo Same app but built with React Native Navigation + redux: https://github.com/hgale/ReactNativeNavigationDemo https://github.com/hgale/ReactNativeNavigationDemo The main differences are that the native nav stacks have better performance, stuff like accessibility works right out of the box and they work the same way that the underlying native system works. The main downside to using Native navigation stacks right now is that setting then up & upgrading them can be a real pain. It can also require native knowledge when things go wrong. I would recommend staying with react navigation (Javascript based nav stack) unless you absolutely need some feature from one of these native nav stacks. It's going to be a lot easier to upgrade and you won't run into issues doing over the air updates with your production apps. It's also the one that Facebook promotes in their docs: https://facebook.github.io/react-native/docs/navigation.html https://facebook.github.io/react-native/docs/navigation.html Right now both React Native Navigation and React Navigation are under heavy development. No matter which one you choose, budget for some pain in the next year when upgrading.
    - danudey 9y ago
      I would think that having to learn a little about iOS/Android would be a small price to pay for decent performance and accessibility. The idea that those are only sometimes important rather than a necessity is alien to me as a software developer and as a user.
dean177 9y ago
I found quite the opposite, it's much easier to manage many activities, I am guessing you were using your own 'routing'? Take a look at react-navigation or react-router (it supports react-native too)
- g00gler 9y ago
  I was looking for libraries that use native code but react-native-navigation was too opinionated and Air BnB's solution wasn't and isn't production ready. I pretty much put the project down after that and started learning Swift (I already do Android). Now I decided to go all out on iOS dev with the hope of making a career change from web.
JohnHaugeland 9y ago
One control per screen It's actually quite easy

andrethegiant 9y ago

Do you share any of your code base with a web app?

dan_manges 9y ago
We don't right now. We're a car insurance carrier that uses our mobile app to gather data as people drive. Since all of our customers have our app installed, we haven't looked to building a web app version yet. Although we could reuse some logic on the web, the overlap would be minimal. Most of the code is centered around the UI, and a web app would likely have a very different interface. It would be nice to share some business logic functions, although we tend to not put much of that in the client anyway. Most of it happens server-side, with client hitting APIs to check business rules.

snarfy 9y ago

It benefits your dev team, but does it benefit your customers? How's the battery usage of your RN app vs a real native app? Does your app require the latest phone hardware to run with decent performance?

sodawater 9y ago
Forget features or rates - snarfy chooses car insurance because their app uses less battery and is _buttery_ smooth.
GBKS 9y ago
As one of the designers of this app, I was skeptical initially if there would be restrictions on customizing common UI components, the smoothness of animations/interactions, usability, performance, etc. You definitely have to put in a bit of extra work (isn't that always the case with making things nice though), but you can get very nice results (and battery usage) with RN for sure on both Android and iOS. Personally, I think it does benefit customers to be able to quickly roll out iterations across operating systems at a high quality. YMMV though, what works for one team, industry and customer base naturally doesn't automatically work for everyone. Do you maybe have experience or data points on RN vs. native in terms of battery usage and performance? Would love to hear any insights you can share. Thanks.
- snarfy 9y ago
  One of the reasons I brought this up was a recent article about energy efficiency of programming languages.[1] JavaScript is ~2x less energy efficient than Java, so it will eat twice the battery. [1] https://sites.google.com/view/energy-efficiency-languages/results https://sites.google.com/view/energy-efficiency-languages/re...
  - b_t_s 9y ago
    "so it will eat twice the battery" may be nearly true on headless boxes running CPU heavy workloads. Mobile apps are about as far from that as you can possibly get. Sure it's probably a measurable impact, but I would expect it's less of an impact than things like how bright the backlighting is, whether you keep GPS usage to a minimum, how well you minimize and batch network communication, etc, etc. CPU is a small part of a phone's power budget and mobile apps spend a lot of time with the cpu largely idle.