From Native to React Native

As a decade-long native Java Android developer, my background in mobile app development dates back to Android 2.3, a time before Google Play even existed. Not to mention I have always written Android apps in Java. During this time, I have had my fair share of trysts with libraries, frameworks, and all sorts of layers aimed to make app development faster, easier, quicker to start or in other words, cool!

A barrier to acceptance

In the winter of 2015, a new buzzword started doing the rounds — React. The folks at Facebook had discovered some secret sauce that would make app development faster, cooler, and according to some, even for college kids. So, I gave it a first shot during a weekend out in the summer of 2016. React at that time was lacking clear documentation for a high-level development framework, and just seemed like a moonshot.

To be honest, I have never been a fan of Javascript, primarily due to the lack of static typing. All-in-all, React somehow was always on the sidelines.

Things changed recently when I joined the engineering chapter of Nuri, a banking startup in Berlin, Germany. The entire frontend was written in React Native, distributed on Android and iOS devices, handled on/off-device key management fairly well, had an impressive UI/UX experience, and honestly, the build artifacts required a fairly small footprint in CI pipelines. To get around the lack of static typing in Javascript, the teams had utilised TypeScript.

Obviously, being in the chapter and not knowing the primary language and framework of development was embarrassing enough for me; so I had to pick up on learning React Native at some point soon.

Confusion and Curiosity

What confused me in the development flows were the differences in the velocity of functionality and UI development compared to my understanding of “native Android” development.

For example, a mid-level developer would easily churn out a functioning version of a screen with listings of data entries fetched from a backend in half or single sprints but would take up almost half a sprint to create dynamic-sized character elements in a Text view. These are undoubtedly motivated folks, so something else was there, most likely in the development toolkit.

This got me curious to start digging deeper into the codebase, and a week into the digging, I knew I had struck gold.

Getting my hands dirty

So I took some days off to have a week outside work, dug around for good resources to start learning and settled in with this Youtube video.

By the end of the day, I had an app running on an emulator with all the basics of a simple smartphone app -> fetching data through REST APIs, updating scrolling lists with fetched data, simple animations between components, texts, graphics - svgs, pngs, and some more of the basic stuff.

There were a million open questions in my mind when I went to sleep that night but was simply blown off at the ease with which components could be built and debugged in real time! The day was Aug 01, 2022.

Either Mosh is a really good teacher (which he is), or I had found a suite of development systems that would make frontend app development just simple, almost to the point it can be called “semi-automated”.

The next day morning, I took up a course on Udemy for a basic course on React Native development to have a structured approach to learning it, and also possibly go through some project work.

First app

Fast forward 6 weeks, and I published my first app on iOS on TestFlight. It was the iOS version of an Android app that was already available on PlayStore for months. It is my first-ever iOS app and the duo of TypeScript and React Native helped achieve it in record time.

Even the Android app version took me about 2 months before I could release it for beta testing on PlayStore, and that after almost a decade of Android app development.

The app is part of a side hustle - The Somnos Project aimed at building simple digital solutions to help people focus, relax and sleep better with the power of sounds. If you are fighting to get some Peace Of Mind in your daily life, do try out the products from this project.

Feeling the awe!

With React Native, everything seemed to just “happen”. Everything that I did not want to deal with in native Android development, I did not have to deal with in React. Case in point, linking and indexing view elements from xml definitions to Java application code. In React, there is no separation of the definition of views and application code.

As a developer, I no longer had to deal with different types of visual components -> Activity, Fragment, Views, etc. In React, it is all just a component. The best part is, you can created layered composite components, taking the reusability of visual components and application code to a whole different level right inside the framework.

There was no longer time to fetch a coffee while Gradle ran your application build. Just save your files, and the changes are immediately there on your phone/emulator.

Typescript

The support for static typing, modules and compile-time error detection in the IDE takes away all the pain points I had with Javascript and surfaces the beauty of Javascript. For me, it was the perfect supplement to React Native framework for high-level app development.

Expo

Expo is the icing on the cake for React based development. It is a suite of services that enables you to build a mobile app without a single digit of knowledge of the underlyings — iOS or Android phones, Notifications, build and distribution and more.

Every functionality that is needed in building a React Native app is built as “an Expo version” by the Expo team, so you get libraries and components which work as a layer on top of the React Native development layer. The best part is that the Expo teams also provide you with simple supporting infrastructure elements which typical app developers need:

• A push notification service that abstracts away Google FCM and Apple APNS, and works without keys, account setups, etc. Just a single REST API request.
• EAS build system takes away the hassles of signing, distributing builds, managing certificates and whatnot for Google Play store and Apple App Store. Your linked Expo account takes care of it all when you trigger a “build and deploy”. The built-in CI pipelines of EAS make it as easy as a single (or two) command(s) for the entire CI pipeline to deploy to either app store/marketplace.
• Development libraries and frameworks that work on top of React Native and abstracts away everything that a typical app developer might not need to know.

Obviously, for everything else, you can “expo eject” and get down to development on React Native, or even down to Java (Android) and Swift(iOS) codebases -> all within the same code repository. Although, I did try it 3 times now, but failed miserably each time.

Honorary mention

Development client is an attempt from the Expo team to fully abstract away a complete layer even for those React Native libraries that require platform-native modules access. It has a way to go before being fully mature, but it served me well enough to take 2 fully-loaded iOS and Android apps to Beta-testing/production. That is something I can definitely live with.

Looking ahead

It is pretty clear to me that React Native is the best solution out there if you are trying to build a service that should be available on Android and iOS mobile devices and Web browsers. Flutter and similar ones are also options with pros and cons.

For small businesses who just had an idea and would like to prototype it out within a month or two, trying it out on React Native is probably the best idea. The framework has the power to get you a running app with simple functionalities in place within a day or half-week at max ! Almost every functionality that typical apps have are already available in React Native “native” libraries or even better in Expo.

Looking back at all the times when I had an idea for an app, and had to abandon it mid-way since development was taking a long time, I lament not having adopted React then. All that said, it still does not mean that I will shelve away native Android development on Java any time soon. It is still the only option to build on core platform functionalities like owner apps, admin apps or geekier into the AOSP!

Also Published Here