Frustrated when your managed Expo project misbehaves and you have no option to customize it? Well, that is a thing of the past now. This tutorial will teach you how to start with Expo config plugins which allow you to add custom native Android and iOS configurations without ejecting the managed workflow. We will use a practical example by debugging and fixing Android's status bar translucent behavior to allow our splash screen reach all device edges.

INITIAL SETUP

To initiate our project you can simply clone this repository that has all demonstrative assets included. Or you can start yourself by running expo-cli:

expo init first-config-plugin -t expo-template-blank-typescript

Then add expo-splash-screen as your dependency..

expo install expo-splash-screen

..and necessary assets to reproduce the issue. We are using typescript for better development experience, which you will definitely find it helpful writing the plugins.

THE ISSUE

We want our application to look cool and therefore we show a full screen image on the intro page. For that we need to set the status bar to be translucent so that image can stretch under it.

<StatusBar style="dark" translucent backgroundColor="transparent" />

The issue is that the status bar is not translucent from the start, resulting in our splash screen and logo shifting up once the translucency takes effect on the app mount. Notice also the color shift of the status bar.

Luckily Expo allows us to configure the Android status bar through app.json which will set the default behavior before the app mounts. Lets try to replicate our settings:

  "androidStatusBar": {
      "backgroundColor": "#00000000",
      "barStyle": "dark-content",
      "translucent": true
    }

The result is not exactly what we wanted. While we managed to make the color of status bar dark from the app launch and logo is not shifting up anymore as translucency is taking effect, the bar itself has that ugly overlay.

We need to investigate what is going on. By running expo run:android or expo prebuild -p android we can generate the Android folder with its configurations. If you don't know where the issue is coming from, you can use a simple strategy to see where changes are being made. Just stage all generated Android files (git add -A), remove translucent: true from app.json, and run expo prebuild -p android to generate native files again.

By removing the translucent property you should see following unstaged changes:

android/app/src/main/res/values/strings.xml

- <string name="expo_splash_screen_status_bar_translucent" translatable="false">true</string>
+ <string name="expo_splash_screen_status_bar_translucent" translatable="false">false</string>

android/app/src/main/res/values/styles.xml

- <item name="android:windowTranslucentStatus">true</item>

This already looks promising as the expo_splash_screen_status_bar_translucent custom Expo property sounds exactly like something we are trying to influence and being previously true we saw the status bar was really translucent during the splash screen. We also notice that android:windowTranslucentStatus was set to true which with some googling we realize was responsible for the status bar overlay. If you are in managed workflow, in the past you would feel trapped because you can't have one without the other to reach the behavior you wanted and the only option was to raise it in Expo issues. But now thanks to Expo config plugins you can take the solution in your hands.

THE SOLUTION

The solution is to make expo_splash_screen_status_bar_translucent set to true while keeping android:windowTranslucentStatus as false - which is the default therefore lets change only the Expo property. With expo run:android you can actually change it in your Android native files yourself to prove the effect after a new build. Yet if we want to stay in managed workflow and away from native file changes, we need to write a custom plugin which will do the change for us during the prebuild.

This means any native changes through plugins will be reflected in Expo development environment only using expo-dev-client - our custom Expo Go.

The @expo/config-plugins package is already part of Expo, so we don't need to install any new dependency. We will start by creating our plugin file in typescript, which is a recommended approach and can be useful not only for more advanced changes.

Lets create our initial plugin file withAndroidSplashScreen.ts in the root folder:

import type { ConfigPlugin } from '@expo/config-plugins'
import { withStringsXml } from '@expo/config-plugins'

const withAndroidSplashScreen: ConfigPlugin = (expoConfig) =>
  withStringsXml(expoConfig, (modConfig) => {
    return modConfig
  })

export default withAndroidSplashScreen

And start compiling it into javascript:

yarn tsc withAndroidSplashScreen.ts --watch --skipLibCheck

Finally, import resulting withAndroidSplashScreen.js file into app.json plugins property for Expo to process it on a next build. Our changes look like this:

{
  "expo": {
    ...otherProps,
    "androidStatusBar": {
      "backgroundColor": "#00000000",
      "barStyle": "dark-content"
    },
    "plugins": ["./withAndroidSplashScreen.js"]
  }
}

Now you can run expo prebuild -p android to see effects of your plugin. Obviously, if you inspect our withAndroidSplashScreen code it is not changing anything yet. It just returns whatever it receives. Our plugin is a simple function.

Initially our plugin receives expoConfig which is basically content of app.json and this object is passed to the withStringXml mod. This particular mod (modifier) from Expo enables us to read contents of android/app/src/main/res/values/strings.xml and change them based on what config we return (all available mods can be found here). For each mod its content can be read from modConfig.modResults - you can actually use console.log(JSON.stringify(config.modResults, null, 2)); to inspect the values during the prebuild command. To apply our desired changes we need to modify modResults.

import type { ConfigPlugin } from '@expo/config-plugins'
import { AndroidConfig, withStringsXml } from '@expo/config-plugins'

const withAndroidSplashScreen: ConfigPlugin = (expoConfig) =>
  withStringsXml(expoConfig, (modConfig) => {
    modConfig.modResults = AndroidConfig.Strings.setStringItem(
      [
        {
          _: 'true',
          $: {
            name: 'expo_splash_screen_status_bar_translucent',
            translatable: 'false'
          }
        }
      ],
      modConfig.modResults
    )
    return modConfig
  })

export default withAndroidSplashScreen

As you see, we assign to modResults what is returned from AndroidConfig helper method setStringItem which accepts the value we want to add and then remaining file strings already existing. Inspecting type of setStringItem and typescript in general should help you fill all needed properties correctly. After running prebuild we should see a new configuration string:

+ <string name="expo_splash_screen_status_bar_translucent" translatable="false">true</string>

We now have our desired splash screen behavior with a translucent status bar already from the app start and without the ugly overlay.

SUMMARY

Hopefully this tutorial helped you to understand better the power of config plugins and that customizing your Expo project is actually not that difficult - you can see final solution in this branch. If you ask what to do with the native Android folder now when you are finished with debugging, you can just delete it together with all generated files. Important is to commit your new plugin file and changes in app.json. The prebuild command is a part of EAS build so next time you build your project, you can be sure your plugin will take effect the same way you did it locally.

Thinking about breaking into web development? Unsure if you have sufficient knowledge or if it's too late for you? Maybe you have a friend struggling with taking the leap. Whatever the case, my story might help.

I studied finance & investments at university for five years, then spent another five years working as an analyst for Bloomberg in London. Yet when I turned 30, I joined STRV — starting my journey as a web developer.

As you might guess, the path to get here wasn't clearcut. The biggest roadblock for a person changing careers is the psychological battle. Your brain can easily calculate what you're leaving behind (10 years in finance), but can't really determine what you might gain. Let's go over what to ask yourself when making this big life decision, and how to move forward.

DECIDING IF IT'S THE RIGHT MOVE

Learning what a web developer does is the first piece of the puzzle. Obviously, the ideal situation is to know someone who actually works as a developer, and even better if that someone's also gone through a career change. If you don't personally know anyone that fits the bill, you can easily find someone at a local development meetup (use the Meetup app or Facebook events). You can also read about building a web development career at freeCodeCamp or Medium, watch relevant Youtube videos or listen to a podcast. I did all of that and found everything equally helpful. Remember: You're entering a very broad and fast-moving space, so one developer alone cannot provide all the necessary info.

What intrigued me most was the lifestyle (remote work, flexible hours) and an opportunity to constantly develop myself, learn new things and build something people will find useful. If you like learning new things, this industry is for you. There are new programming technologies popping up all the time and while this can get tiring for someone who's been in the industry for years, those newer to the job find this exciting. This actually gives newbies a great advantage — companies need fresh, flexible minds that are enthusiastic and willing to learn a specific stack of technologies used.

As for having joined STRV, I'm thrilled to have the opportunity to determine my own hours and, even more than that, it's incredible to have smart colleagues around, all of whom help me develop my coding skills and provide guidance when trying new technologies.

READY TO LEARN?

The learning process for new developers can be split into the categories below. Since we all have a different learning style, I mention both pros and cons for each category. I'd recommend starting with the first category (as though it's the first step) and going from there—or choosing and combining what works for you.

Interactive Platforms

If you've never coded before, you need to start with the basics (data structures, conditionals, loops, functions, etc.). The best way to do that is to use a free interactive coding app, such as Codecademy, Sololearn or freeCodecamp basic courses. They are great because you don't have to install or set anything up, which can be a demotivating headache for a beginner. Some of them have a mobile app, too.

The apps teach users that writing code has to be precise. For example, it's not always apparent to new developers that lower and upper case letters matter. Another revelation for beginners is the importance of conditionals, and that showing either 'login' or 'logout' in a navigation menu is just an if condition based on a user being logged in or not. My advice would be to use these platforms to grasp the basics before they become repetitive and lengthy, then move on to more comprehensive material.

Video Tutorials

The next step involves taking more comprehensive video courses that teach how to build an app from the ground up. It is closer to reality than interactive platforms and is a good way to check if you actually enjoy the development process. Udemy and YouTube are great inexpensive sources to start with. Finding the right content among the vast amount of videos might be a challenge, but reviews and the number of subscribers/likes are a good guide.

When searching for videos, finding updated content is crucial given that the technologies advance very quickly. If you use outdated content, you might encounter compatibility issues if the tutor does not specify which version of a library he/she is using.

Once you've found some good options, observe the teachers and learn from those with a teaching style that suits you best. Among free content with good tutors, I recommend Kevin Powell (html/css), The Net Ninja (frontend) and Traversy Media (various tutorials).

Motivation, Inspiration, Clarity

Following a lengthy tutorial, you often get to a point when it's useful to step back from coding and consolidate what you've learned. Listening to podcasts such as CodeNewbie and Syntax or watching YouTube videos like Web Development in 2020 can complement the learning process, help you keep up with the industry's new trends and guide you in what to learn next.

You might also find yourself battling dilemmas such as learning a programming framework (React, Vue, Angular) versus focusing more on core knowledge of vanilla JavaScript, or styling your app with pure CSS versus utilizing a design library (Bootstrap, Material UI, Tailwind). Whatever it is you're struggling to answer, focus on keeping your motivations high by remembering where you're headed: building something real and valuable.

Furthermore, reading freeCodeCamp or Medium articles about career changes or development work also keeps you motivated and inspired. Twitter is great for this as well. And if you need more accountability, sign up for the #100DaysOfCode challenge to join a great community of upcoming programmers, who will support you whenever needed.

Content can feel repetitive after some time, especially while you haven't moved on to advanced topics yet. But personally, I loved this part of the learning process because it's — unlike when you've moved on to actual coding and you have to find free time and really focus. With a full-time job, that usually means waking up quite early or staying up late.

Meetups, Bootcamps, Academies

Meetups are irreplaceable. You get to know real developers who can answer any questions that pop up in your head. Sometimes, the topics might be too advanced to comprehend when you're a newbie, but give it a few months. Keep listening and learning. You'll gain a lot more clarity about standards and new trends in development. I once went to a Jamstack meetup in London (before it became such a buzzword) and the knowledge I gained definitely helped me keep up during various conversations with other developers before officially becoming one myself.

Bootcamps are also a popular way to speed up the learning process, but they aren't for everyone. It depends on whether you prefer learning at your own pace or the pace set by a tutor. Bootcamps can be very intense and a bit on the expensive side, so think twice whether or not the format works for you. While another huge benefit of them is that they connect you with like-minded developers and the industry, you can do that on your own if you put in the time. So if the format does suit you, and you prefer investing money over time — go for it.

As part of their hiring process, some development companies set up academies where they invite both developers and non-developers to attend a series of workshops. It's a great alternative to bootcamps because they are usually free, with no strings attached. You just have to show that you have the right attitude and hunger for learning. The fact that I attended STRV React Nights in 2019 definitely played an important role in eventually getting hired.

Whether you decide to go with any of these options or not, my advice is to keep asking questions. Leave all doubts behind; so what if it ends up not working out? The worst thing that can happen is that you will have spent time on learning something new.

Building stuff

Probably the most crucial part of the learning process is to start building stuff on your own. Here, you will question yourself the most because it is the hardest. Tutorials teach you to follow along, but taking things into your own hands and actually making calls about how to structure your project and code is a whole different ballgame. If you lose confidence, even right at the beginning, there's nothing wrong with turning to your peers or sources for inspiration. Have a look back at the tutorials you've gone through or check out STRV's open source templates.

A big question during this time is: What do you actually build? If you come up with an idea, do it. Starting a project will be your biggest motivation. And if you're low on ideas, a good tactic is to start replicating designs of other websites, even popular ones like Twitter. Google Developer Tools can help to guide you.

A good way to give purpose to your project is by adding it to your portfolio. You probably don't yet have the skills to build something that you could ask money for, so build a website for someone that needs it. It can be your friend, a small local business or a charity. When I was starting to develop, I noticed that a pastry shop near my apartment didn't have a website, so I went ahead and built a simple landing page. The plan was to first build it, then show them. Unfortunately, before I got the opportunity to present it to them, they already had one ¯_(ツ)_/¯.

Be kind to yourself during this stage. Becoming confident in your coding skills takes time. Nobody expects you to know everything and write code on par with senior developers. Embrace being a newbie.

Mentoring

Having a mentor is not a requirement when becoming a developer. For most of my career-change journey, I've managed to do things on my own. But when I briefly tried mentorship during React Nights, I definitely saw the benefits; it helps you get clarity on many things. From the coding logic you use to technologies you should be learning as a developer, mentorship provides a lot of answers and puts them at your fingertips.

There are specialized websites you can Google to find a mentor. Some are free, some are paid. Or you can take things into your own hands and ask someone to mentor you, be it in person or via Twitter or a different channel. You might be surprised, but most developers are more than happy to offer you their help — for them, it's an activity that lets them hone their skills and, in general, people tend to get satisfaction from giving advice. And of course, should you find a mentor, always respect and appreciate their time.

Teaching

The ultimate way to solidify your knowledge is to teach someone what you know. For example, you can either help other friends who are learning development or write an article. The article can be published on your personal blog, Medium or places like freeCodeCamp. It is totally optional, yet great for your resume and a good habit that will help you gather feedback from others and build confidence.

ON A PERSONAL NOTE

Learning coding can be frustrating at times. The biggest lessons often come from failing and fixing your mistakes, meaning you'll sometimes feel like you've hit a wall. And when trying to make a career shift, hitting a wall can be especially demotivating. You may question whether it's even worth it. Whether it's too big of a risk. My advice is, just remember why you decided to do it in the first place. And try to make the learning process fun!

Having successfully made the jump, I can now say with absolute certainty — to me, this career, this lifestyle, is worth it. And making a big career change later in life than most people, that in itself is a great feeling.

Being a mobile application developer, sooner or later you will face a request from your client to implement biometrics authentication and will be asked how many days it could take to release. Well, if you develop applications in React Native, the answer won't always offer itself right away because you need to find a solution that fits both Android and iOS. Therefore, some due diligence is needed first.

"Due diligence is an investigation, audit, or review performed to confirm facts or details of a matter under consideration."

There are several criteria you have to consider. Biometrics is usually a feature utilized in security-heavy focused applications to authenticate users; for example, your bank will likely sign your account out — either immediately once you close the app or in a very short time — to protect your finances should someone get control of your device. Therefore, security will surely play an important role in your decision-making process. Hopefully, every step you take in this direction will make it harder for a potential attacker.

Biometrics is also meant to make life easier for users so that they don't need to input their login credentials every time they need to authenticate themselves. That is why we need to look for a user-friendly solution, meaning the libraries we decide to implement should be actively maintained and offer the latest biometrics standards expected by users.

Finally, development time is money, so if the client's budget is limited, you have to take it into consideration and offer the best value solution.

WHAT ARE THE OPTIONS?

Once you start researching potential solutions, you will realize that you face a dilemma regarding where the big part of biometrics implementation should take place. On the backend, the mobile app or actually somewhere in between?

1. MOBILE APP IMPLEMENTATION

This approach is a very pragmatic and fast solution especially in cases when one does not want to rely on your backend counterpart's implementation. There can be many reasons: a limited client's budget, time sensitivity when the backend team is focused on another feature or just no need for a complex solution.

How does it work? Upon the user's first signup or login, we can store the user's credentials securely on the mobile device (iOS Keychain or Android Keystore). To achieve this, we can utilize, for example, the react-native-keychain library that allows us to hide the sensitive data behind biometrics authentication. Once a user's authenticated session expires, we offer a biometrics challenge and, if successfully passed, we retrieve the stored credentials to initiate a login API call.

This solution is not very sophisticated and therefore has some drawbacks. For example, if the mobile application complements a website where the user can change or reset his/her password, the next mobile login request after biometrics authentication will fail and we will need to ask for the user's credentials again.

Security might also be quite a concern because the user's credentials are stored on a mobile device, which is not considered best practice. The react-native-keychain library warns that the data could even be easily decrypted on devices running older than the Android 6.0 operating system. Use this option for fast implementation and simple flows where security is not the highest priority.

2. BACKEND IMPLEMENTATION

Having backend implementation allows us to utilize an extra layer of security, which is desirable for applications that want to go the extra mile in securing users' data.

The solution that offers itself is utilizing an RSA algorithm by creating a public/private key pair on the device when biometric authentication gets enabled. One way is to keep the private key securely on the device while the public key travels to the backend and is saved under the particular user. Note that one user can have multiple devices, meaning multiple public keys.

Source: android-developers.googleblog.com

As the diagram shows, upon biometric authentication (step 3) the private key signs a piece of data, sends it to the backend (4) and then the backend uses the paired public key to verify the data and sends back the result (5). In case of a login action, it will return an access token to initiate a new session. Alternatively, we could generate key pairs on the backend and make the mobile app request the public key. Remember that the private key should not travel.

This way, we shift a big portion of work to the backend, which can lead to much longer delivery time and cost for the client. On the other hand, this approach can be reused in other parts of the application, like approving financial transactions with biometrics — unlike in the first option, where credentials can only be used for a single purpose.

In React Native, this solution is readily available with the react-native-biometrics library, which is, unfortunately, not actively maintained (last commit 2/2020) and its biometrics part does not support the latest standards, such as fallback to passcode when Face ID fails.

To offer the users the best experience, we can implement our approach with two separate libraries: expo-local-authentication for the biometrics part and react-native-rsa-native for the RSA algorithm. Use this option for a more security-focused approach when backend resources are available and the deadline is not a week.

3. COMBINED IMPLEMENTATION

If our application utilizes refresh tokens, we can smartly combine the two previous options together. Upon signup or login, we can store a new refresh token securely on the device using the react-native-keychain library mentioned in the mobile app implementation. Once our session expires, we prompt the user to retrieve the refresh token stored behind biometrics authentication. If the user passes the challenge, we use the refresh token to call the backend and refresh the session/get a new access token.

The big security advantage compared to the first solution is that we don't have to keep the sensitive login credentials stored on the device. Also, backend verification of the refresh token provides certain security aspects we implemented with the second solution.

Overall, this approach is very practical to implement, especially in the case when refresh tokens are already utilized. The only downside is that it has a single purpose of refreshing the user's session.

Summary

While implementing biometric authentication on React Native is definitely not rocket science, time needs to be invested into due diligence to find the best solution that balances important criteria such as security, cost-effectiveness and user experience.

Previously, if you wanted to integrate Plaid React Native SDK to Expo, you either had to forcefully eject to bare workflow or use a webview solution which could result in some funny unexpected issues such as this recaptcha pop up.

Well, in case you have stumbled upon my previous guide to Expo config plugins, you already know that customizing Expo managed workflow is more than possible and therefore, in this tutorial, we will look at a bit more advanced example how to integrate Plaid, a reliable service to connect financial accounts to our app.

SETUP

To get started you can use this Github repository as a starter or just follow these commands:

Initiate a new Expo project - here with typescript for better DX:

expo init expo-plaid-sdk-integration  -t expo-template-blank-typescript

Add the React Native Plaid SDK library:

yarn add react-native-plaid-link-sdk

Update App.tsx to:

import React from 'react'
import { StyleSheet, Text, View } from 'react-native'
import { PlaidLink, LinkSuccess, LinkExit } from 'react-native-plaid-link-sdk'

export default function App() {
  return (
    <View style={styles.container}>
      <PlaidLink
        tokenConfig={{ token: '#GENERATED_LINK_TOKEN#', noLoadingState: false }}
        onSuccess={(success: LinkSuccess) => console.log(success)}
        onExit={(exit: LinkExit) => console.log(exit)}
      >
        <Text>Add Account</Text>
      </PlaidLink>
    </View>
  )
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center'
  }
})

And include iOS bundleIdentifier and Android package name of your choice to app.json:

"expo": {
    ...otherProps,
    "ios": {
        "supportsTablet": true,
        "bundleIdentifier": "com.expo.plaid"
    },
    "android": {
        "adaptiveIcon": {
            "foregroundImage": "./assets/adaptive-icon.png",
            "backgroundColor": "#FFFFFF"
      },
      "package": "com.expo.plaid"
    }
}

If you now try running the application through Expo Go, you will likely see this error...

TypeError: null is not an object (evaluating '_reactNative.NativeModules.RNLinksdk.continueFromRedirectUriString')

...which should be expected.

PLAID INTEGRATION

To start integrating Plaid we will need to run the app through expo-dev-client which we can achieve either by using expo run commands locally or using EAS build process. By building the dev client we will have a custom Expo Go which will add the Plaid library to its bundle, meaning you can use this client until you decide to add again something new that is not supported by it. For simplicity we will stay with the local run commands. Then we just need to follow the Plaid readme setup guide for both iOS and Android.

iOS setup

This is actually super simple. The readme suggests adding to ios/Podfile following string pod 'Plaid', '~> <insert latest version> to pin the latest version, but, in reality, this is optional and we can easily work with the version currently bundled in the library. As a result, the only step we have to do is to initiate the expo-dev-client by running:

expo run:ios

After the build process finishes, the app launches without the error we experienced previously. You can press Add Account and you should see Plaid error complaining about the token we provided - but about that later.

Unexpected environment string value: (null). Expected one of: production, sandbox, or development.

Android setup

If you run expo run:android and press Add Account at this stage, you will get an unhandled promise rejection..

TypeError: null is not an object (evaluating '_reactNative.NativeModules.PlaidAndroid.startLinkActivityForResult')

..because there are actually bunch of steps to make Android work and as the readme suggests it is due to TurboModules not supporting autolinking. But in general this is nothing we cannot setup ourselves with Expo config plugins.

1) Setup your app id

This change you have to do on Plaid Dashboard at the API page - Allowed Android Package. You should configure there the Android package name from app.json - com.expo.plaid.

2) Update MainApplication.java

Here we have to fullfil 2 requirements:

• Add import com.plaid.PlaidPackage; to the imports section
• Add packages.add(new PlaidPackage()); to List<ReactPackage> getPackages();

Which we can do only with an expo config plugin:

Create in the root of your project withAndroidPlaid.ts file and start transpiling it to javascript with this command:

yarn tsc withAndroidPlaid.ts --watch --skipLibCheck

and import it in app.json as a plugin:

{
  "expo": {
    ...otherProps,
    "plugins": ["./withAndroidPlaid"]
  }
}

Finally, change withAndroidPlaid.ts content to following:

import type { ConfigPlugin } from '@expo/config-plugins'
import { withMainApplication } from '@expo/config-plugins'

function applyPackage(mainApplication: string) {
  const plaidPackageImport = `import com.plaid.PlaidPackage;\n`
  const plaidAddPackage = `packages.add(new PlaidPackage());`

  // Make sure the project does not have the settings already
  if (!mainApplication.includes(plaidPackageImport)) {
    mainApplication = mainApplication.replace(
      /package com.expo.plaid;/,
      `package com.expo.plaid;\n${plaidPackageImport}`
    )
  }

  if (!mainApplication.includes(plaidAddPackage)) {
    mainApplication = mainApplication.replace(
      /return packages;/,
      `
    ${plaidAddPackage}
    return packages;
    `
    )
  }

  return mainApplication
}

const withAndroidPlaid: ConfigPlugin = (expoConfig) => {
  expoConfig = withMainApplication(expoConfig, (config) => {
    config.modResults.contents = applyPackage(config.modResults.contents)
    return config
  })

  return expoConfig
}

export default withAndroidPlaid

If you look closely, our plugin is utilizing withMainApplication, a mod provided by Expo allowing us to read and modify the content of MainApplication.java. We provide the content to our function applyPackage where we execute 2 string replacements to insert plaidPackageImport and plaidAddPackage constants into the file - the changes Plaid readme wanted from us.

Our strategy is to simply find a stable part of the file where we can append our changes. Due to the string replacement nature, it is quite dangerous thing to rely on, because they could change with consequent React Native and Expo updates - so be sure these replacements still work when you upgrade.

If you run expo prebuild -p android you should now see updated MainApplication.java. If you did something incorrectly, you may want to discard changes, check your plugin code, and try prebuild again.

3) Update app/build.gradle

We need to update dependencies to following:

dependencies {
    // ...
    implementation project(':react-native-plaid-link-sdk')
}

Which we can do utilizing withAppBuildGradle modifying the file within withAndroidPlaid function.

// ...
expoConfig = withAppBuildGradle(expoConfig, (config) => {
  config.modResults.contents = applyImplementation(config.modResults.contents)
  return config
})
// ...

And applyImplementation is our custom function following the previous strategy of appending plaidImplementation string to the right place of the file.

function applyImplementation(appBuildGradle: string) {
  const plaidImplementation = `implementation project(':react-native-plaid-link-sdk')`

  // Make sure the project does not have the dependency already
  if (!appBuildGradle.includes(plaidImplementation)) {
    return appBuildGradle.replace(
      /dependencies\s?{/,
      `dependencies {
    ${plaidImplementation}`
    )
  }

  return appBuildGradle
}

4) Update settings.gradle

Finally, we have to append following string to settings.gradle:

include ':react-native-plaid-link-sdk'
project(':react-native-plaid-link-sdk').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-plaid-link-sdk/android')

Which can be done using withSettingsGradle Expo mod:

expoConfig = withSettingsGradle(expoConfig, (config) => {
  config.modResults.contents = applySettings(config.modResults.contents)
  return config
})

And making the changes with our custom applySettings function. Notice that we are just concatenating the strings with plus symbol given that we don't really care about the exact placement of plaidSettings constant.

function applySettings(gradleSettings: string) {
  const plaidSettings = `include ':react-native-plaid-link-sdk'
  project(':react-native-plaid-link-sdk').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-plaid-link-sdk/android')`

  // Make sure the project does not have the settings already
  if (!gradleSettings.includes(`include ':react-native-plaid-link-sdk'`)) {
    return gradleSettings + plaidSettings
  }

  return gradleSettings
}

If you lost track of the changes or applied them incorrectly, you can always go to the solution branch of this github repository for my final implementation.

Troubleshooting: I have discovered 2 potential issues when implementing Plaid on Android, so if you are facing build errors or your app is crashing, you might find an answer in these github issues: Kotlin version and OkHttp version.

After applying all necessary changes you should just run expo run:android to build the app with all modifications.

Once the build process finishes and the app launches, you can press Add Account and you should see a different Plaid error complaining about configuration - but it is actually about the fake token we have provided.

null - unable to open link, please check that your configuration is valid

Getting the link token

At this point, you just need to provide a correct link token in App.tsx. Normally you would get it from your backend, but for testing purposes we can actually use a very handy Postman collection provided by Plaid.

After going through the setup and utilizing your client_id and secret from Plaid dashboard, you can hit https://sandbox.plaid.com/link/token/create API endpoint and use the returned link_token.

{
  "expiration": "2021-12-25T19:49:22Z",
  "link_token": "link-sandbox-965dbc89-14fc-4122-b900-27a562de6db0",
  "request_id": "AEBgG6EbWGsQ9aR"
}

Now pressing Add Account should finally open Plaid interface:

Summary

This integration might feel scary at first, but in the end we are just doing the same thing over and over - inserting a string into a native file during the build time (or prebuild time more specifically). Note that the Expo mods we used are marked as dangerous given that they rely on our custom string replacement rules and you should expect them to break in the future. But for now, they are the best way how to combine the Expo managed workflow and Plaid React Native SDK.

When I was asked to lead Ascension mobile development, leaving The Pump, Arnold Schwarzenegger's official fitness app, felt bit sad, because it seemed like nothing bigger can come after that. Well, I couldn't be more wrong. Releasing Ascension was my biggest success story as a developer, with the application gaining the number 1 spot in the US App Store reference category, reaching the 36th place in the broad US App Store free apps category, gaining over 50,000 registered users within a first 24 hours, and finally keeping rating 4.9+ ⭐️ on both iOS and Android platforms.

Ascension

The client, Ascension Press, is a publisher of Catholic books and digital media, and they have huge amount of digital content, with podcasts The Bible in a Year and The Catechism in a Year, probably being the most popular, especially among the US audience. So popular that The Catechism in a Year was just behind the Joe Rogan Experience in the USA top podcasts. Therefore, the client tasked STRV in building a mobile application to unite all their digital content with the Bible and the Catechism (2 books + 2 podcasts) being the centerpiece of everything.

As you can imagine, this was quite a technical challenge, yet we kept the team reasonably sized with 2 core frontend engineers and 1 core backend engineer to keep the efficiency high. To hit our milestones safely, we would eventually bring +1 for both FE and BE. And as usual, we were accompanied by 1 PM, 1 QA (+1 before the launch), and 1 designer. The application didn't require any strong native integration, therefore React Native was picked to provide the client with fast and efficient development.

Development

Before we could even start developing, we had to figure out the biggest technical challenge - how to display the Bible and the Catechism. We knew we needed interactions such as highlights, taking notes, text resizing, saving last position, cross referencing to certain book sections, which is something eBooks have figured out before us, therefore a Webview implementation with epub.js was considered. But we also needed custom design and ability to dynamically insert certain additional content before or after specific verses/paragraphs to provide even more depth to the original books.

We understood we need an absolute control for the best user experience, so we undertook an epic quest of creating our custom data structure and parsing ePub version of the books with its enormous content into it. And given the "static" nature of the books (in other words, the Bible won't change), it was actually a safe decision allowing storing indexed interactions on the backend, but keeping the content on the frontend and making the books and search for the users offline as default.

Nevertheless, it turned out that there were many more technical challenges we had to face after that and push React Native to its limits.

One of them were long lists of content, React Native's main nemesis. While the Bible chapters are relatively well sized, the Catechism chapters can have over 200 paragraphs. Moreover, we could not display simple text, because the parsed content actually had to include html tags to apply to certain words italics or bold styles, and also to keep <a> tags to custom render footnotes and references to other book sections. The amazing library react-native-render-html helped us tremendously with rendering, but the performance suffered quite a bit. It could have been easily solved by using recycling from Flashlist, but Flashlist is unable to scroll precisely to a specific index when content is not consistently sized, which was a crucial user experience interaction to access the exact last location or navigate to a specific highlight or reference. So we got stuck with Flatlist, which by the way is not great in it either, but is able to make it work when you set initialNumToRender to your desired index, but you can imagine what happens to the JS thread when you set it to 200. Eventually, we made Catechism content more granular, splitting chapters into articles and smartly optimizing our components with memo, which mostly resolved our performance issue. Finally, on top of it we added a skeleton loader to make the user experience even better.

Basically, the application already replicates a fully fledged eBook reader functionality, with some cool features such as scroll up/down to go to previous/next chapters/locations, but again there was much more to build. For example, a fully fledged podcast player with transcripts and a global miniplayer allowing you to navigate the rest of the app while listening.

As big believers in Expo, we started with Expo AV, but we quickly realized we would be missing out on iOS lock screen audio controls and promptly switched to more feature rich react-native-track-player. The library is currently in v4 release candidate status, but it is already stable. The library helps nicely with queueing of audio tracks, progress tracking and each track can carry extra metadata to access anywhere in the app. At the time of writing, the Ascension app has 4 various audio types (the two podcasts, individual Bible Answers tracks, the Bible as an audio book, Bible Studies playlists), so metadata helped tremendously to separate progress tracking/queuing logic for each one of them. Finally the library's documentation is clear and helped us to easily implement an offline listening feature, which all users wanted the most.

As a part of the Bible Answers (1000 pieces of inserted content to certain parts of the Bible - text, images, audio, video), we also implemented a video player using both react-native-video and Expo av. We found that on iOS we couldn't use Expo AV for video, because it was overriding native settings of the audio player and lock screen audio controls would be lost again. Therefore, we switched to react-native-video, but found issues on Android with full screen controls and orientation. That is why we ended up with react-native-video on iOS and Expo AV for videos on Android. React Native at its best 😅. But lets be honest, it is so great to have the option to split the logic based on a platform.

This is already my longest portfolio article, but there is still so many more things to talk about. For example, after two previous GraphQL projects, our backend engineers chose a REST api, therefore React Query was chosen to help with the API management. Given, that with GraphQL you can easily generate types and React Query hooks from a schema, I was searching for a way how to do it with REST. I remembered when I was playing with Supabase 2 years back (public talk), the had types generation thanks to OpenAPI, therefore I persuaded our amazing backend engineer to maintain an OpenAPI schema and used this OpenAPI codegen to generate types and React Query hooks to make the project more maintainable. Eventually, I also migrated the project to a monorepo, so that we could reuse the api and other things on the admin.

Finally, I am just at the bring of launching subscriptions to give users access to even more premium digital content. Revenue Cat has proven to be a great choice for The Pump, therefore I picked it for Ascension as well.

Summary

At the time of writing, the Ascension project is still ongoing and there is still so much more content to incorporate into the app. Besides new features, Ascension constantly monitors feedback (among other smart things their amazing team does) from the users, who are generally bit older, so they bring valuable insights, how to make the app easy to use for everyone.

Over 6 weeks since the launch (28 June, 2023), we have already gathered over 10,000 ratings on iOS and 2,600 on Android, still keeping the rating 4.9+ ⭐️ on both platforms.

When I transitioned from my Financial Markets career to Frontend development, I expected to leave the world of finance behind. Yet, as it turned out, I could not escape that easily 🤔. My first three projects at STRV were all related to finance by pure coincidence. Besides Rich Uncles (a REIT investment platform, renamed to Modiv) and Stride Health (an insurance platform), I also worked on Bitcoin IRA, a platform that allows you to invest in cryptocurrencies using your retirement account.

Obviously, for each developer it is very helpful to understand the context of the client's business, because while developing new features you are able to predict possible edge cases and actually shift the client to the right direction by understanding both the business logic and possible hurdles in development. So all in all, it was a good way how to start my career at STRV.

Bitcoin IRA

At the time (August 2020), Bitcoin IRA already had a working web application in React, so it made sense to expand the offering for a mobile solution using React Native, allowing client's engineers to eventually pick up React Native and maintain both applications. At STRV, our team consisted of two React Native engineers, one PM, one QA and one designer, with backend provided by the client. Especially having own STRV designer is always a big win resulting in faster development thanks to a consistent design system and well structured Figma files. You can see the simple and clean designs in the official STRV case study here.

Development

This was officially my first React Native project, therefore, as it used to be during my financial career, I just surrounded myself with various information sources to consume lots of React Native knowledge quickly (Youtube, Twitter, podcasts, Reddit, Github repos) and apply it to the project. Eventually after 3-4 months of development, my senior colleague moved to a different project and I was left to finish the project on my own. This was a great experience and source of many lessons I documented in my article about the transition from React to React Native. The biggest lesson was obviously successfully launching the application to production, which not every juniorish React Native developer gets to experience that early and learn all the ins and outs of Google and Apple store release management. Thanks to that I got rid of my remaining imposter syndrome and I was able to move on to more challenging projects.

Regarding the tech stack tidbits, it included Redux Toolkit combined with Redux Sagas for a better control of API requests and data flows, which is crucial for each financial application. Unfortunately, React Query was just becoming a thing and it was too risky to bet on it and as a newcomer to React Native I didn't have enough leverage to push for it. From a hindsight, it would make the development much easier and more maintainable. Especially polling for updated asset prices during a trading flow would be a piece of cake with React Query.

Similarly, forms are crucial for financial apps and Formik & Yup were the best to offer for form handling and validation at the time, but these projects became quite hard to maintain for the community with Github issues piling up, therefore I eventually refactored everything to more agile React Hook Form & Zod, which both have became my go-to and battle tested forms solution.

Finally, to boost security and improve user experience, among other measures, biometric authentication was implemented, which eventually made me to document it and share lessons in one my first public talks.

Summary

Checking the 4.5⭐️ rating on both AppStore and Play Store, I am very happy with the outcome of my first React Native project. Staying eventually alone on the project was a crucial test for myself and I am glad I was able to eventually release the project to the client's satisfaction. Also this was an era before Expo and EAS became our go-to at STRV, therefore I had an opportunity to get hands dirty with native code changes, React Native upgrades and certificates management - a valuable lesson some developers might not get to experience with Expo these days.

After three financial projects in a row, I was sure something new is around the corner. Almost correct 🙂.

Nutiliti

Nutiliti started as an application allowing flatmates to split utility bills (by percentage or a fixed amount) by simply connecting their credit cards and Nutiliti would handle the rest - basically charging everyone its bill portion. Over 6 years studying and working in the UK, I had 19 different flatmates (London to blame 🤦‍♂️, people just come and go), so I could see it working by removing the hassle to chase everyone to pay their part.

At the time (September 2021), Nutiliti had already launched their React Native application to the AppStore, but it was bit rushed to capture the upcoming new school year tenancy changes. Therefore, at STRV we were tasked to bring the application to a more stable state, launch the Android version, extend the payment options to include bank accounts and more.

The client gave me full autonomy to work on the React Native application, so I jumped into the codebase, added STRV code quality tools (ESLint, Prettier, Husky, lint-staged) and started the refactor. Luckily the code base was already mostly in typescript, so it went quite fast.

Because the backend was in GraphQL, as the next logical step I implemented automatic code generation for types and Apollo Client queries and mutations hooks. All this made the codebase much more maintainable and easier to work with.

The application consisted of a lengthy onboarding flow to gather all the necessary tenancy information, so this was a great candidate for E2E testing implementation. At the time, Detox was the best choice for the task.

All above was possible only thanks to the client's CTO, who understood the importance of code quality and testing for long-term success, and was willing to invest into it. STRV is one of the most expensive agencies out there (but worth every penny!), so you can imagine it is hard to persuade clients to invest into refactors and almost impossible to find clients who would actually propose it themselves.

It is also worth mentioning that the client started the application in Expo, a React Native framework that we avoided at STRV for a long time due to its limitations. However, I knew it was the turning period for Expo, which introduced a modern set of tools such as expo-dev-client and Expo Application Services, basically allowing to build React Native applications with any native customization you would like via Expo Config Plugins and making the build and submit processes super easy. Therefore, as a first to try at STRV, I went all in Expo and after this successful experience I have been evangelizing it to my colleagues and others ever since. Many of it is mentioned in my yearly React Native at STRV reviews (2022, 2023).

Finally, as mentioned, one of the most important features was to implement bank account payments, which was a great opportunity to learn about the Plaid API, which we already used in Rich Uncles, but I was not involved in that part of the project. And because React Native Plaid SDK required native changes, it was a great opportunity to implement an Expo Config Plugin and write an article about it.

Summary

Working solo at Nutiliti's React Native application was a huge learning experience and especially it uncovered for us at STRV the new possibilities Expo brings to the table. Now basically all projects are built with Expo and we are loving it. Also, my Expo Config Plugin articles have become the most popular among my blog readers, because at the time besides main documentation there was literally no other source of information than my 2 articles. I am feeling bit guilty they have become bit outdated, but hopefully the approach I taught is still helpful!

As far as Nutiliti goes, the app has 4.7⭐️ rating in the AppStore and 4.0⭐️ rating on Android. The app is focused on the USA and a younger target group (students, early professionals), so it is not surprising there are only 9 reviews on Android vs 98 on iOS. Also, Nutiliti has become so much more than when I left to a different project in May 2022. These days they partner with property managers and offer many new features such as energy provider switching. I wish them best of luck, because they are a great team and I am sure they will succeed!

Sometimes you have to be just on the right place at the right time. Not even three years into my career as a frontend developer, together with my fullstack colleague, we were assigned to build an official mobile fitness application for Arnold Schwarzenegger himself. STRV is a top agency with presence both in San Francisco and Los Angeles, so sometimes big names come around, especially in the fitness area, which is manifested in STRV's own love for fitness and its top-floor gym.

Arnold’s team was looking for a first solution that could be delivered quickly (basically 3 months over Summer 2022) and altered on the go to incorporate feedback from beta testers and then later from first users. React Native’s speed of development, flexibility and cross-platform nature made it a perfect fit for the project.

The Pump

The Pump is not only a fitness app but also a closed community of Arnold’s fans, who can interact with Arnold via discussions in motivational articles the app offers. It is for everyone, not only bodybuilders but also for total fitness beginners, with tailored workouts for each difficulty level, gender, equipment (body weight, gym) and fitness goal (get big, get shredded).

What makes it truly standout is the combination of retro and modern bold design, a true masterpiece from our designer Bara, and you can read all about it in STRV's design article and also in the official case study. As usual, our team was also accompanied by a product manager and a QA engineer.

Our team at STRV's gym

Development

We knew we have to build the application fast, therefore an idea to use backend as a service was brought up. After dismissing Firebase due to potential Firestore vendor lock-in, and Supabase due to its relatively early nature not tested on a fully-fledged product by us, we decided to go with AWS Amplify from Amazon. But after 2 weeks of development, we realized that our data heavy application requires a lot of custom logic, which made the implementation of Amplify more complex and slower than building a standard backend solution with full flexibility on our side. For our Node BE, besides top DX choices such as Prisma and GraphQL, we also utilized Railway for the first time, and all in all, my fullstack colleague quickly caught up and replicated our Amplify data structure.

On the React Native side, we had lots of UI to build. Luckily, our designer was utilizing consistent spacing and typography, therefore I knew I could use a theme strict solution such as Restyle from Shopify to its full potential. After setting the theme and text variants up, the app was almost building itself.

Besides GraphQL as our data layer, on the client side I also utilized Zustand and MMKV to persist active workout data the user would be filling in. Zustand wins over React Context with its capability and over Redux with its simplicity, and MMKV is a better alternative to AsyncStorage thanks to its synchronous nature and better performance.

The Pump is a subscription-based application with a lifetime membership option as well, therefore I chose RevenueCat as our battle tested payment solution. All in all, a great experience, but once your application includes also the lifetime membership option, you have to be careful with the way you implement it. It is an in-app purchase rather than a subscription, so obviously you should make the user cancel their subscriptions first before buying a lifetime membership and also if they own one, then they should not be able to buy any subscriptions. Many things you don't have to consider when offering just subscriptions and I felt RevenueCat could do bit more to document this use case.

Finally worth mentioning, after successful experience on Nutiliti, starting the project with Expo was an obvious choice, proving that any native customization can be done via Expo Config Plugins and Expo Application Services are the best in class for building and submitting React Native applications.

Summary

After the first version of the app was finished in September 2022, as it happens in the agency development, I moved to the Ascension project and my fullstack colleague Michal stayed to gave the app few more final touches until the client took over the maintenance of the project. The app was eventually released in April 2023 hitting the TOP 20 in the US Health & Fitness AppStore category and selling out all 5000 lifetime memberships within 72 hours. Current rating is 4.4⭐️ on both iOS and Android and the app is currently accessible via an invite only, most likely still in the stage to gather and incorporate feedback from its first founding users.

At STRV offices

Cost-saving is usually the most apparent benefit, given that — on a typical project — a single engineer is able to work on an iOS and Android app simultaneously. The same goes for an application’s post-launch maintenance and new feature development; at this point, the client normally needs to find two native engineers to get familiar with the codebase and start working on the project. In the case of cross-platform development, the client only needs one.

Nevertheless, due to high demand, finding a really good React Native engineer is definitely not an easy task these days. Therefore, the math is not that simple, and 1 does not always equal 2.

1 ≠ 2

Not all applications are a great fit for React Native and that is why, at STRV, each application proposal is closely reviewed by our Frontend (React Native), iOS and Android departments to determine whether native or cross-platform development is the best fit. It is not uncommon for clients to approach us with a request for a complex React Native application and us suggesting native development instead, to ensure client and project success. On the other side of that, our Android and iOS departments sometimes suggest React Native on less feature-intensive projects to benefit from cross-platform development.

The State of React Native

To follow up on the statements above, it is worth mentioning that React Native is not just for simple applications. The framework is battle-tested by Facebook and Instagram applications, which regularly appear on the AppStore’s Top 10 Most Downloaded Apps in the US. And, recently, Coinbase — the biggest crypto exchange platform and a heavy React Native user — nabbed the #1 spot on the list. There are many other leading companies using React Native; you can learn more on the React Native website.

Among those companies, Microsoft has started investing in the framework, with Skype and Office applications now written in React Native. And not only has Microsoft taken an active part in the new React Native versions’ release process, but it’s also been developing react-native-windows — a library to ease the development of desktop apps for both Windows and macOS. A great example of a successful approach is the rewrite of Facebook’s Messenger desktop app from Electron, the current cross-platform desktop go-to solution, to React Native. This goes hand in hand with React Native’s Many Platform Vision. Some of the main motivations were also described in a recent React Conf 2021 talk.

Trends

Shift to Expo

Looking at the applications currently under development at STRV, we have seen a major shift towards Expo, a React Native framework that tries to abstract out manipulation of native iOS and Android code to allow web engineers with knowledge of React to build mobile apps without major roadblocks. We were quite skeptical about Expo; just a year ago, I suggested that you can’t build a professional application with it. Oh, how things change in frontend development…

The truth is that of our two new React Native projects, both are Expo applications. In both cases, the codebase was already bootstrapped by the client, so it was not exactly our choice — yet we’ve seen major improvements in the Expo ecosystem, which is why we decided to stay open-minded and give it a go. Additionally, keeping what’s best for our clients in mind, ejecting a project from the start would mean adding complexity with which the clients’ internal engineers might struggle in terms of productivity.

To add perspective, we generally had two big problems with Expo projects. The first was that whatever features you needed, once you shipped your application, Expo would bundle all its features with it — meaning that the resulting application size would be a minimum of 50MB, regardless of its simplicity.

The second was that, when integrating a package that was not part of the Expo environment, you would have to start managing everything Expo was doing previously for you — a painful process previously called “**ejecting.**” Therefore, it always made sense to build pure React Native applications from the start to offer the best customization for our clients and a small application size for their users.

Neither of the arguments above holds true anymore. First, Expo introduced the Expo Application Services (EAS) build system, which bundles only features your application actually uses. Once we migrated a client's app from the previous Expo build system to EAS, the iOS application size dropped by 63%, from 70MB to 26MB.

Secondly, the changes in the build system enabled customization of Expo applications with a new config plugins environment. Now, whenever we need to customize our React Native project the way traditional Expo would not allow us to, we can write an Expo config plugin that will do the customization for us. On my current project, I have five essential config plugins (three of my own, two community-driven) and another two from the community I use for development — proving that without customization, one would have to either eject from Expo or make sacrifices on certain features.

Moreover, EAS tremendously helps with credential management for submitting applications to app stores, which is a common pain point for a React Native engineer who has to learn specificities for both iOS and Android store submissions. Not everyone has the luxury of having colleagues from native departments nearby to offer their expertise (like we do at STRV).

Overall, Expo has made a huge leap forward in 2021 and I believe that slow convergence towards Expo will benefit the previously split community of React Native engineers who would develop only in Expo versus those who would prefer full control and would not give it a chance (which used to be our case). Standardization of React Native applications should also help the clients, making it easier to find and hire the right engineering candidates who will be maintaining the application and its codebase.

Competition

There’s been quite a big hype around Flutter, a cross-platform framework by Google. Its popularity has been growing rapidly, even catching the attention of our Android department. These days, it is quite common to compare React Native to Flutter, with each side elevating its favorite framework. Yet the truth is that competition only benefits everyone.

I believe that both frameworks can thrive and learn from each other. It might be a good thing that React Native is not the only major cross-platform player, should something extreme happen — like Apple considering limiting the presence of cross-platform applications.

For us, React Native is a battle-tested cross-platform solution that provides our clients a familiar codebase to work with. But we have also started actively utilizing Kotlin Multiplatform, an elegant cross-platform solution that allows our Android and iOS departments to share the business logic part of the codebase, offering time-saving and consistency across both applications.

Looking Ahead

We have many things to be excited about in the React Native ecosystem. The major evolution coming in 2022 is most likely a release of a new rendering system called Fabric, which has been in development since 2018 and, by the way, is already powering over 1,000 screens on your Facebook application.

Overall, React Native’s new architecture promises even better performance and application start-up times. A big part of this will also be Hermes, a javascript engine optimized for React Native originally built to speed up Android applications. Recently, it got the support of iOS and is on track to become the new default.

The new architecture release will coincide with React 18 bringing Suspense, a data fetching evolution that has been in the works for a few years. Together with Suspense, the new architecture will allow applications to not only be faster but feel faster.

The React Native community is also very active, and one of the most exciting projects within the space is React Native Skia, an implementation of Skia — Google’s 2D graphics engine powering Flutter applications (proving my point about competition benefits). Hopefully, we may see a stable release this year, allowing engineers to utilize new drawing capabilities and shift some graphics from less performant SVGs to Skia.

Another community project to watch is RePack, a toolkit bringing Webpack — a module bundler — and its powerful ecosystem to React Native. It’s a much-needed competition to Metro, the current default bundler solution that has not seen a significant improvement compared to new web-based bundlers.

Finally, I would like to go back to Expo, which we will definitely see growing further. EAS Updates — an evolution of Expo Updates — has just been released to preview, allowing developers to create workflows in which they can update mobile applications “over-the-air” without the need to go through the Apple or Google store review. It’s a total life-saver to instantly fix little bugs.

There are also Expo Modules in the works, which should allow us to write React Native packages in Swift (iOS) and Kotlin (Android). Those are easier programming languages to learn compared to Objective-C and Java, empowering more engineers in bringing native iOS and Android features to React Native.

Summary

React Native has been evolving and it is encouraging to see both Facebook and Microsoft heavily investing in its future. Given its cost-saving potential and codebase familiarity and maintainability, it is an attractive option for those of our clients who frequently consider it as their solution of choice. Yet years of experience in architecting mobile applications and solutions positions us as a company that understands in which cases React Native can truly thrive, thereby letting us ensure the success of our clients’ applications.

One year ago, I wrote a thorough review of the general state of the React Native cross-platform framework and its position at STRV. It’s time for a follow-up.

At STRV offices

Some of my predictions, such as the framework's convergence to Expo and transition to the new architecture, have proven to be easy bets — but what I wouldn’t have predicted is the rise of React Native projects under our Frontend department development.

Over the last year, we have worked on a record 10 React Native projects, which demonstrates the ever-increasing demand from clients matched by our successful hiring.

2022 in Review

Looking back at 2022, there were quite a few notable events to mention.

React Native 0.68

Version 0.68 released in March was the first to include the new architecture opt-in flag, allowing everyone to get a taste of it and for community libraries maintainers to start experimenting with its adoption.

App.js Conference in Krakow

After a long Covid break, the whole community finally gathered in June for a face-to-face conference to exchange ideas, share common struggles and get a peek at the future of React Native. STRV participated and confirmed that our development practices utilize the best React Native can offer.

Personally, I attended a new architecture workshop to get a better understanding of its adoption timeline. It was clear that it will be a bumpy road for the community since it’ll take at least two years before the architecture reaches wider adoption — but the commitment from Meta to support library maintainers going through the transition was reassuring.

We also attended an animations and React Native Skia workshop to up our skills in building performant and interactive user experiences, and to understand Skia’s capabilities.

Worth mentioning is that as a conference partner, Expo established itself as a React Native leader and re-introduced its new features, many of which we’d already been utilizing on STRV projects and which I also wrote about in my last article.

But the announcement that stole the show was the introduction of Shopify’s Flashlist, a drop-in and significantly more performant replacement for the infamously slow Flatlist. The community’s excitement was like nothing I’d ever seen before; nobody had been expecting someone to provide a solution for one of the most common React Native issues — slow long lists — just like that, even before the new architecture had arrived.

Expo Router

Another great innovation came from Expo in September in the form of Expo Router’s initial beta release. File-based routing is a feature that web developers take as a given; almost every major frontend framework supports it — yet only now, with Expo Router, can we utilize it to scale projects on mobile. I believe there are many more web features the router will unlock for mobile development but, most importantly, it will likely become an essential tool in building shared navigation between mobile and web in case of multi-platform applications.

How Can We Improve React Native?

One positive surprise came in October, when Meta opened up an active discussion among the React Native community to figure out the biggest pain points, with core contributors to the framework acknowledging the issues and providing necessary visibility into their action plans. I believe the community finally feels heard and that this step strengthened the overall relationship between developers and Meta — especially during the crucial transition to the new architecture, where we just have to trust it will unlock the benefits we were promised.

Other Developments

Also notable was the ever-increasing adoption of React Native, with Discord, Replit, Steam and Starlink apps echoing most among the programming community. Even the Windows 11 Settings app is now using React Native, proving the framework's capabilities in what was otherwise a largely uneventful year for desktop support, with Microsoft remaining the leader in the space.

And finally, at the end of 2022, we got our first State of React Native survey. As I write this, the results are still pending.

Looking Ahead

New Architecture

2023 will be the year of a full-speed transition of common libraries to the new architecture. Yet as far as wider adoption among developers is concerned, I expect that to come in 2024.

The current Expo SDK 47 — together with the new Expo Modules API — is paving the way for the seamless creation of libraries with support for the new architecture in mind, so I wonder how many maintainers will be tempted to abandon their existing solutions, choosing to create a new one from scratch. One common library, React Native Pager View, decided something in that sense. Better than stitching together a new compatibility upgrade, the architecture transition is a good reason to reevaluate the project and start fresh.

This is as exciting as it is worrying. The community will be required to keep a close eye on which versions of the library are still compatible with the old architecture until all essential ones have transitioned. We can’t use the new architecture unless all dependencies are compatible. One way to find libraries that already support the new architecture is reactnative.directory.

At STRV, we will monitor the community closely to keep ourselves informed so that we can prevent potential incompatibilities on our projects. And with the progressing adoption, we will start building a demo application based on the new architecture to test common functionalities and to serve as a benchmark for our own adoption.

React Native Web Renaissance?

Besides the typical cost efficiency and speed of development reasons, our clients also choose React Native as a mobile solution due to its potential to share business logic with the web. Moreover, if there’s already a working website in React, the client's own developers can eventually become the maintainers of the React Native application we deliver.

In cases when we deliver a website (e.g., landing page, mobile app web equivalent, admin), node backend and a mobile application, monorepos have practically become the norm for STRV, with their utilization in many React and React Native projects. While they add complexity early on — especially for new adopters — the investment usually pays off by sharing simple things like various constants, translations and input validation rules, as well as more complex business logic and API.

Yet it’s always tempting to push code sharing even further and utilize React Native capabilities to build both mobile and web applications from a single codebase. While many websites already utilize the solution, developers working on those projects usually face problems and complexities trying to make their code performant, compatible, functional and accessible on all platforms. As you can imagine, these developers are usually not the happiest ones and actually, their retention becomes a big risk given their mobile and web know-how accumulation.

React Native Web is a good representation of all the high hopes developers put into React Native; yet instead of them being fulfilled, it has often led to misuse of the framework — resulting in many developers getting burned and vowing not to touch it again. But with the latest innovations around the corner, even the hardest deniers may come back to give it one more chance.

At STRV, we reevaluate the multi-platform approach every year and scan the landscape for solutions that would make it easier to develop and maintain. Though still too early for production, 2023 finally feels like we may experience the React Native Web renaissance with new solutions for sharable routing and UI. The above-mentioned Expo Router has the potential to provide unified routing for both web and mobile, and the recent release of Tamagui v1.0 offers a performant, shareable UI and styling solution. Moreover, React Native 0.71 brings many web and mobile API unification improvements, answering the community’s demand for reduced compromises which are inevitable when building web with React Native. Let’s try and see.

All-in-Expo

At STRV, we’ve pretty much moved all React Native development to the modern Expo set of tools, starting with Expo dev clients and config plugins for bringing any iOS or Android dependencies, all the way to Expo Application Services (EAS) — allowing fast builds and credentials management. While I wrote about it as a trend for 2022, 2023 shows that it’s undeniably become the most efficient way to build a React Native application.

With a clearly defined path forward, our team will finally be focusing on establishing best practices and a knowledge base for React Native development, subsequently sharing it with our team members.

More Conferences & Meetups

In 2023, the community will benefit from two face-to-face conferences: App.js (May 10-12) in Krakow, which is expected to be a blast like last year, and Chain React (May 17-19) in Portland, Oregon, which is returning after a long break.

Thanks to the high demand for React Native projects, we have also decided to share our newly gathered know-how and organize two meetups ourselves, one in Brno (Feb. 14) and one in Prague (Feb. 16).

Everything Else

React Native Skia has been actively developed and this year, we might get V1 and see bigger adoption. The new architecture is expected to unlock many innovations, from much faster Android and iOS builds to even faster list libraries, such as WishList. Bundling in React Native has been ripe for innovation and it finally seems that the default Metro bundler will get improvements. Expo-image is going to bring modern image formats and loading techniques the web has utilized for years already. All in all, speed is the common denominator.

Summary

While the longevity of frontend technologies is always in question, React Native is here to stay. With strong investments from Meta, Microsoft and Shopify, the best is yet to come. In the current macroeconomic situation, React Native’s cost efficiency and speed of development are ever-attractive for our clients, yet one still has to be realistic and expect potential compromises and limits — which native iOS and Android solutions just do not have to face. That is why we are so excited about 2023 when, once again, many of those limits and compromises will be broken.

What was your first year like when you started your coding career? I remember it went quite smoothly for me, and I jumped onto a project pretty early on. It was an ongoing project—so time to market wasn't a key factor—and I got great support from my colleagues. But let's face it: With older projects, you mostly deal with bugs, optimizations and continued refactoring, plus some features here and there.

Refactoring did actually keep my motivations high by opening up a path for learning how to write better code. Yet as a junior dev, it is essential to try new things to get a greater perspective; that's what helps you answer questions about your career, coding preferences or favorite libraries—which is the core of most fun arguments with your colleagues.

Therefore, when I hit one year in my coding career, it was a proper challenge and blessing in one when a new project came around—specifically a React Native (RN) project. Just like that, together with my senior colleague, I started building a new mobile app for iOS and Android using my web development skills. Meaning that my previous article should be renamed to How I Left a Financial Markets Career for Web Frontend Development. And, as in the previous article, this experience has come with plenty of lessons worth sharing.

GETTING STARTED

While the React Native coding environment feels quite familiar to a React developer, you actually lack the knowledge of what you are able to build with your skills. Here is where the afore-mentioned greater perspective comes into play; as a developer, you need to broaden your horizons—otherwise, you are risking living in your small bubble, fearing change and getting stuck.

Learning

Perpetually finding myself in somewhat of a "code newbie" mindset, I know that there are certain gaps in my coding skills that I need to fill.

I always prefer learning by actually seeing someone building something. At the time of this project, my favorite tutor, Mosh Hamedani, had released his React Native course (free YouTube preview), so I signed up for it and built my first app. Besides the app building and his coding tips, the great thing about Mosh's course is that he walks you through the setup of Xcode and Android Studio, which are needed for using mobile device emulators/simulators. You want to get this right. But do not worry, we can still write our code in, for example, VSCode.

Another great tutor, The Net Ninja, has a free course also worth checking out. And finally, I've discovered William Candillon, who is a big guru in the React Native community especially thanks to his "Can it be done in React Native?" YouTube series. While William is mostly focused on animations, around that time he also started a series called "React Native Fashion", where he builds an app from scratch based on designs in Figma—which is very close to the real developer experience, so check it out!

Expo vs. React Native CLI?

You will find that almost all tutorials, be it the ones from YouTube or Medium, will use Expo, a framework and set of tools for building React Native applications. Its "managed" workflow prevents and eases many headaches React Native developers face. Expo apps are super easy to set up and are made available on your mobile device through a simple Expo client, meaning it skips the App Store and Play Store in the process. This is obviously a great choice for a tutorial or an MVP, but is it good for a professionally built app?

For now, it usually isn't! Expo does not allow you to touch native Android and iOS modules and, in general, you are locked to their environment — which is very powerful, but the situation is still not ideal. If you'd need something that is not available in Expo, you would have to go through a potentially painful ejecting process. Also worth mentioning is that Expo apps are significantly bigger in size. At STRV, we always use React Native CLI to build apps so that we can provide the best value for our clients' money.

Many tutors and commentators heavily promote Expo and scare new developers by claiming that with React Native CLI, devs will have to touch native iOS and Android modules to get things working. But in reality, those are big scares of the past. Since React Native version 0.60, almost all libraries are auto-linked and you just have to install them with npm or yarn. I imagine that before that time, it was probably a huge headache; but now, already close to version 0.64, things are much better. Though, yes, there are cases when you have to play around with native modules—for example, to set up a splash screen and an app icon—but, again, you are a developer and, sometimes, you need to get your hands dirty. Avoiding difficult things may just create internal anxiety that will surface later.

THE DEVELOPMENT EXPERIENCE

It is different. Once you set up your Android Emulator and iOS Simulator, you can start exploring your code changes—and will soon discover that not everything is as simple as it is in tutorials.

Does It Work on Both Android and iOS?

As a web dev, you check how your app behaves across various internet browsers. In mobile development, you check if things are working in the same way on both Android and iOS. This is important. There are some libraries or component properties that are platform-specific only. Documentation is your friend, so keep it in mind. It can literally be trivial things—like shadow properties that have no effect on Android, because you'll have to utilize preset elevation properties.

How Does It Look on My Old Nexus Versus Iphone 12?

Another parallel is checking for website responsiveness while resizing the browser screen versus checking how your app looks on mobile devices with various screen sizes and pixel density. This can easily lead to misaligned design. If your simulator is big enough and fits all things on one screen, it may require a ScrollView component on a smaller device to allow users to reach all the offscreen content.

Debugging

There are many ways to debug your app by reaching for tools like React Dev Tools, a simple element inspector or a network tab that you're used to. Tools such as React Native Debugger are also quite popular, but they require turning on the 'Remote debugging' mode on your simulator, which I found sometimes interferes with the app and throws weird errors.

With React Native version 0.62 comes Flipper, Facebook's own debugging tool included as a default for you to use. This is great because it works out of the box and you just need to enable plugins for your app to get it working. Maybe the UI is not the nicest you would expect (luckily, it is being improved), but having it built in and not interfering with your app is a great plus.

Also, if your build is failing, sometimes it is worth turning on Xcode and Android Studio to build your app there, as their logs may better point you to what is causing the issue. I know, those tools feel like a blackbox and your working machine will surely start loudly complaining, but some familiarity will pay off. Check, for example, this talk on Xcode.

To be honest, debugging errors will take a long time to get used to. For a novice, it is not always apparent where the error is coming from. And, more importantly, it'll take time to figure out if code changes alone can fix the issue, or if you have to reload—or even rebuild—your app. This can make you lose precious time, which is why I recommend documenting the steps you take when resolving common bugs—that's how you will save time later on.

Fast Refresh

When things are going quite smoothly, something I really enjoy is Fast Refresh, which allows you to see your code changes reflected instantly. Some great news is that this functionality has recently made its way to web development as well.

CODING TIPS

There's quite a lot to consider when you are building a mobile app in React Native after having worked solely in web development. As such, in this section I would like to touch on a few essential topics that you may find helpful.

Styling

All your components are display: flex and flexDirection: column as default, so forget grids and blocks and brush up on your flexbox skills. You will often be tempted to use flex: 1 to make your container fill the whole screen or all available space, which is perfectly fine—but remember that these don't have to play nicely if your component has any animation elements and the device has to recalculate the space. Similarly, another default is position: relative, meaning your absolute elements are positioned relative to their parent.

Forget CSS pseudo-elements and selectors; in React Native, we inline the styles. The recommended approach is to use a StyleSheet object, but I enjoy using Styled Components in a similar way as on the web. If you are a fan of styled systems, Restyle from Shopify is gaining popularity.

You can also choose from several UI kits to get started on your hobby project. Popular ones are, for example, React Native Paper and UI Kitten.

By the way, remember that you don't have semantic HTML elements at your disposal. Most components are View (container) or Text (you cannot use simple text with other components), therefore you may want to think about adding some accessibility props.

Images

You cannot use .svg files as a source for RN's Image component. You will probably end up using pngs, ideally 3x the size to account for iPhones' scale factor—so don't forget to compress it! If you want to use svgs, use React-Native-SVG library and SVGR playground for quick conversion to an RN component.

Animations

You can use the built-in Animated API, which performs well especially when using useNativeDriver: true prop. However, you get the best performance with the React-Native-Reanimated library, which is currently being upgraded to version 2 and expectations are high! Note that this only works with Hermes enabled (see the next section). More sophisticated animations used to, for example, wow users with an eye-catching splash screen, are commonly achieved with Lottie.

Libraries

In general, there are actually many built-in components within React Native. For example, Activity Indicator (loader) that behaves natively on both Android and iOS, or Flatlist, a component used to display and optimize lists of items, a preferred way compared to mapping over an array as we are used to from the web. The trend is to make the RN library lighter, which is why some nonessential ones were moved to React Native Community repo for maintenance.

One important note for Android: As you add more libraries, you may encounter an error that limits you to a certain number of allowed methods. To deal with this, enable Multidex. Another error may come if you enable Hermes, an optimized Javascript engine for running Android apps and, soon, also iOS. While some libraries—like the above-mentioned Reanimated—require it, others are not yet compatible with it (Realm - see below).

Keyboard Avoiding View

No comment. If you've worked with React Native, you get this. It is a topic one would rather skip. When you work with text inputs, you have to account for the keyboard sliding from the bottom, hence we utilize the Keyboard Avoiding View container that is able to adjust itself and make space for the keyboard. Unfortunately, consistency across iOS and Android is not always there, and you will probably end up adjusting Android's windowSoftInputMode at some point to get the best experience.

Landscape Mode

Another unpleasant thing you might face is optimizing for the landscape mode. For most apps, it is common practice to just disable it.

Navigation

To navigate between screens, you will probably end up using the very popular React Navigation library. There is a great, purely native alternative, React Native Navigation (the names get confused easily), from Wix. It is super performant but not that flexible. Therefore, again: If your design asks you for something custom, you have no choice but to go with React Navigation; luckily, it is a great, well-documented option.

Storing Data

The Redux library is quite a common choice thanks to its broad ecosystem. Luckily, there is now a very useful Redux Toolkit that mitigates the amount of boilerplate you have to usually write. RTK Query is a very new Redux solution for data fetching and caching, hopefully making our lives even easier. Though the web seems to slowly be moving away from Redux to React Query, SWR or other solutions, mobile is a different story; Redux is holding on to its popularity, as it integrates well with libraries that persist and rehydrate the global state for users when they relaunch the app.

To persist data on the device, it is common to use AsyncStorage, which is an asynchronous alternative to web's LocalStorage. Another interesting option (though a bit more complex) is to use the Realm database.

Other Mobile Development Considerations

Sooner or later, you will encounter a situation where you need to add permissions to your app; for example, to access the camera and photos library during a file upload. Though not always required, it is common to use the React Native Permissions library to offer a consistent experience across platforms.

Further, mobile devices can lose connectivity easily; for that, you can count on the NetInfo library to offer a user experience while offline. Finally, notifications are an essential part of mobile apps and Firebase offers great React Native integrations.

FINAL WORDS

We live in an amazing time. Our React coding skills can easily transfer from web to mobile to build full-fledged iOS and Android apps. Sometimes, this allows us to offer significant cost savings to our clients in the process. Yet one has to understand that mobile and web development do differ and, to offer a great user experience, it is not only about the code we write.

Experienced mobile app developers can easily smell when something is not right, therefore I insist that you put your ego aside and ask them—be it your colleagues or peers on Twitter or Reddit, or anyone with mobile UX know-how—to review your app and provide feedback. Only with this approach can you progress and apply your skills to build great products.