Cross-Platform App vs. Native App Development in the ordinary life of a dev

What we at Motius do spans from simple IoT prototypes for our office to complex software solutions for our clients. In most cases, this includes developing a mobile application. The reason for this is that mobile phones accompany us everywhere, so we like to be able to do everything with them. If you think about it, it’s only natural to have an app be part of a project in most cases. Motees love mobile development and we believe it’s very practical to be able to control our hardware prototypes via an app, so mobile development is indeed a must for us.

An example of a project that is worth mentioning is our drunk detector app, which is actually a prototype we built on a weekend at our office. You attach an infrared camera like FLIR to the phone, look into it and the app will tell you whether you are drunk or not. We natively developed this application for Android, simply because the developers were using Android phones, so we didn’t see any benefit in targeting iOS at the time.

But is this the case for all apps we develop?

What do we do when a client comes to us and wishes to build an app? The first thing we typically think is: let’s make it cross-platform. Why? Because we can. We found out that, with experienced developers, implementing a cross-platform mobile application takes roughly the same amount of time as it would take developing a native application for only one platform. And if a project doesn’t require specific hardware or APIs, which are not available on both platforms, then why not kill two birds with one stone?

Like many others, most of our developers are self-taught in native mobile development and are quite fluent in either Android applications written in Java or iOS applications written in Swift, or even both of them. There comes a time though, when you want to rapidly prototype a solution for both platforms, without having to write the entire code twice. There’s many different ways to do this and all have their pros and cons. At Motius, the framework of choice for doing this is React Native.

The React Native experience

React Native spawns off ReactJS, which was originally intended to help developers in building web applications (we’re talking about one of the top starred projects on GitHub). One day Facebook decided to apply this concept to mobile development as well, which is where the React Native adventure starts.

But why React Native and not one of the other cross-platform development frameworks, such as Xamarin or Ionic? For starters, at Motius we all speak JavaScript, we love to keep up with the newest technologies, and seeing that React Native is a new open-source framework with a big community behind it, we believed it to have a lot of potential. Moreover, the components are mapped to native elements, compared to the typical web-view-based apps. I’ve personally only had experience in using Xamarin before and didn’t feel quite comfortable with it, mainly because of the poor community support and scarce open-source libraries available. This is not the case with React Native. But I’m definitely not going to start a religious war over which framework is best; instead I will simply focus on some technical advantages brought about by React Native in the everyday life of a Motee and why we keep using it.

The Good

Let’s start with the very moment our tech-addicted developers decide to create a new project: A React Native project basically contains 3 projects at once, 2 of them are our beloved Android and iOS projects, which we all know how to handle; hence they shouldn’t bother us too much. Gradle (a common build tool for Android) works as always, and so does CocoaPods (a widely-used dependency manager for iOS). The only thing left is a JavaScript project, which we can open on any operating system, with any development environment or editor. In this project the whole creation of the app takes place. By the way, did I mention that creating the whole project requires to execute a single command? No need to click us through a 10-page wizard on an overkill UI. Well, isn’t that handy?

Next up are the views, which are the core part of the entire development process. You could be wondering: there are HTML-like tags and CSS rules, so the views are shown in a web view, right? Nope and that’s the great part. React Native components instantiate native elements and native views on both platforms and communicates with them. Some widgets are not supported in the framework by default, but that’s where the big community comes in play: all native libraries can be bridged and used, additionally to all the available open-source JavaScript libraries out there that are built to instantiate native elements and manage them. Although this is not like writing an app in native code, the end-result looks the same and the performance is quite good.

Last but not least, the deployment. It just works. Be it an emulator/simulator or a real device. One command in the terminal and the app is installed and running. And it looks the same on both platforms.

The Bad

Of course, it’s not always roses, there also happen to be some downsides. As a developer, there is a time when you need to do something that is not supported or included in the base framework, so you have to look for a suitable library to help you out. There’s tons of libraries out there and it takes some time to find the right one. All libraries are open-source and can contain Easter bugs. Fun fact: we noticed several times already that some bug reports had been open for months and in the end, it was up to us to fork the libraries and fix those bugs ourselves, or add some functionality we needed (this is just one example). To be completely honest, every now and then working with the framework feels like testing a beta version. Also, in some extreme cases, a library you are looking for doesn’t exist at all or doesn’t cover an edge case which is required in your app. In that case the only option is to resort to native modules, but that’s very rare. The size of the community, however, is a big plus and makes us confident that the framework itself will keep getting better.

So now we can finally write mobile apps completely in JavaScript without having to use web views. Yay! More JavaScript power to our Motees. For people who’ve had experience with ReactJS before, React Native is rather straightforward and the big challenge is finding the right libraries and APIs for your purposes. I personally dived directly into React Native without any intermediate steps, so this definitely caused the learning curve to be steeper. Damn those bloody flex-boxes. I got to love them though, after spending several hours trying to figure out why a view wasn’t where it was supposed to be on the screen (or was missing altogether).

Conclusion

At the end of the day, it’s really fun to be able to quickly prototype an app and have it working right off the bat on any phone, with good performance and most importantly, a lot of satisfaction 🙂

Do we miss native development? Definitely! But mostly because we haven’t used one of the new OS versions before and want to play with them in order to learn something new (isn’t that in our DNA, after all?). Cross-platform development in general really makes the entire flow more efficient and opens up more possibilities. We really like it and will continue exploring these new possibilities. Who knows, maybe next up will be a cool framework for cross-platform development for wearables?!