Developing in React Native is very different to writing Native source code. Life can be fun and here is a my experience learning the balance between the two.
My initial months at Coroma were spent maintaining legacy Objective-C applications, helping when needed with some Swift projects. In January, I was lucky to be placed on a project prototyping an application using React Native. This allowed for a self learning opportunity to add to my skillset. Developing in React Native is a completely different paradigm and it’s popularity within the industryis extremely hi, so I was really lucky to jump onto this project team. You may be interested in what I’ve learnt jumping back and forth between the two.
Technically, the biggest difference between the two is how each platform separates the view from the business logic. React Native relies heavily upon State Management, with it’s origins from JSX and is based heavily on HTML and CSS which is used to layout UI components. When the state of the application changes, all the components re-render. Even more interesting is with Redux, or any other predictable state container, changes delivered by another component or asynchronous request can be consumed in a global context.
By comparison, UI elements in a Native iOS application are constructed using an extensive framework called UIKit. Elements can be easily displayed on the view in a wysiwyg editor or programatically via the objects properties. Androids XML properties for UI elements are closely related to React Native, giving Android developers a slight advantage.
As React Native is not officially supported by either Apple or Google, not all native features are supported in by React Native. For example, implementing a simple keyboard accessory in React Native is virtually impossible. Support to customise that view is missing. The projects themselves require significant configuration to support React Native where hardware of the device is accessed. Having native definitely expedited app setup. Apple required the user accept access to hardware and Google maps for instance is not native to the iOS platform, so knowledge of including external dependencies is a definite help.
Design patterns of Android and iOS are quite different. Heavy testing is required to determine which platform is being used in order to execute the correct code. Developing a unified UI for both platforms is not the goal of React Native, building platform-oriented interfaces with minimal programming effort is the real purpose. Knowledge of user interface design abilities in both platforms in indispensable.
This is a risk in choosing React Native. For example, the last Salesforce React-Native SDK still depends on RN 0.50.4 (released last November), and applications requiring it as a dependency will need to be downgraded to support that version. The current Salesforce SDK depends on RN 0.53.3, we have to upgrade all the other dependencies and configure changes.
I hope I have presented some good evidence of pros and cons of React Native development. This is a very complex issue amongst mobile developers and each developer has their own opinion. Please feel free to share your opinions and discussions by commenting below. If React Native interests you may gain a lot of knowledge reading our other blog http://coroma.com.au/the-react-native-blog-i-wish-i-had-when-learning-react-native/