When I was doing mobile development with Android, iOS seemed like the other side of the world, just as being a South Korean never imagining crossing the border to the north. I never even owned an iPhone.
Soon this became a problem. When I wanted to create my own mobile product, I had to have my “significant other” to have the iPhone users to be on board with the product, and some ideas are difficult to test properly without embracing both platforms.
Even when I was working in a startup that was operating an app with 1.5M downloads, I witnessed that the inconsistency of Android and iOS development slowed down the whole development process not in terms of 2x, but 4x. Product management became a chaos.
Sometimes 2-week-worth of codes on Android ended up being trashed, because these codes were decided by the team to be implemented during the Android team were waiting for the iOS to catch up (iOS were delayed by the lack of developers and inefficient App Store Review process).
That is when I started looking at React Native — a Facebook initiated open-source framework “for building native apps using React.js.”
At first, I was skeptical about the whole thing, because I saw many unsteady and lagging hybrid apps. However, React Native is different from any other javascript-powered mobile framework, because it scripts javascript directly to the native layer, rather than adding another layer. Check out this keynote on React.js Conf 2015 to understand more about this.
Long Hoang, my teammate, and I have decided to build the prototype of our startup idea, Plain Exchange, with React Native. The choice was inevitable, since, due to the nature of the idea (peer-2-peer foreign currency exchange), we needed the app to run on both platforms, and we did not have enough resource to build two apps.
After working on React Native for 4 months, I strongly believe that React Native will be a game changer for mobile development.
Does it actually work well?
Yes.
After 4 months of development, our team succeeded in developing a well running app with same features with one codebase on both Android and iOS platform.
Unfortunately, since our app was rejected by the App Store, it is only published on the Android Play Store.
Here are some running video of the app on both platforms. You can see that a lot of layouts are rendered almost identically!
What’s so good about it?
1. Power of React State & Flux
React makes the application into a state-based machine. The magic of React is that it deals all changes with state changes. The virtual DOM with Flux makes it so much easier to handle changes of data and each component. Since this is very obvious for people who are familiar with React & Flux architecture, I will not discuss in detail. To learn more check the official React website and/or talks from React Conference.
When I was developing in Android, the use of cache was necessary, and each view had to decide whether it had to pull data from the cache or from the plain java object. But in React-Flux structure this confusion is solved since all data in the view must go through the flux store.
2. All-in-one js file
When I was developing with Android Studio, I had difficult time going back and forth xml and java files. Although Butterknife library made it simpler to bind Android views, it is still quite hard to see how the component will look like as a whole. If there are many state changes in the view, the code gets more complicated.
On the other hand, React Native puts all logic, view, style, and state in one javascript file.
For example,
var Error = React.createClass({
displayName: "ErrorCard",
render: function() {
return (
<Text style={styles.description}>
{
this.props.data ?
this.props.data["Text"] :
"Opps, this is embrassing."+
"\nSomething went wrong :(\nWe will fix it soon.\n\n"
}
</Text>
);
}
});
var styles = StyleSheet.create({
description: {
color: '#333333',
fontSize: 18,
textAlign: 'center',
paddingTop: 10,
paddingBottom: 10,
lineHeight:25,
},
});This is a simple component that shows an error message. The render function shows exactly how the component will be rendered with ternary operator handling the logic of default and non-default error message. No need to mention the css-style styling of the view.
3. Dynamic Loading
Android gradle build is very notorious for its speed. When my teammate gets up for coffee, I will always ask “gradle build?”, and he says “Hope it will be done after I come back to my spot.” and laugh.
But with React Native, I didn’t need to worry, because, if I enabled dynamic reloading, the moment I pressed save on my Atom editor the app will be refreshed. This is such a game changer for the productivity of mobile developers. I think my productivity went at least 4x up.
Another feature that needs to be mentioned together is the dynamic updates. React Native bundles the whole javascript files into one to load the whole app. Because of this nature, there has been new attempts — like CodePush from Microsoft — to dynamically update the app without going through the Apple App Store or Google Play Store.
I have never used this myself yet, but technically it seems feasible. This is another productivity booster considering all the hassle with App Store Review.
Please share some experience if you have any experience using CodePush or any other similar service!
4. Javascript (ECMAscript 6)
Since I have been coding in Java for a long time, when I first started using Javascript, I was shocked about its flexibility. The functional programming paradigm was so new to me that at first I had hard time dealing with concepts like closure, function as parameters, etc.
Nevertheless, the more I got used to Javascript, the more productive I got in building the product. I especially love how I can pass functions down as React props.
One thing that Javascript lacked was the power of inheritance. Using Javascript prototype did not look comfortable. However, in ECMAscript 6(es6) — the new version of javascript, class feature enabled to embrace the advantages of object-oriented language. As soon as I learned es6, I refactored a lot of my codes, removing deprecating paradigms like React mixins.
I would not say I am not the best Javascript coder yet. I try to keep on learning more about the language through reading blog posts and learning through Code School lectures.
5. No more looking for iOS “significant other”
In four months, I submitted the first app on the Apple App Store. Although it was rejected, I made a full-functioning iOS app on a native layer with only couple of lines of Objective-C code (for configuration).
Since React Native started off with iOS, my experience tells me that it is slightly more stable and rich in resource on iOS than on Android (but it is catching up very fast!). Whereas I spotted some device-specific bugs (as always) on Android, iOS version was reasonable stable.
Now I would confidently use React Native to prototype on iOS and/or Android, rather than looking for the significant other. If possible, I want to carry React Native to the production level, since the app will be in one code base, enabling the team to re-use a lot of codes.
Facebook team revealed that Facebook Ads Manager has been built on React Native and the team was able to re-use 85% of the codes. When I was building Plain Exchange, I think I roughly achieved similar percentage. Using “Platform” library with if statement/ternary operator, I have easily managed to manage the diverging code sections.
I really enjoyed my time hacking with React Native and will continue making mobile products with it. Check out my RN codes on github.