When developing a mobile app, writing native code for both iOS and Android is a big investment, especially in the early stage of an app’s lifecycle, when things change rapidly. So at first we looked closely at the nature of the apps, and concluded that React Native was a great fit: we could benefit from more rapid development processes but still have native apps on both main platforms. It also meant that we could rely on our web development skills and we weren’t constrained by the availability of native developers.

This is where React Native shines: it is the best of both worlds with regards to using Webviews inside simple native wrapper applications, porting React to native code or, as it’s called now, ComponentKit, and scripting these with Javascript to call native APIs.

When I first got my hands on an app in the early stages of development, I was impressed with how quickly the app was being developed. When initially running through the app on iOS devices, all the native UI was there, and it felt like it had been built by a native developer. But first impressions can be deceptive. When I opened the app on an Android device my hopes were dashed: the native user interface and behaviour had not been thought about at all, which made the app feel very alien on Android — as if someone had created an iOS app on Android. This led me to be a lot more cautious and take a step back from being as comfortable in testing as I would be for a native app; it felt a lot more like testing the unknown.

A lot of this is down to creating the app for a single operating system, in our case for iOS, the mobile device of choice of most of our developers. An example of not knowing or understanding the native UI and behaviour of Android is the use of the “back” button on Android to navigate between app views; in this case, that button simply closed the app!

I had hopes that React Native could bring an end to the fragmentation that occurs across Android operating systems, but this is not the case. Although it appears to be better, I’ve come across memory issues, which are OS specific — in our case, affecting Lollipop. I also found issues where the app just won’t work on KitKat due to libraries being too advanced for the operating system. Ultimately, this steered our decision to not support KitKat and focus on Lollipop and above.

This may come across as a drastic decision, but the amount of time and “hacks” that it would involve to get a specific OS to work, and the likelihood of this introducing stability issues across the remaining Android versions, made it too costly to support. While stats show that KitKat still makes up a significant percentage of the overall Android population, it is now four years old and is a legacy OS. Its use will only decrease over time and we are now on Android 7.0 (Nougat).