Building & Publishing
In order to submit to an App Store, we first need to create a build of our application that we can publish. If we were building mobile applications without React Native,we would use the same IDEs that we write native code with to create builds of our application. With applications built with the Expo CLI, we can create standalone builds in two different ways:
- Using the Expo CLI directly
- Ejecting and creating builds manually through Xcode or Android Studio
Both approaches will allow us to generate iOS and Android builds that we can deploy to app stores or play stores. Each approach has its advantages and disadvantages.
Building with Expo
In order to build with the Expo CLI, you need to have an Expo account. You can create one at https://expo.io/signup. Once your account is set up, you can sign in directly through the command line: expo login
The app.json file is automatically generated in the root directory when creating a new project with Expo and allows us to modify a number of build configurations. Although it populates with many fields by default, only a number of attributes are required for a native build.
{
"expo": {
"name": "Online_Shopping",
"slug": "Online_Shopping",
"version": "1.0.0",
"orientation": "portrait",
"icon": "./assets/icon.png",
"splash": {
"image": "./assets/splash.png",
"resizeMode": "contain",
"backgroundColor": "#ffffff"
},
"ios":{
"bundleIdentifier":"com.companyname.appname"
},
"android":{
"package":"com.companyname.appname"
}
}
}
- name: The name of the application that shows on the device home screen for applications installed through an App Store/ Play Store.
- slug: The URL name for published Expo applications. For this configuration,the URL will look like expo.io/user_name/weather.
- sdkVersion: The Expo sdk Version that the application is running with. This needs to match with the installed version in package.json.
- icon: The icon of the application that shows on the device home screen.
- version: The version of your current build.
- ios/android: iOS and Android build-specific configurations. The iOS bundleIdentifier and Android package fields are both unique strings that identify the application and follow a reverse domain naming convention. It is important to make sure a proper name is chosen for both fields, as they cannot be changed once the application is published to an App Store.
Pros and cons of building with Expo
Creating builds with Expo is only possible if we do not plan on including any custom native code. If we need to include any native dependencies in our application, we have to eject and create our builds manually using Xcode and Android Studio. If you have already ejected, then skip right ahead to the “Building Manually” section of this blog. Otherwise, we highly recommend to use Expo as it is a much simpler and quicker build process.The Expo platform supplies a CLI to automate the process of creating a native iOS or Android build of our application. When building for both iOS and Android, signing files are required to identify the author of the application. Expo can automatically generate these files for you. This method allows us to create iOS builds without using Xcode and without owning a Mac computer. However, Xcode is still required to publish the build to the iOS App Store. Another significant advantage of using this approach is over-the-air (OTA) updates. By default, applications published with Expo will always check for updates when launched. If a new version of the app has been published with Expo, the updated build will be fetched and loaded automatically. With this, we can release fixes and updates to our application without going through the process of publishing a new version to the App Store. A drawback of this approach is the limited control it allows over the build process.The final bundled build will include every API provided by Expo, regardless of whether we use them or not. This can result in significantly large build sizes even if the code that makes up our application is relatively small.
*Pros and cons of building manually*
We can create builds of our application using the IDE for each platform, Xcode and Android Studio.The primary advantage of this approach is the capability to add native iOS and Android code to our application. Building manually also allows us to take full control over the build process, and this includes modifying any signing steps and adjusting the final build size ourselves.The downside is that in order to use an IDE to build our app, we have to eject from Expo. This means that we will have to own a Mac computer to create an iOS build.
Creating an iOS build with ExpoIn order to create builds for iOS applications, you need to enroll in the Apple Developer Program. You can either enroll as an individual or an organization. As an individual, apps distributed in the App Store are tied to your personal name. As an organization, apps are tied to a legal entity’s name.Once we have a developer account set up, we can build a native iOS bundle through Expo with the following command: expo build:ios
We are then asked how we would like to handle our credentials:
The credentials here refer to signing certificates and a provisioning profile needed to submit applications to the App Store. We’ll go with the simpler option of letting Expo handle all of the credentials here.Once we have selected the option for Expo to take care of managing our files, we’ll need to submit the ID and password for our Apple Developer Account:
Although we specified we want Expo to handle all credentials, we still have the option to provide overrides for specific certificates. Expo prompts us about these next. We want Expo to handle both:
Next, the build process will begin and a URL is provided (e.g.https://expo.io/builds/unique-id). This URL provides access to the current status of the build and you can follow along by reading its logs.The build process can take a few minutes to complete. Once completed, another URL will be provided that contains the generated .ipa build file. Pasting this link into your browser’s address bar will begin downloading it to your machine.
Creating an iOS build with Xcode
As we mentioned earlier in this article, an account with the Apple Developer Program is necessary in order to create a build ready for distribution. You’ll need to enroll if you haven’t already. Once enrolled, the first thing we’ll need to do is code sign our application. Code signing is the process of using a digital signature to identify the application author’s identity. Signatures are used to ensure that updates to an application are published by the same author.
With Xcode, we have two options for code signing an application:
1. Manually, where we provide all the resources ourselves
2. Automatically, where Xcode takes care of creating all the necessary signing credentials
Automatic code signing is recommended in the Xcode documentation as it simplifies the process of creating all the required assets needed for signing. Xcode takes care of creating all the needed credentials and we only have to provide our developer account without doing more additional work.
With this approach, Xcode will:
- Create the necessary signing certificates
- Create an App ID
- Handle all the provisioning profiles needed
Automatic Code Signing
To access a React Native application using Xcode, we can open the /ios/AppName.xcodeproj file in our project. An Xcode project file (.xcodeproj) contains all the source files and resources needed for building and managing a project with the platform.Once the file is opened with Xcode, you should see your application loaded as the main target. This is what the default dashboard looks like for an open application:
The bundle identifier in the Identity section of the General tab is a required field and is a unique string that identifies your application. Once a build of your application is uploaded for submission, this field cannot be changed. The version and build number fields also need to be completed and will be used by App Store Connect to identify different versions of your application. In the Signing section of the screen, there is a checkbox for Automatically manage signing. After checking this field, a “Team” drop-down is displayed asking for a development team that can be used to associate all the created signing credentials. In order to see your team as one of the drop-down options, you must add an Apple Developer Account to Xcode. You can add this account by opening Xcode Preferences in the main menu. Once a development team is selected, you should see a signing certificate assigned to your developer account. Xcode takes care of creating this certificate along with a provisioning profile and assigns it to your team. With a certificate set up, you can now head directly to the “Creating a build archive” section to create a build of your application.
Manual Code Signing
To begin the process of manually code signing, we’ll need to sign in to the Apple Developer Portal.
The Apple Developer Portal provides links to resources, guides and documentation.There are two important tools provided by the platform that we will be exploring:
• Certificates, Identifiers & Profiles is where we set up signing certificates and profiles for our application to identify them.
• App Store Connect is a collection of tools that allow us to manage and submit application builds to the App Store. Let’s navigate to Certificates, Identifiers & Profiles and begin by creating an appropriate signing certificate. Once we are at the certificates screen, clicking the + icon on the right hand of the screen will allow you to create a new certificate. Make sure iOS, tvOS, watchOS is selected in the dropdown in the left navbar.
Signing certificates are digital signatures used to perform actions while ensuring the application is from the same source and has not been altered with. There are two certificate types relevant to building and distributing an iOS application:
- Development(iOS App Development): Used for the development of an iOS application and limits the number of devices that the application be installed on
- Distribution (App Store and Ad Hoc): Used for the distribution of iOS applications to App Stores or for Ad Hoc distribution
A CSR file is a formatted and encrypted file that contains information that identifies a particular source and is used to issue a certificate. You can follow the instructions provided to save a CSR file somewhere on your computer. Once that’s done, click continue to proceed and upload the file. Once uploaded, you should be able to download the certificate by clicking Download. Double-clicking the certificate file (.cerformat) will save it in your Keychain.
Let’s move on to creating an app identifier. This is also known as the App ID and is a unique string that identifies a single application (or multiple applications) connected to a development team. We can do this by navigating to the iOS App IDs screen by clicking Identifiers/App IDs in the side menu. To register a new App ID, we needto fill out a few fields:
• App ID Description: Any description of your application can be used here, but this is usually the same as the name of the app.
• App ID Prefix: This is your Team ID by default.
• App ID Suffix: By changing the suffix of our App ID, we can choose between its two different types:
* AnExplicit App ID is used for a single application and must be unique. A reverse domain naming convention is commonly used (com.companyname.appname). This option needs to be selected in order to include most application services such as in-app purchases and push notifications. You can see a list of all services that can be enabled/disabled at the bottom of the screen.
* A Wildcard App ID can allow a single identifier and provisioning profile to be used for multiple apps. Many Apple services cannot be included with this type of ID. Since App IDs cannot be changed for an application submitted to the App Store, it is important to ensure that this option is only selected if no such services are included and will not be in the future. An asterisk must be the last character of the ID (com.companyname.*) here.
• App Services: In here, you can select any Apple services to include in your application. Once a certificate and identifier is created, a provisioning profile needs to be setup for the application in order to allow it to be downloaded on physical devices. A provisioning profile is the combination of an application’s unique bundle identifier and a signing certificate. Without a profile, we cannot run an app on a mobile device. A distribution provisioning profile is needed when an application is ready to be distributed to multiple users. To create a distribution provisioning profile, we can click the Provisioning Profiles –> Distribution list item in the side menu and then + on the right hand side of the screen.
Of the many possible options, there are two specific types of distribution profiles relevant to iOS applications:
• App Store: Used to submit an application to the App Store.
• Ad Hoc: Used to distribute applications to multiple testers. Unlike a develop-ment provisioning profile, an Ad Hoc profile can not used to debug applications.
Select App Store to create the profile you need to submit an application to the AppStore. In the next few screens, you will need to select the App ID you just created and the certificates you wish to include in the profile. Once completed, you can name your provisioning profile and download it to your machine.The final step here is to manually assign our created distribution certificate to our project in Xcode. We can open the /ios/AppName.xcodeproj file to do this.
The bundle identifier field must be the same as the AppID you created earlier in the developer console, so you’ll need to make sure that it matches in order to create a successful build. To manually take care of assigning a provisioning profile to our application, disable the Automatically manage signing checkbox. Two newer sections, Signing(Debug) and Signing(Release), will show up underneath. Select the Provisioning Profile dropdown for our signing release and click Download Profile to download the distribution profile directly from the Apple Developer Console. We can do the same for the debug section if we have a development profile created as well.
Creating a build archive
Once all the credentials needed for code signing have been set up, we can create a build archive of our application. We can begin by changing our device target at the top of the screen to Generic iOS Device
The Generic iOS Device target is only used to create an iOS device build. With this target selected, we can select Product Archive to create a build archive. After a few minutes, a window showing all past archives will pop up. Clicking Export on the right hand side and selecting App Store as our method for distribution will allow us to export an .ipa file of our application. Instead of doing this however, we can also submit directly to App Store Connect by clicking Upload to App Store.
Testing the final build
Since we signed the iOS build with an AppStore distribution certificate, it cannot be downloaded and run on a personal simulator/device for testing purposes through Xcode. To allow for this, we can useTestFlight. TestFlight is an Apple platform that allows others to download and test a production build on their devices. Instructions for using TestFlight to invite users to test your production build can be found on the TestFlight website.
Publishing to the iOS App Store
Submitting and managing application builds for iOS can be done in App Store Connect. You can sign in with your developer account.
App Store Connect provides a collection of tools that developers can use to manage their applications, view user analytics, study trends and patterns as well as view financial results. Let’s navigate to My Apps to view a dashboard of all the applications tied to your developer account. Nothing will show here if you haven’t submitted an application before. Click the + icon on the top left to add a new application. We’ll need to fill out a form with a few fields:
• Platform: Select whether you’re creating a new iOS or tvOS application.
• Name: This is the display name of your application in the App Store.
• Primary Language: The main language your application is localized for.
• Bundle ID: The unique identifier for your application. If you let Xcode automat-ically code sign your application or Expo handle creating credentials for you,you should see the ID for your application in the dropdown. If you don’t see it,you may have to create your App ID manually in theDeveloper Portal.
• SKU: This is the Stock Keeping Unit, an identifier commonly used for inventory and financial tracking. It also needs to be unique to each application, and you can use the same string as your bundle ID if you like.
Clicking Create will create our application on the platform.
We can add more general information here such as the application’s subtitle, privacy policy link, and categories. On the left side of the screen, you’ll notice that the current status of our application’s submission process is 1.0 Prepare for Submission. 1.0 refers to the version of the application, and this number will change once we upload newer build versions. Clicking the link in the side menu will navigate to another form that allows us to provide version-specific information of our application.This includes:
• iPhone and iPad application previews and screenshots
• Promotional text
• Keywords
• App description
• App Store Icon
• App review information
All of this information can be modified at any time by submitting updated builds of an application. In the Build section of the screen, you’ll see a message letting you know that you can submit builds directly using Xcode.
Every iOS application that is published to the App Store goes through an extensive review process before being accepted. In Xcode’s Window Organizer screen, you can see a list of previously created build archives of your application. This is what the screen looks like when you have multiple builds:
Before we upload our build archive to the App Store, we can validate it to ensure that our build files pass all the validation checks performed by App Store Connect. We can do this by clicking the Validate button in the menu on the right. If any necessary configurations or assets are missing, Xcode will give us an error here.If our build archive is validated successfully, we can move on to clicking Upload to App Store. After selecting the correct development team, we’ll see an Upload Successful message if there were no issues with the archive. It can take a few minutes for the build archive to show up in App Store Connect. Once it does, you should see it in the Activity tab of the application. Moreover, the Build section of our submission will now show a different message -Select a build before you submit your app.Clicking the link will display a list of available builds.
Once you select your build and complete all the necessary information for your application, you can submit it using the Submit for Review button. According to Apple’s support documentation, review times vary. Half of all applications submitted are reviewed within 24 hours and over 90% are reviewed within 48 hours.The status of the application in App Store Connect will be In Review until it is completed.
Android
As we mentioned previously, you can skip directly to the build approach that is more relevant for your application:
• If you have not ejected your application from Expo, you can read the next section and skip the section that explains how to create a build manually
• If you have an ejected application, skip the following section entirely and head directly to “Creating an Android build manually”
Creating an Android build with Expo
We can start a build process for Android with the following command:
exp build:android
We are then asked if we would like Expo to take care of creating a keystore or uploading it ourselves:
Testing the final build after automatic signing
There are two different ways to test the final build of your application:
1. On an emulator - You can drag and drop the final build.apk to have it boot up automatically.
2. On a physical device - You will have to first install Android Platform Tools to your computer. This includes Android Debug Bridge (adb), a command-line interface that allows you to control an Android device connected to your machine. Once installed, you can run adb install apk-file-name.apk with your device plugged in. After setting up and testing your final application’s build file, you can head directly to the “Publishing to the Play Store” section to learn how to publish your applicationas well as distribute testing versions through different channels.
Creating an Android build manually
In order to code sign an Android application with a certificate, the build process requires a keystore that contains an app signing key. This is done to ensure the source has not changed if any updates are done to the application. There are two different ways to create an Android keystore for an ejected React Native application:
1. Using Java Keytool
2. Using Android Studio
Using Java’s Keytool application can be quicker and is the approach mentioned in the React Native documentation.However, instructions to create a keystore using Android Studio can also be found in the Android Studio docs if you prefer that approach. Keytool is a command-line tool already included in the Java Development Kit that simplifies the management of keys and certificates. It can be used to create a keystore containing an app signing key used to sign an Android build.
For Unix-like operating systems such as macOS and Linux, the keytool directory is added directly to the $PATH variable of our system. This means we can run the command in any directory as an executable. If you are using a Windows machine, you can only run keytool commands in C:\Program Files\Java\jdk1.x.x_xxx\bin where 1.x.x_xxx is the version of JDK installed on your machine.
We can generate a keystore with a single key using the following command in ourterminal:$ keytool -genkey -v -keystore android-release.keystore -alias android-\release-alias -keyalg RSA -keysize2048-validity10000
The command contains a number of settings that would apply to our generated keystore:
• -keystore: The name of the keystore file. In here, the file would be named android-release.keystore.
• -alias: The keystore alias is its unique identifier and is used to code sign theapplication. Our alias here is android-release-alias.
• -keyalg: Defines the algorithm used to create a public-private key pair in ourkeystore. RSA is commonly used, but you can find out about all the possible options in more detail by referring to Java’s cryptography architecture guide.
• -keysize: Specifies the size of the created key.In short, key size is used in cryptography to define the number of bits in a key used in an algorithm. In here, we’ve specified 2048 bits (which represents 256 bytes).
• -validity: The length of time our key will be valid in days. We’ve set our validity to 10000 days here.
Running the command will then prompt for passwords for the keystore and signing key, as well as the Distinguished Name fields for your key. Once provided, an android-release.keystore file will be created in the current directory. Due to the fact that a keystore represents an application owner’s identity, it is extremely important to remember to keep a keystore file secure. If the file is lost, updates to an application in the Play Store cannot be performed and a new app will have to be created and submitted. If the file is compromised or stolen, an attacker can publish a newer version of your application with malicious code. It’s considered best practice to avoid committing a keystore to your version control system, like Git.We need to place our keystore file in the android/app directory of our project. Once that is done, we can configure the Gradle build process by adding our keystore and key information. Properties that modify the build process can be added to the android/app/.gradle/gradle.properties file. Let’s add the following to the bottom of the file:
APP_RELEASE_KEYSTORE_FILE=android-release.keystore
APP_RELEASE_KEYSTORE_PASSWORD=YOUR_KEYSTORE_PASSWORD_GOES_HERE
APP_RELEASE_KEY_ALIAS=android-release-alias
APP_RELEASE_KEY_PASSWORD=YOUR_SIGNING_KEY_PASSWORD_GOES_HERE
Since these properties will need to be referenced in our build file, you can choose any key name for each of these key:value pairs. Once our signing credentials are added to our Gradle properties, we can access them in our build file to complete the signing process. We can apply configurations to the build process by adding them to the android/app/build.gradle file. Default configurations are added to this file as soon as we create a new Android project. Let’s add a signing configuration to the android block within this file underneath our default configurations:
android{
//...
defaultConfig{
//...
}
signingConfigs {
release {
if(project.hasProperty('APP_RELEASE_KEYSTORE_FILE')
){
storeFile file(APP_RELEASE_KEYSTORE_FILE)
storePassword APP_RELEASE_KEYSTORE_PASSWORD
keyAlias APP_RELEASE_KEY_ALIAS
keyPassword APP_RELEASE_KEY_PASSWORD
}
}
}
buildTypes{
release{
//...signingConfig signingConfigs.release
}
}
}
We’ll now need to assign our newly created configurations as the release signingConfig of the build process:
android{
//...defaultConfig{
// ...
}
signingConfigs{
// ...
}
buildTypes{
release{
// ...signingConfig signingConfigs.release
}
}
}
And that completes our signing process! We can now navigate to the android/ directory and bundle our application into a build:
cd android
./gradlew assembleRelease
Starting any Gradle build is done with the Gradle Wrapper, a command-linetool we can use at the root of any Android project with /gradlew task-name.The assembleRelease command will bundle (or assemble) all the core JavaScript code into the final build. This file can be found as a app-release.apk file in the android/app/build/outputs/apk/ directory.
Testing the final build after manually signing
With an Android emulator running or a physical device connected to our machine, we can install a production build of our application with the following command:
react-native run-android --variant=release
Aside from this, we can also publish alpha and beta versions of our app to a closed oropen group of testers before submitting it to the Play Store.
Publishing to the Play Store
In order to publish and manage Android applications with Google Play Console, we’ll need to create a Google Developer account which requires a one-time payment.
Once we launch the console, we can click Create Application to begin the process of submitting an application to the Play Store.The first few fields we need to fill out are the application’s default language and title. Once completed, we land on the Store listing page. This page allows us to specify the content in our app’s listing in the Play Store. Parameters include:
• App description
• Graphic assets such as screenshots, icons and banners
• Application type and relevant category
• Privacy policy link
The left-side menu contains links to other areas of our application such as setting up the price of a paid application,its places of distribution, and its content rating.The App Releases link in the menu is where we can manage uploading the APK builds of our application.We can roll out new builds in a number of different channels:
• Internal test: Used to quickly publish builds for internal testing with a smallnumber of testers.
• Closed (alpha): Used to publish builds for closed testing. This is useful to testyour application with a larger number of privately invited testers.
• Open (beta): Used to publish builds for open testing. Anybody can join thistesting program and provide private feedback to the author of the application.
• Production: Used to publish final production builds to the Google Play Store.
With any of these build tracks, we can upload an APK file by clicking Manage and then Create Release. In here, we have the option of using App Signing by GooglePlay instead of managing our signing keys manually. Enabling this feature will mean that the signing key within the keystore used for your application will be handled as an upload key. If we opt-in to this feature, we will have to publish a new application if our key is lost or compromised.There are a few more note worthy parameters we need to specify. The first is the release name. This is not visible to users and is used to distinguish separate releases in the Play Store. It is recommended to use the version of the APK here or an internal code name relevant to this release.The second is release notes. We use release notes to explain modifications to the app in this release. After this, we can upload the final signed.apk build file (app-release.apk in the android/app/build/outputs/apk/directory) and review our submission before rolling it out! If you decided to roll out a production build, the application should show up in the Play Store in a few hours.
Expo supports over-the-air (OTA) updates by default. Every standalone application built with Expo will know how to reference updates to an application based on its URL (expo.io/user_name/APP_NAME). Once an Expo-built application is published to the iOS App Store or Google Play Store and installed on a user’s mobile device, we can distribute any updates to the application using the following command: expo publish This command allows us to publish directly with Expo. When the app is re-launched on a user’s device, the new version of the application will be automatically down-loaded and displayed. With this, we can publish newer updates without distributing new build versions to app stores.
OTA updates only work when JavaScript code is modified. We cannot use this feature if we eject to a regular React Native project.we need to be careful to not publish newer JavaScript code over-the-air that bridges functionality to native modules.
