Running a detached Expo app? Follow these tips for a smoother developer experience.

Expo has been a liberating product for our development team. While some of the team has native iOS or Android experience, an even greater number have developed mobile-responsive and hybrid applications. PhoneGap and Ionic were the early players in the space, but the declarative model provided by React and the growing ecosystem of mobile support via React Native has certainly encouraged explosive growth in mobile development. Expo builds on what React Native offers to further enhance productivity and has been utilized on our professional and personal projects.

The landscape for building native mobile apps with JavaScript is still fairly immature and the workflows require manual (often tedious) processes to achieve feature parity with a native iOS or Android application, e.g., supporting lower-level features such as Bluetooth (although support is planned) and advanced WiFi controls. The workflow for enabling this type of development in Expo is been known as being “detached” from the core Expo experience. In late February, Expo updated the framework to alleviate some of the headaches associated with managing a detached project. The equivalent workflow going forward is referred to as “bare.” Since many projects will be utilizing older SDKs and tooling, some of these notes are still relevant for upgrading the Expokit SDK for your app.

The documentation for upgrading your application is constantly improving and some of these steps may become obsolete later in 2019.

General Steps

In our personal experience, creating a fresh Expo project, detaching and copying the original project’s source files is smoother than updating the SDK in-place.

  1. Expo project setup
    1. $ expo init {slug}(name should be the well, slug, in your current app.json).
    2. Choose a template based on your preference.
    3. Choose the advanced flow (this is the detached experience) and configure the nameandroid.package and ios.bundleIdentifier. Use the same values from your existing app.json.
    4. Answer Y/n for Yarn depending on your preference. If you choose n, you will need to run $ npm i to install the project dependencies.
  2. Copy original source files such as static assets (JavaScript, images, fonts). Do not forget any configuration files for tools such as Babel, Eslint, Jest, et al.
  3. Begin grabbing configuration values from package.json. This will have your project’s dependencies, optional tooling configuration (Jest, Babel, Eslint, etc.) and script commands.
  4. Comb through the original app.json and port values over to the new file. (Note: between SDK updates, this file structure may change, so this is a good chance to read the docs on possible configurations.)
  5. If not done already, run $ npm i to get all dependencies.
  6. (iOS only) From the project root, go into the ios folder and reinstall pods, $ cd ios && pod install . This step may require an update to CocoaPods and the CLI output is typically helpful for guidance.
  7. Go back to the project root folder and run $ react-native link to link up native dependencies with the JS code.

iOS Steps

  1. Open the Xcode workspace file. Copy over Assets.xcassets to update the app icon and launch image. This may require a minimal effort in manually updating the files to get it set back up correctly.
  2. Copy the entitlements file, if used. This will declare some special permissions that the app requires for approval in the App Store.
  3. Update signing credentials (Projects → General → Signing) and select the proper values.

Android Steps

  1. Android seems to have more build changes between updates. A handy method for comparing the build steps is to use a Git diff tool, e.g., $ git difftool origin/develop android to compare the changes in the android directory against the develop branch. It is important not to loose any custom build configurations that are required outside of the provided structure from Expo’s detach scripts.
  2. Correct android.defaultConfig.versionCode  and android.defaultConfig.versionName in android/app/build.gradle.
  3. Copy any modifications to files such as MainActivity.java into the new project.
  4. Copy any image assets for the launch screen/icon.

Wrapping Up

At this point, your project should be ready to start testing locally. Unexpected issues may arise, e.g., Babel 7 is used in SDK 32 and our project was configured with Babel 6.x.

The steps listed here are not exhaustive, but they should provide a primer for general steps to consider when upgrading the Expo SDK for your project.

Have any questions or need help building a React Native mobile app? Get in touch.