While working on our Devbridge TeamApp, we were confronted with a dilemma. Our backend and the iOS version were continually updated by various developers, while the Android version’s codebase couldn't keep up. The result was that iOS users had access to features that Android users were missing. We realized that with our limited internal R&D team we didn't always have the necessary bandwidth to update three platforms and started looking at a complete rewrite of the app. And this time, we were going to go multiplatform.
We weren’t thrilled with the idea of a Web-App, which would only be there to act as an icon and a loader for a web page. It doesn’t offer the same native feel as a proper native application, and it doesn’t work at all without a network connection. We also wanted to have more functionality than what a web page could offer (like Health integration for iOS, photo upload directly from camera, et cetera). It seemed a much better idea to look into frameworks that could let us write applications for the most popular mobile platforms used in our company, and around the world - iOS and Android - using the same codebase.
Xamarin vs. React Native
A crash course with React Native
We loved the hot reloading capability of React Native, which let us modify application code without recompiling the application itself. Code is loaded from a local server while developing, and is packaged into the application with other resources on proper release.
Layout in React Native is implemented with CSS-like stylesheets that allow you to specify border widths and margins, colors and fonts. The nicest thing about this is that elements can be laid out using a partial implementation of flex-box layout rules. That makes arranging elements in a row, spacing them out evenly or making them stretch proportionally a breeze. Basic component hierarchy is laid out with JSX tags, and style information is added by passing “style” props to elements. The props can be dynamic and generated at runtime. The same goes for the structure by using variables in the JSX tree.
Don't “React” to it all...
However, a problem became apparent as the project got more complicated: What do you do when the functionality that you require isn’t in React Native, can’t be made with given components, or requires the use of a library that was made for native development and not for React Native? The answer is native modules. Native modules are a way of bridging native code and React Native code. A component written in native code can integrate with the usual React Native layout. We had to write native modules that supported multipart form upload and photo operations.
In the native application, React Native looks like a simple view controller, so if you want to use another view controller from a library, you can push it over React Native and then pop back from it. We used this for photo previews for which we had already made view controllers in our past projects.
Even though we didn’t have Android development expertise, we were able to implement the views and components we needed by using a bit of Google-fu, and then we were back in the React Native code.
Keeping things neat with Flux
Is React prime time ready?
React Native enables quick prototyping and a very high initial velocity. Basic features are relatively easy to implement. If needed, they can be extended with native code and native views, and also integrate well with other view controllers. Specifics are easy to pick up, and don’t stray too far from the React framework used in web development.