[RubenSandwich]

As someone who was in your shoes last year as I made a job transition into a lead developer role at a new company. I picked React Native for a small project over Swift: https://studio.carnegiemuseums.org/out-loud-cdc979453ef0#.rh.... It was worth it. Not only because immutable render functions make view code extremely pleasurable to write, but also because it's mostly JS and JSX it allowed me to quickly spin up a web developer to work on this project with me. (About 2-3 weeks.)

Now React Native is not without it's downsides though. You pretty much have to know the platform underneath if you want to do anything past API calls and rendering to a list view. (And even that list view does not support the heavy recycling that iOS manages for you.) For the above project I had to write our own Bluetooth, Audio and Accessibility Native Modules.

But the speed at which we were able to develop over a native solution was worth it alone. I highly suggest looking into React Native if your next project is simple enough.

[LeoNatan25]

Looking at https://github.com/CMP-Studio/TheWarholOutLoud, I see that you only support iOS. Any particular reason for that? Seeing as you have chosen React Native, why have you not used the number one feature, which is cross-platform development?

Often I see people touting "cross-platform development", but then, in practice, one platform always gets priority, and when it comes to support the other, a lot of the view code has to be rewritten. How much of an effort do you reckon would be required for this app to support Android?

If only iOS was the only target, why did you go through the RN hoop, when Swift would be much more natural?

[RubenSandwich]

Sure. The project only had to support iOS, our research shows that about 70% of this museum's goers use iOS devices. So MVP; iOS first.

I wouldn't list "cross-platform development" development as the most important feature to me. If that is the case then I would just as easily used Ionic or Cordova which are far more stable then React Native currently is. Rather it was a combination of things that got me to use React Native for a project:

1. Redux - Single direction data flow 2. React - Pure render functions 3. Ease - Both easier to learn/use and faster iteration times vs. Native.

This project was honestly a testing ground for React Native for my team and it was a small project that if we decided to we could switch to natively without too much of a time hit. We fell in love with pure render functions and single directional data flow and it would be hard to go back to MVC-like architectures. (Yes their are libraries for that for Native platforms but not with the same ecosystem and community behind them as React Native has.)

As for how hard would be to port over? I'd say we would could keep all the logic and would have to redo 40 - 50% of the UI for Android. Which is higher then it would be now because when we started navigation in React Native was the wild west so we dropped into a Native solution.

Our next project however is a cross platform React Native app, which we hope to release by the end of this month. This app shares about 80% - 85% of the code between platforms. We also believe as a team to making apps feel native to their platform so Tab Bars on iOS and hamburger menus on Android, which is why our numbers are lower then other apps that use their own branded UI vs. platform UI.

[tuxracer]

FYI Tab Bars are now recommended by Google for Android as well http://www.androidauthority.com/bottom-navigation-material-d... There is a lot of data that shows hamburger menus create big discoverability issues and Google highly discourages uses them now.

So if anything the general layout of an iOS app would meet the latest Android Design Guidelines quite well. There may be certain "iOSy" things left like very blurry backgrounds but overall there's little reason to have a different UI layout across platforms at this point.

[LeoNatan25]

I think the main issue is that since the Android guidelines have changed so many times in a short period of time, it makes it very confusing to follow the latest ones. Add on top of that even Google's own apps fail at following some of the most established Material Design guidelines, it is very difficult to have proper examples to look at when trying to design an Android app.

[tuxracer]

That's very true Google has never been as disciplined when it comes to design guidelines. But aside from purity to specific guidelines there is a lot of data that show hamburger menus are death for discoverability of whatever is tucked away in them. Google has been slowly moving away from that direction for years first with the removal of the hardware menu button. As far as tabs go, having tabs, and on the bottom, is tremendously helpful especially on larger screen devices. All things Apple has likely known all along and hence their original design guidelines that Google seems to be adopting more and more of over time.

[cageface]

React Native is so much nicer for building and iterating on layouts and styles it's almost worth considering the switch for that alone. Hopefully Apple is watching and will steal some of the best workflow benefits for some future version of Interface Builder.

[Eridrus]

> I had to write our own Bluetooth, Audio and Accessibility Native Modules

I hope you open sourced these :)

I was looking at React Native the other day and the impression I got was that almost every piece that does more than display data from the web needed extra modules and far from all of them were written already.

[LeoNatan25]

This is true. Some great ones exist (like https://github.com/airbnb/react-native-maps and https://github.com/wix/react-native-navigation), but those are few and far between. Most are very simplistic and only solve very narrow cases. So you end up having to do a lot of the work yourself, for both platforms. And that is a big chore, as there is a lot of boilerplate to integrate native components with RN.

Disclaimer: react-native-navigation is developed by Wix, my employer, but I have not worked on that one.

[RubenSandwich]

Sure did: https://github.com/CMP-Studio/TheWarholOutLoud/blob/master/i.... See also CMSAccessibilityManager and CMSBeaconManager. They are not listed as packages on npm though because by the time we shipped the way to construct Native Modules had changed in the latest React Native. :/

[huangc10]

Can you share how big your team is and how many people were proficient in which languages? thanks!

[RubenSandwich]

Sure. This particular project was 2 engineers working about 4 months from concept to shipping. One engineer had done iOS development since iOS 5 and was familiar with Swift and Obj-C and only vaguely familiar with JS, React and Redux. The other engineer came from a web background using mostly Angular 1.x and jQuery with no native mobile development experience.

Edit: 4 months because many novel solutions needed to be developed. Particularly a coarse indoor location that uses iBeacons and works without internet access and a statistics based learning audio player that alters content order based on what you have previously listened to.

[huangc10]

thanks! I can see these type of hybrid teams becoming more and more common.