I watched the video on React Native which hit the front page of Hacker News the other day and remain pretty skeptical about the promises being made.
Having built both native iOS and Android experiences (as well as cross-platform applications in Cordova / Phone Gap and Flex 4), I am not sold that the key problems preventing developers from producing a truly unified codebase are likely to ever be solved completely in a “Learn Once, Deploy Anywhere” manner…There will nearly always be some level of customization required, Developers and designers will nearly always need to have direct knowledge of each platform target.
The obsession with attempting to streamline native mobile development is well-placed…I fully understand the pain involved in trying to manage Android and iOS development simultaneously…However, it is unlikely that React Native is going to be a “magic bullet.”
You can’t engineer native design patterns out of the equation
- You severely restrict design patterns on one or both platforms to avoid patterns which are not natively shared across all
- Make developers customize UI per platform (invalidating “Learn Once, Deploy Everywhere”)
- Provide *the exact same* experience on all platforms and avoid all native controls for any platform (e.g. something like Paper or FlipBoard)
Many applications opt for option 2. Lets take a look at some of the potential complications an x-platform native developer can run into.
UIPageViewController? Not in Android. UISplitViewController? Not in Android (though possible to approximate readily with List Fragments). Navigation Drawer? Not in iOS (without some hackery or inclusion of 3rd party libraries).
These are just a few examples, there are many others.
Tool Bar / Tab Bar / Action Bar Insanity
The Action Bar in Android behaves fundamentally different from it’s iOS equivalent(s). On Android, the Action Bar “splits” on mobile phones to spread options across the top and bottom of the phone screen. In “tablet mode,” the Action Bar occupies the title bar along with all it’s related menus, tabs and contextual actions (see above).
In iOS, replicating the behavior of this Action Bar construct would involve swapping and mix-matching three completely separate and functionally different components: UITabBar, UINavigationController and UIToolBar. If you add in a “Universal” iPad mode with a UISplitViewController, this becomes even more difficult (although probably less so since the iOS 8 update which allows UISplitViewController on iPhones).
Tab Bar goes on the bottom in iOS, on the top in Android
In iOS, the area directly under the navigation bar is reserved for UIToolBar (which contains contextual actions). In Android, the area under the title bar is where Tab Bar goes. In iOS, the area across the bottom of the screen is where UITabBar goes. In Android, contextual options from Action Bar (which would normally be placed in an iOS navigation or UIToolBar) feed across the bottom of the screen.
iOS (iPhone) does not have drop-down menus, Android does
The iPhone doesn’t have drop down menus, instead relying on pickers for contextual data selection, while Android uses drop down menus for navigation. Another way iOS exposes options it to give the user a slide-up modal dialog or action sheet. Neither are meant for navigation. iOS does, however, have pop-up menus which can live in the bottom right of a UITabBarController in the form of a moreNavigationController. Finally, the iPad has a control called UIPopoverController which can provide a drop-down of sorts when combined with a list view.
Closing thoughts: iOS and Android development speed
iOS, Android (and don’t forget Windows Phone) SDKs are massive in size. The rate at which they change is astonishing: Last WWDC, Apple introduce 4,000(!) new APIs. Thats just iOS, not even including Android (and don’t forget Windows Phone). These companies employ tens of thousands of busy engineers doing nothing updating them. As a result, React Native will likely always be behind the latest and greatest updates from Apple and Google.