Many clients want mobile apps for both the iOS and Android platforms (and some for the Windows platform too). The conventional approach is to develop an iOS app using the Swift language (or Objective C) and a separate Android app using the Java language. That approach brings with it a number of disadvantages; the most obvious to the client is that they have to pay to build and maintain two different applications that do the same thing. Another disadvantage which indirectly impacts the client is that the agency has to maintain skills in multiple platforms, paradigms, languages and tooling.
Maintaining multiple specialised ‘siloed’ development skills in an organisation has consequences. Consider resource balancing: imagine you have a fixed number of iOS developers and a fixed number of Android developers. When you offer solutions to customers you have to schedule your project pipeline to fit in with your resources. If you have accepted work which fully loads your iOS developers, any further iOS app projects won’t be able to start until those resources become free. This delays the date you can start the work and potentially loses you the opportunity. You could of course take resources from existing projects which will impact their delivery dates. If some of your Android developers have no work to do they are not creating value yet their cost doesn’t go away.
Of course, you might be able to find developers who have good competence on both platforms but they are then unlikely to be the specialists you require; and if they are specialists in multiple platforms your cost base will increase. Short term resource challenges could be addressed using contractors but that has it’s own set of problems.
For agency work scheduling resource availability clearly impacts delivery dates. For product work, these costs and resource conflicts impact client’s return on investment and time to market.
The solution we have chosen
At 1minus1 we have chosen React Native. Let’s explore what that is, how it works and how we and our customers benefit from it.
React Native is an Open Source framework initially developed by Facebook. It supports the React paradigm and is implemented as a set of libraries providing indirect access to the native frameworks on the different platforms. Hence the name.
Facebook wrote the libraries for iOS in Objective C and the libraries for Android in Java. They include ‘bridges’ to make the native platform libraries accessible. Microsoft also claim to have written a set of React Native libraries for the Windows platform which includes Windows Mobile (we have yet to test these).
You can also add third-party developed components or create your own native components. For example, on IOS you can write code in Swift or Objective C which access native libraries directly and include a bridge to use it as a component in your app.
React Native supports ES5 syntax and the latest version of ES6. It also supports the JSX extension so the tags you write can be written more easily.
To see these details in practice let’s have a look at a fairly simple example from one of our mobile apps so any front-end web developers out there can see the similarities to your own output. This one is written using ES6 and JSX.
Instead of using full-blown CSS, React Native supports a subset of Flexbox, a layout mode in CSS3 with which front-end web developers may be familiar. The style properties (or attributes) in the above code reference the following Flexbox definitions which we place in a separate file (see below) so they can be reused more easily in other components.
In that example, the component has no state. In React Native each component may have a state which is represented by the state dictionary this.state. Whenever you change the state (dictionary) e.g. in response to an event, the render method of the component is called and the component is redrawn. Actually in reality your request to change the state is handled asynchronously and the state is not changed until the current thread has completed so your code following the request can be executed without being interrupted by the state change. You distribute your business logic throughout the app by including each part within the component that renders the associated information. This keeps related code together and facilitates easy re-use of code at component level.
Functions can be passed as properties and this mechanism allows a component to communicate back to the component that contains it in the view hierarchy.
Tools such as Xcode and Android Studio can be used to package the React Native software into an app for testing on a simulator, for distributing to test on a device and for distributing through the App Store or Play Store.
Results and learning
Facebook suggest re-use across mobile platforms could be 85% or more and we have found that in some cases the re-use is 100%. Yes, in some cases the same software can be packaged into an iOS app and into an Android app with no changes and run natively on each platform. This is an incredible saving that we can pass on to the customer and improve our competitiveness.
So, is there a downside? Well, we haven’t done any really complex apps using React Native yet, but scalability is one of the main benefits offered by the React paradigm so there should be no real problems there.
Are all platform specific features supported? Well, all the features we have needed are supported by React Native or third-party components. React Native is Open Source with a growing number of active contributors so the pain and the remedies are shared by the community.
Does the choice of solution affect the customer in any other way? Customers are always able to change their suppliers and, if they choose to, it shouldn’t be too difficult for them to find developers who could maintain the app software because these developers can either be front-end developers or mobile developers.
The philosophy behind React Native is “Learn once, use anywhere” and Facebook’s vision is to have one paradigm and one development environment across all mobile platforms and front-end web development.
Although we have built a number of mobile apps using React Native it is still a relatively new technology for us. We intend to use the same automated testing technologies in React Native and front-end web development.
Our conclusions – they’re good!
The similarities between the way we now do mobile development and the way we do front-end web development (same paradigm, same language, same tools, many technologies the same) means that we are able to view a group of developers as one resource pool for a lot of our iOS app development, Android app development and front-end web development. This should make the project pipeline easier to manage and will enable us to be even more agile in addressing customer demand.
A further benefit we hadn’t considered is emerging: front-end and mobile developers can review each other’s code (we use PRs in github for this). We still need experienced mobile developers for some things; for example, app packaging/ distribution, implementing platform specific requirements and understanding mobile UX standards but that will only be a small percentage of the effort on most projects.
Although it’s possible that some requirements on future projects might not be so easy to implement in React Native, we can summarise our journey so far:
We set off hoping to improve our productivity when we are developing a mobile app on multiple platforms. We found that React Native did help by facilitating high re-use but also that it can even improve productivity developing for a single platform. An extra benefit is that using React Native for mobile development and React for front-end web development means it should be possible to share resources across the two disciplines.
We firmly believe this approach will bring a major improvement to our productivity, flexibility and competitiveness going forwards.