[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.