|
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 have been solved ( or are likely to ever be solved in a write once or learn once, deploy everywhere model ). 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 and all the suffering caused by having two different apps…but React Native isn’t going to alleviate the key problems which cause this to be so painful for most developers. I will try to demonstrate below why, no matter what, mobile designers and developers are going to need to have (perhaps significant) platform-specific education in native constructs if there is any expectation of being able to “Write Once, Deploy Everywhere.” This knowledge requirement is likely going to invalidate “Learn One, Deploy Everywhere” despite it’s promise. Sorry . Time to take off your propeller-hat and think about usersThe problem with the native mobile cross-platform obsession is that it is an engineering obsession not rooted in the best interests of users . While Facebook may be able to address the problem from a engineering standpoint, the ultimate result is not going to be a pleasing to users ( something which Facebook struggles against mightily on mobile ). Users selected their chosen mobile device for a reason and expect ( even deserve to have) a certain set of user experience patterns. Presenting users with broccoli when they wanted steak is going to piss them off. You can’t engineer native design patterns out of the equationI hate to use the word “can’t” when talking about software. Software allows impossible things to be done. However, in this case I feel we have a “can’t” situation. Here is why React Native is probably going to fail to accomplish its goal. Are you ready? Platform specific design patterns . Yup. Android and iOS (and Windows Phone…) have fundamentally different design guidelines backed by completely different sets of native UI controls which are going to make “write once, deploy everywhere” difficult to truly deliver, just as they make “design once, deploy everywhere” a non-starter ( unless you favor the route of designing an application which largely ignores all platform specific design patterns which then limits you to building Paper or FlipBoard over and over again ). The interface you write for iOS will not directly translate to Android without (a) possessing sufficient working knowledge of both Android vs iOS design patterns to allow you to customize such a design to either platform manually or (b) severely restricting design patterns on one or both platforms to avoid patterns which are not natively shared on both platforms or (c) providing janky 3rd party support for non-native patterns across native iOS and Android to force them to be the same. Don’t even get me started about adding Windows Phone into that mix… This brings us back to my first point about respecting user choice:
Providing a crappy experience for users of all platforms to make engineering easier is not a good solution. Design patterns are rigidly backed by native UX frameworksDesign guidelines are not just pretty words on paper, they are “hard coded” into Android, iOS and Windows Phone. Google, Apple and Microsoft built their native mobile frameworks to work in very specific ways. These patterns are often rigid in nature or ( as in the case of a hardware back-button on Android which is altogether missing on iOS handsets and tablets ) simply impossible to duplicate across devices.
A UI control from Android may be architected, from the bottom up, to be completely different and non-compatible with an equivalent individual or set of controls from iOS. Replicating the behavior of one control from Android may require multiple control from iOS (and don’t forget Windows Phone!). UIPageViewController? Not in Android. UISplitScreenViewController? 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 examples are less stressful, but there are some really bad ones which will surely leave developers and designers (and most importantly, users) puzzled. Tool Bar / Tab Bar / Action Bar Insanity The “ Action Bar ” in Android behaves fundamentally different than 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 will involve swapping and mix-matching across three completely separate and functionally different components: UITabBar, UINavigationController and UIToolBar. If you add in a “Universal” iPad mode with a UISplitScreenViewController, this becomes even more difficult ( although probably less so since the iOS 8 update ). In iOS, the area under the title bar / navigation bar is reserved for UIToolBar (which contains contextual actions). Items in UIToolBar are meant for performing contextual actions , not navigation:
Use a navigation bar to enable navigation among different views and—if appropriate—to provide a control that manages the items in a view. If you need to provide a larger set of controls and you don’t need to enable navigation, consider using a toolbar instead (to learn more, see Toolbar ). 
On iOS, the “Tab Bar” equivalent which is used to navigate between screens floats at the bottom of the screen where Android likes to wrap various contextual options from Action Bar. The Title Bar / Navigation bar is a separate entity entirely from UIToolBar and UITabBar and can host it’s own contextual items. There is no wrapping or exchange of items in the same way Android does with Action Bar. Replicating this experience across iOS and Android (and don’t forget Windows Phone!) would require a level of convoluted UI programming which borders on Cyclopean. I fear genuinely and truly for any developer tasked with making this “easy” for end-user developers ! Facebook developers are smart but they probably aren’t that smart. iOS does not have drop-down menus, Android does iOS doesn’t have drop down menus , instead relying on pickers while Android does . Furthermore, drop-down menus in Android are meant for navigation, not contextual data selection and manipulation. Attempting to force iOS into Android navigation patterns doesn’t make a lot of sense ( or respect the end user’s choice of native platform, see exhibit A ). iOS does, however, have pop-up menus which can live in the bottom right of a UITabBarController in the form of a moreNavigationController . Is there realistically a way to transpose, using automagical code, an Android interface which makes use of drop down menus into an equivalent iOS interface…and have it be “Universal” across iPhone and iPad? Whatever they pay the person who can figure that out is worth it but I doubt it is realistically possible to pull off. The Universal Application Mega-FailBuilding Universal applications which reuse code across phone and tablets is already quite difficult and many companies fail to accomplish this goal even with teams of skilled native developers. I have a truly difficult time believing that we can sprinkle some React Native on this issue and solve it across platforms. I am not going to drill much farther into this topic other than to say I am simply going to assume React Native is meant for more basic applications. The Cross-Platform Snake Oil Demo StrategyOne thing I have noticed over the year despite multiple attempts on the part of platform providers to demonstrate working cross-platform native solutions is they always seem to use applications which follow this pattern:
The reason why React Native (and Fastbook before it , which relies on HTML5) use these patterns is that they are probably the only patterns which can be consistently replicated across all mobile operating systems. Step outside of this pattern and, as I have worked to outline above, you are going to run into severe problems quickly. Add in Universal apps and you are likely to be better off going all native. So thats itiOS and Android are massive in size on their own. Not only that, they change drastically every year. The rate change is astonishing. Last WWDC, Apple introduce 4,000(!) new APIs . Thats just iOS, not even including Android. Do we really and truly believe that Facebook, no matter how many brilliant engineers they employ, can possibly update React Native fast enough to keep up with this rate of change? Do we truly believe that Facebook can possibly stay ahead of these yearly updates at the grueling pace which Apple and Google have been maintaining? Color me skeptical. |
|
|
