Generating Android APK/AAB and iOS Build Artifacts in React Native

Course: React Native Training

Topic: Generating Android APK/AAB and iOS Build Artifacts

Course Link: React Native Training Course

Demo Link: Register for a Free Course Demo

Training Provider: JustAcademy

1. Introduction to Mobile Build Artifacts

React Native allows developers to build Android and iOS applications using JavaScript or TypeScript and React components. During development, the application is commonly executed through a development server, emulator, simulator, or physical device. Before the application can be distributed to testers or published in an app store, it must be prepared as a production build.

A build artifact is a generated file or collection of files produced by the build process. It contains the compiled application code, required resources, application metadata, and other components needed for installation or distribution.

For Android, common distribution artifacts are APK and AAB files. For iOS, the primary distribution artifact is an IPA file, while Xcode also produces an application bundle and intermediate build products.

1.1 Learning Objectives

• Understand the difference between development builds and production builds.
• Learn the purpose and structure of Android APK and AAB files.
• Generate a signed Android APK for testing or direct distribution.
• Generate an Android App Bundle for Google Play distribution.
• Understand iOS build artifacts and the IPA format.
• Configure Android signing credentials and iOS code signing.
• Manage app identifiers, version numbers, build numbers, and environment settings.
• Understand how to build React Native applications with Gradle and Xcode.
• Troubleshoot common build, signing, and packaging errors.
• Prepare production-ready artifacts for testing and release.

1.2 What You Should Know Before Starting

• Basic React Native components, navigation, and application structure.
• JavaScript or TypeScript fundamentals.
• Basic terminal commands and package management.
• Android Studio, Android SDK, and Gradle fundamentals.
• Xcode and iOS project fundamentals for iOS builds.
• Application identifiers, environment variables, and release configuration.

2. Understanding Development Builds and Release Builds

2.1 Development Build

A development build is intended for active development and debugging. It may use a development server, debugging tools, development-specific configuration, and additional logging.

• Supports rapid code changes and debugging.
• May depend on Metro during development.
• May include debugging utilities and development-only behavior.
• Is not automatically suitable for public distribution.

2.2 Release Build

A release build is prepared for testing, distribution, or publication. The JavaScript bundle and native resources are packaged according to the release configuration, and the application is signed using the appropriate credentials.

• Uses release build settings.
• Includes the production JavaScript bundle when required by the build configuration.
• Uses the configured application identifier and version.
• Applies release signing and packaging rules.
• Should be tested without relying on a development server.

2.3 Comparison

3. Understanding Android APK and AAB Files

3.1 What Is an APK?

An Android Package Kit (APK) is an installable package for Android devices. It contains compiled code, resources, assets, a manifest, and other files required by the application.

An APK can be installed on compatible Android devices, subject to Android security settings, signing requirements, device compatibility, and any applicable distribution restrictions.

Common uses of APK files:

• Installing a release build on a test device.
• Sharing an application with an internal testing team.
• Testing a release build outside the Play Store.
• Distributing an application through an approved enterprise or private distribution channel.

3.2 What Is an AAB?

An Android App Bundle (AAB) is a publishing format designed primarily for app-store distribution. It contains the compiled code and resources needed for Google Play to generate optimized APKs for different devices and configurations.

An AAB is generally uploaded to Google Play rather than installed directly on a device like a conventional APK. Google Play uses the bundle to deliver the appropriate APK components to each supported device.

Benefits of AAB:

• Supports device-specific delivery of resources and native components.
• Can reduce download size for users by avoiding unnecessary resources.
• Supports Play Feature Delivery for appropriately configured applications.
• Fits the standard Google Play publishing workflow for new applications.

3.3 APK vs AAB

3.4 Which Format Should You Choose?

• Choose APK when you need an installable file for a test device or an approved direct-distribution workflow.
• Choose AAB when preparing an Android application for Google Play publishing.
• Generate both when your release process requires a store bundle and a separate installable testing package.

4. Preparing a React Native Project for Release

Before generating production artifacts, verify that the project builds correctly and that release configuration is complete.

4.1 Verify the Project Structure

A typical React Native project contains files and folders such as:

MyReactNativeApp/
├── android/
│   ├── app/
│   │   ├── build.gradle
│   │   └── src/
│   ├── build.gradle
│   ├── gradle/
│   └── settings.gradle
├── ios/
│   ├── MyReactNativeApp.xcodeproj/
│   ├── MyReactNativeApp.xcworkspace/
│   └── Podfile
├── src/
├── App.tsx
├── package.json
└── package-lock.json

The exact structure varies with the React Native version, package manager, native dependencies, and whether the project uses Expo or the React Native Community CLI.

4.2 Install Dependencies

From the project root, install JavaScript dependencies using the package manager used by the project.

# npm
npm ci

# Yarn
yarn install --immutable

Use the command supported by your package manager and lockfile. For Yarn versions that do not support --immutable, follow the appropriate installation command for that version.

For iOS projects that use CocoaPods, install the native dependencies from the ios directory:

cd ios
bundle exec pod install
cd ..

The bundle exec form is appropriate when the project manages CocoaPods through a Gemfile. Otherwise, use the CocoaPods workflow configured for your project.

4.3 Run Basic Validation

• Confirm that the application starts successfully in development.
• Resolve TypeScript errors, lint errors, and failing tests where applicable.
• Verify navigation, forms, network requests, and local storage.
• Check images, fonts, icons, and other packaged assets.
• Verify production API URLs and environment-specific settings.
• Ensure no private keys, passwords, or unnecessary debugging endpoints are included.
• Confirm that required permissions are justified and correctly configured.

4.4 Inspect Git Changes

Review the files that will be committed before starting the release build.

git status
git diff --check
git diff

Do not commit keystores, signing passwords, API secrets, provisioning credentials, or private certificates to a public repository.

5. Android Release Configuration

5.1 Configure the Application ID

The Android application ID uniquely identifies the application in the Android ecosystem. It is commonly configured in the app-level Gradle file, although the exact location and syntax can vary by Android Gradle Plugin and React Native version.

Example in android/app/build.gradle:

android {
    namespace "com.example.myapp"

    defaultConfig {
        applicationId "com.example.myapp"
        minSdkVersion rootProject.ext.minSdkVersion
        targetSdkVersion rootProject.ext.targetSdkVersion
        versionCode 1
        versionName "1.0.0"
    }
}

This is an illustrative Groovy Gradle example. Kotlin DSL projects use build.gradle.kts and different syntax. Follow the structure already present in your project.

Important considerations:

• Use a stable, unique application ID for the production application.
• Do not change the production application ID casually after publishing.
• Use appropriate identifiers for development, staging, and production variants if required.
• Ensure the package identifier matches the intended app-store listing.

5.2 Configure Version Code and Version Name

Android uses two important version values:

• versionCode: An integer used by Android and app distribution services to identify the release sequence.
• versionName: A human-readable version shown to users or distribution tools.

defaultConfig {
    versionCode 2
    versionName "1.0.1"
}

For each new Play Store release, increment the version code according to the applicable publishing requirements. Update the version name when the product version changes.

5.3 Configure SDK Versions

Android projects specify SDK-related values such as the minimum SDK, compile SDK, and target SDK. These values influence device compatibility, compilation, and platform behavior.

• minSdkVersion: The minimum Android API level supported by the application.
• compileSdkVersion: The Android API level used when compiling the application.
• targetSdkVersion: The API level against which the application declares that it has been tested, affecting platform compatibility behavior.

Use versions supported by your React Native release, native dependencies, and Android build tools. Confirm current Google Play target API requirements before publishing.

5.4 Verify the Android Manifest

The Android manifest declares important application information, components, permissions, and other platform settings. Review the manifest and any manifests contributed by native dependencies.

• Check application label and launcher icon settings.
• Review internet and other required permissions.
• Confirm deep links and intent filters.
• Verify exported component requirements for supported Android versions.
• Remove permissions that the application does not need.
• Check network security settings and cleartext traffic configuration.

6. Creating an Android Release Keystore

Android release artifacts must be signed. A release keystore contains a private key and certificate used to sign the application. Protect the keystore and its passwords because losing access to the required signing key can complicate future updates.

6.1 Generate a Keystore

One way to generate a keystore is with the Java keytool utility included in a JDK installation.

keytool -genkeypair -v \
  -storetype JKS \
  -keystore my-release-key.keystore \
  -alias my-key-alias \
  -keyalg RSA \
  -keysize 2048 \
  -validity 10000

This command prompts for keystore and key information. Use organization-approved values and follow current platform signing recommendations. Store the resulting keystore in a secure location outside version control.

6.2 Store Signing Credentials Securely

Typical signing configuration uses values such as:

• Keystore file path.
• Keystore password.
• Key alias.
• Key password.

Do not place real passwords directly into a tracked Gradle file. Use environment variables, local untracked properties, or your CI/CD platform's secure secret storage.

6.3 Configure Gradle Signing

The following is an illustrative Groovy Gradle configuration. Adapt it to the current project template and avoid assuming that all React Native versions use identical Gradle settings.

android {
    signingConfigs {
        release {
            if (project.hasProperty("MYAPP_UPLOAD_STORE_FILE")) {
                storeFile file(MYAPP_UPLOAD_STORE_FILE)
                storePassword MYAPP_UPLOAD_STORE_PASSWORD
                keyAlias MYAPP_UPLOAD_KEY_ALIAS
                keyPassword MYAPP_UPLOAD_KEY_PASSWORD
            }
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release
            minifyEnabled false
        }
    }
}

In this example, the release build references Gradle properties. The names must be defined in a secure, untracked configuration or supplied by the build environment. Production projects may enable code shrinking or other optimizations after verifying that the configuration works with their dependencies.

6.4 Signing Security Checklist

• Keep the keystore in a protected backup location.
• Restrict access to release signing credentials.
• Never commit passwords or private signing material to source control.
• Use a secret manager or protected CI/CD variables for automated builds.
• Document the approved signing and key-recovery process.
• For Google Play App Signing, understand the distinction between the upload key and the app-signing key managed by Google Play.

7. Generating an Android APK

In a standard React Native Community CLI project, Gradle can generate a release APK. Confirm that the Android environment is configured and that the release signing configuration is valid before running the build.

7.1 Open a Terminal

Navigate to the React Native project root:

cd MyReactNativeApp

7.2 Build the Release APK

On macOS or Linux:

cd android
./gradlew assembleRelease

On Windows Command Prompt:

cd android
gradlew.bat assembleRelease

The command runs the Android Gradle build and attempts to create the release APK. A successful build depends on correct SDK, JDK, Gradle, dependency, and signing configuration.

7.3 Locate the APK

In a typical Android project, the generated APK is located at:

android/app/build/outputs/apk/release/app-release.apk

The exact filename and directory may differ if the project defines product flavors, custom output names, or multiple APK variants.

7.4 Install the APK on a Connected Device

Enable the appropriate device developer settings, connect the device, and confirm that Android Debug Bridge (ADB) recognizes it.

adb devices
adb install android/app/build/outputs/apk/release/app-release.apk

If the same application is already installed with a different signing certificate or an incompatible package identifier, installation may fail. Uninstalling the existing application can remove its local data, so back up anything important before doing so.

7.5 Verify the APK

• Confirm that the APK exists and has a plausible file size.
• Install it on a compatible test device.
• Launch the app without running Metro.
• Test navigation, images, API calls, notifications, and other critical features.
• Check logs for crashes or missing native libraries.
• Verify that the installed application shows the expected version and icon.

8. Generating an Android App Bundle (AAB)

For a standard React Native Android project, the Gradle bundleRelease task generates an Android App Bundle.

8.1 Build the Release Bundle

On macOS or Linux:

cd android
./gradlew bundleRelease

On Windows:

cd android
gradlew.bat bundleRelease

8.2 Locate the AAB File

A typical output path is:

android/app/build/outputs/bundle/release/app-release.aab

The output name may change when flavors or custom Gradle settings are used.

8.3 Why AAB Is Used for Google Play

When an AAB is uploaded to Google Play, Play can generate device-specific APKs and deliver the relevant components. This can reduce unnecessary downloads and supports modern Play distribution features.

8.4 Test the AAB Before Publishing

An AAB is not ordinarily installed directly using adb install. To test its generated APKs, use a supported tool such as bundletool or a Google Play testing track.

A simplified bundletool workflow may look like this:

# Generate an APK set from an AAB
java -jar bundletool.jar build-apks \
  --bundle=android/app/build/outputs/bundle/release/app-release.aab \
  --output=app-release.apks \
  --mode=universal

# Install the generated APK set
java -jar bundletool.jar install-apks \
  --apks=app-release.apks

Depending on the signing setup and bundletool version, you may need to supply signing information or use the appropriate device-specific options. Treat universal APK generation as a testing convenience, not as a replacement for testing Play's normal device-targeted delivery.

8.5 Upload to Google Play Console

1. Open the appropriate application in Google Play Console.
2. Create or select the intended testing or production track.
3. Upload the release AAB.
4. Review the app signing, version, compatibility, and policy checks.
5. Resolve blocking errors and review warnings.
6. Complete the release notes and required declarations.
7. Submit the release for the appropriate review or rollout process.

Publishing requirements and available tracks can change. Follow the current Play Console guidance for the specific application.

9. Android Build Variants and Product Flavors

Android projects can define build types and product flavors to produce different application variants. This is useful when a project has development, staging, and production environments or separate branded editions.

9.1 Build Types

• Debug: Used mainly for development and debugging.
• Release: Used for production-oriented packaging and distribution.

9.2 Product Flavors

Product flavors can vary the application ID, app name, API configuration, resources, and other properties. A project might have flavors such as staging and production.

For example, a project may expose Gradle tasks with names similar to:

./gradlew assembleStagingRelease
./gradlew assembleProductionRelease

These tasks are only available if the corresponding flavors and build types are defined. Do not copy the example task names without checking your Gradle configuration.

9.3 Avoid Environment Mix-Ups

• Verify the API endpoint before each build.
• Use distinct identifiers for side-by-side staging and production installations.
• Check the application name, icon, and environment label.
• Ensure production builds do not expose debug menus or test credentials.
• Record which Git commit and configuration produced each artifact.

10. Understanding iOS Build Artifacts

React Native iOS applications are built using Xcode and Apple's build tools. iOS distribution relies on Apple's signing, provisioning, and distribution requirements.

10.1 What Is an .app Bundle?

An .app bundle is a directory package containing the built application executable, resources, metadata, and other required files. Xcode produces this bundle as part of the build process.

10.2 What Is an IPA File?

An IPA is an iOS application archive used for supported installation and distribution workflows. It packages the application in a format used by Apple distribution tools and channels.

10.3 Common iOS Build Outputs

10.4 iOS Build Requirements

• A compatible Mac computer.
• A supported version of Xcode.
• Required Apple SDKs and command-line tools.
• Installed React Native JavaScript dependencies.
• CocoaPods and native dependencies when required.
• A valid Apple developer signing setup for the intended distribution method.
• An appropriate bundle identifier, version, and build number.

11. Preparing the iOS Project for Release

11.1 Open the Correct Xcode Project

React Native projects that use CocoaPods commonly have an Xcode workspace. Open the workspace rather than the project file when the workspace is present and required.

open ios/MyReactNativeApp.xcworkspace

Replace the example project name with the actual workspace filename. If the project does not use CocoaPods, follow its native project setup.

11.2 Set the Bundle Identifier

The bundle identifier uniquely identifies the iOS application. In Xcode, select the application target and review the identifier under the target's signing or general settings.

Example:

com.example.myapp

The bundle identifier should match the intended Apple developer configuration, provisioning profile, and App Store Connect application.

11.3 Configure Version and Build Number

iOS typically uses two related values:

• Version: The user-facing release version, often called CFBundleShortVersionString.
• Build number: The build iteration, often called CFBundleVersion.

Example values:

Version: 1.0.0
Build:   2

Use a consistent release numbering scheme. Each uploaded build must satisfy Apple's current versioning and build-number requirements.

11.4 Review iOS Deployment Target

The iOS deployment target defines the minimum iOS version supported by the application. Check that it is compatible with your React Native version, installed native dependencies, and product requirements.

Increasing the deployment target may exclude older devices. Changing it should be a deliberate compatibility decision rather than a way to hide an unrelated build error.

11.5 Review Info.plist

The application's Info.plist contains configuration metadata used by iOS. Depending on the project, some values may be generated or managed through Xcode build settings.

• Check the display name and bundle metadata.
• Verify permission descriptions for features such as camera, microphone, photo library, or location access.
• Review URL schemes and associated domains where applicable.
• Check orientation and supported device settings.
• Confirm that privacy-related declarations match actual application behavior.

12. iOS Signing and Provisioning

Unlike a typical Android APK workflow, iOS distribution requires Apple code signing and, for many distribution methods, appropriate provisioning configuration. Exact requirements depend on the distribution channel and account setup.

12.1 Code Signing

Code signing helps verify the identity associated with the signed application and protects the integrity of the signed code. Xcode manages much of the signing workflow when automatic signing is configured correctly.

12.2 Apple Development and Distribution Credentials

• Development signing: Used for development and supported device-testing workflows.
• Distribution signing: Used for supported release distribution workflows.
• Provisioning profile: Associates the app identifier and signing configuration with the intended distribution method and, where applicable, permitted devices.

The exact certificates and provisioning requirements differ by distribution channel. App Store distribution, ad hoc distribution, enterprise distribution, and development testing should not be treated as interchangeable.

12.3 Automatic Signing in Xcode

1. Open the iOS workspace in Xcode.
2. Select the application target.
3. Open Signing & Capabilities.
4. Choose the correct development team.
5. Verify the bundle identifier.
6. Enable automatic signing if appropriate for the workflow.
7. Resolve certificate, profile, and entitlement errors.

12.4 Manual Signing

Some teams use manually managed certificates and provisioning profiles for repeatable or controlled release workflows. In that case, ensure the selected profile, signing identity, bundle identifier, and entitlements match.

12.5 Protect Apple Credentials

• Store certificates and private keys securely.
• Restrict access to App Store Connect and developer-account credentials.
• Use a secure CI/CD secret store for automated signing.
• Never commit private keys, passwords, or sensitive provisioning material to a public repository.
• Document certificate renewal and access-recovery procedures.

13. Generating an iOS Release Build with Xcode

13.1 Select the Appropriate Scheme

Open the iOS workspace in Xcode and select the intended application scheme. Confirm that the scheme uses the appropriate configuration and target for the release you want to produce.

13.2 Choose a Generic iOS Device Destination

For an archive intended for distribution, select an appropriate generic iOS device destination rather than relying on an iOS simulator destination. Simulator builds and device distribution builds are different workflows.

13.3 Create an Archive

1. Select the application scheme.
2. Choose the appropriate release configuration.
3. Confirm bundle identifier, version, build number, and signing settings.
4. Select Product > Archive.
5. Wait for Xcode to complete compilation and packaging.
6. Review the result in the Organizer window.

The archive is commonly saved under Xcode's archives directory. Its location can vary based on Xcode settings and the selected build environment.

13.4 Export the Archive

In Xcode Organizer, select the archive and choose the distribution workflow that matches the intended destination. Xcode guides you through signing, export options, and validation.

For App Store distribution, follow the current App Store Connect upload workflow. For other distribution methods, choose only the option appropriate to your developer account, app, and target audience.

14. Generating iOS Artifacts Using the Command Line

Xcode's command-line tools support repeatable build automation. The following examples are templates; replace the workspace, scheme, archive path, and export options with values from the actual project.

14.1 List Available Schemes

xcodebuild -list -workspace ios/MyReactNativeApp.xcworkspace

This command helps identify the available schemes and targets in the workspace.

14.2 Archive the Application

xcodebuild \
  -workspace ios/MyReactNativeApp.xcworkspace \
  -scheme MyReactNativeApp \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -archivePath build/MyReactNativeApp.xcarchive \
  archive

The command attempts to produce an archive for a generic iOS device destination. Signing configuration, team selection, dependency setup, and Xcode version can affect the result.

14.3 Export an IPA

IPA export commonly uses an export-options property list. Create the file using settings appropriate to the intended distribution method and the installed Xcode version.

xcodebuild \
  -exportArchive \
  -archivePath build/MyReactNativeApp.xcarchive \
  -exportPath build/ios-export \
  -exportOptionsPlist ios/ExportOptions.plist

When the export succeeds, inspect the export directory for the IPA and any associated files. The export options must match the archive, signing configuration, and intended distribution workflow. Do not assume that one universal ExportOptions.plist works for every app or Xcode release.

14.4 Understand Build Output Locations

With Xcode, the output location depends on the archive path, derived-data settings, and export path. In automation, use explicit output directories and preserve logs to make builds easier to reproduce and diagnose.

15. Using React Native with Expo EAS Build

React Native projects created with Expo may use Expo Application Services (EAS) Build to generate Android and iOS builds in a managed cloud build environment. This can reduce the need to configure native build tools locally, although project configuration and credentials are still important.

15.1 When EAS Build Is Useful

• When the project uses Expo's build workflow.
• When cloud-based builds are preferred.
• When a team needs repeatable build profiles.
• When the project requires configured native dependencies or custom native code supported by its Expo workflow.

15.2 Install or Use the EAS CLI

npm install --global eas-cli
eas --version

Use the version and installation approach recommended for the project. Authenticate when required by the selected EAS workflow.

15.3 Configure Build Profiles

A simplified example of an eas.json configuration is shown below. Adapt the settings to the project, EAS schema, and intended distribution method.

{
  "build": {
    "preview": {
      "distribution": "internal"
    },
    "production": {
      "autoIncrement": true
    }
  }
}

This example illustrates profile separation only. Internal distribution settings, Android artifact formats, iOS credentials, and production behavior should be explicitly reviewed for the project.

15.4 Build Android Artifacts

# Example preview build
eas build --platform android --profile preview

# Example production build
eas build --platform android --profile production

For a store-oriented Android build, configure the profile to generate the appropriate AAB or APK. The artifact format depends on the EAS profile and build configuration.

15.5 Build iOS Artifacts

# Example preview build
eas build --platform ios --profile preview

# Example production build
eas build --platform ios --profile production

iOS builds require appropriate Apple signing and distribution configuration. Depending on the profile, the output may be intended for internal testing or app-store distribution.

15.6 Download and Verify the Artifact

After the build completes, obtain the artifact through the EAS build result or dashboard. Confirm the platform, profile, version, and signing setup, then test the artifact through the distribution method for which it was created.

Do not mix commands from the Expo EAS workflow with Gradle or Xcode workflows without understanding which build system manages the project and its native configuration.

16. Production JavaScript Bundling and Asset Handling

A standard React Native production build normally packages the JavaScript bundle and required assets into the application. This allows the application to start without relying on the development Metro server.

16.1 JavaScript Bundle

The production bundle contains the JavaScript or compiled application code required by the React Native runtime. The native build system and React Native configuration determine how the bundle is generated and included.

16.2 Static Assets

Review the following assets before generating a release artifact:

• Application icons and splash-screen resources.
• Images referenced by the application.
• Custom fonts and their registration.
• Localized strings and resource files.
• Native libraries and platform-specific assets.

16.3 Avoid Development-Server Dependencies

Test the release artifact with Metro stopped. If the application fails to start, inspect the build logs, bundle configuration, asset references, and native runtime logs.

16.4 Validate Environment Configuration

Ensure the generated artifact uses the correct environment-specific configuration. Do not assume that variables from a local development shell will automatically be included in a native release build.

• Verify production API endpoints.
• Remove test accounts and development-only settings.
• Do not embed private server secrets in client-side code.
• Check feature flags and analytics configuration.
• Confirm that release logs do not expose sensitive user data.

17. Optimizing Build Size and Performance

Build size affects download time, installation experience, and storage use. Optimization should be measured and tested rather than applied blindly.

17.1 Android Optimization

• Review native dependencies and remove unused packages.
• Consider R8 or other supported code-shrinking configuration when appropriate.
• Validate ProGuard or R8 rules for native libraries and reflection-based code.
• Use Android App Bundles for Google Play's optimized delivery workflow.
• Compress and resize large images when visual quality permits.
• Inspect APK or AAB contents using supported Android build tools.

17.2 iOS Optimization

• Remove unused assets and unnecessary native dependencies.
• Review image dimensions and asset formats.
• Use appropriate release build settings.
• Verify that architecture and deployment settings match supported devices.
• Keep dSYM files needed for crash symbolication.

17.3 JavaScript and Asset Optimization

• Use efficient image sizes and appropriate formats.
• Avoid shipping unnecessary development tools in production.
• Reduce duplicated dependencies where practical.
• Profile application performance on representative physical devices.
• Test startup time, navigation responsiveness, and memory use.

17.4 Measure Before and After

Compare release artifact sizes, application startup times, and important user flows before and after making optimizations. A smaller artifact is not automatically a better release if the change introduces crashes or removes required functionality.

18. Testing Release Artifacts

A successful build only confirms that the configured build process completed. It does not prove that the application works correctly on real devices or meets store requirements.

18.1 Functional Testing

• Launch the app from its installed icon.
• Test sign-in, sign-out, registration, and account recovery.
• Test navigation and deep links.
• Check API requests, loading states, and error handling.
• Test forms, validation, and keyboard behavior.
• Check offline behavior and network recovery.
• Verify notifications and permission-dependent features.
• Test image upload, file access, and camera features if applicable.

18.2 Test on Physical Devices

Emulators and simulators are useful, but release artifacts should also be tested on representative physical devices. Hardware, OS versions, permission prompts, performance, and native integrations may behave differently.

18.3 Test Clean Installation and Upgrade

• Install the artifact on a device that does not already have the app.
• Verify the initial setup and onboarding process.
• Where possible, test an upgrade from a previous production-like version.
• Confirm that stored data and migrations behave correctly.
• Verify that app signing and package identifiers permit the intended upgrade path.

18.4 Test Without Development Tools

Confirm that the application launches and functions with the development server stopped. This is especially important for React Native applications that have been developed primarily using a local Metro server.

18.5 Validate Store Readiness

• Check app name, icon, screenshots, and listing information.
• Verify privacy declarations and permission use.
• Confirm version numbers and build numbers.
• Review crash reports and known issues.
• Confirm that signing and distribution settings are correct.
• Check current Google Play or Apple submission requirements.

19. Common Android Build Errors and Solutions

19.1 Useful Android Diagnostics

# Run a release APK build with detailed output
cd android
./gradlew assembleRelease --stacktrace

# Run a release AAB build with detailed output
./gradlew bundleRelease --stacktrace

# Check connected devices
adb devices

# Inspect device logs
adb logcat

Use the Windows Gradle wrapper filename when building on Windows. Review logs carefully and remove credentials or private information before sharing them.

20. Common iOS Build Errors and Solutions

20.1 Useful iOS Diagnostics

# List schemes and targets
xcodebuild -list -workspace ios/MyReactNativeApp.xcworkspace

# Build the release configuration
xcodebuild \
  -workspace ios/MyReactNativeApp.xcworkspace \
  -scheme MyReactNativeApp \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  build

These commands are examples and may need additional signing or project-specific options. When diagnosing failures, start with the earliest relevant error rather than focusing only on the final generic build-failed message.

21. Artifact Naming, Storage, and Release Management

A release artifact should be easy to identify, trace, verify, and recover. Consistent naming helps developers, testers, and release managers avoid installing the wrong build.

21.1 Suggested Artifact Naming

MyApp-Android-1.0.0-102-release.apk
MyApp-Android-1.0.0-102-release.aab
MyApp-iOS-1.0.0-102-release.ipa

These are suggested filenames, not mandatory platform formats. The Android version code and iOS build number may follow different numbering rules. Keep the naming convention aligned with your team's release process.

21.2 Maintain a Release Record

For every production artifact, record:

• Application name and platform.
• Application version and build number or version code.
• Git commit or source revision.
• Build profile and environment.
• Build date and build system version.
• Signing and distribution method, without storing secrets in the record.
• Test results and known issues.
• Artifact location and checksum.

21.3 Calculate a Checksum

A checksum can help verify that an artifact has not changed during transfer.

# macOS
shasum -a 256 MyApp-Android-1.0.0-102-release.apk

# Linux
sha256sum MyApp-Android-1.0.0-102-release.apk

Use an equivalent trusted checksum tool on Windows if required. Compare the resulting value with the checksum recorded by the build or release process.

21.4 Store Artifacts Safely

• Use access-controlled artifact storage.
• Keep signed release artifacts and relevant symbols according to retention policies.
• Back up required signing materials securely.
• Do not place release credentials alongside publicly accessible artifacts.
• Preserve logs and build metadata for troubleshooting and audits.

22. Automating Builds with CI/CD

Continuous Integration and Continuous Delivery (CI/CD) pipelines can automate testing, artifact generation, signing, storage, and distribution. This improves consistency and reduces manual release errors.

22.1 Typical Pipeline

1. Check out the approved source revision.
2. Install JavaScript and native dependencies.
3. Run linting, type checks, and automated tests.
4. Configure the correct environment and version numbers.
5. Load signing credentials from a secure secret store.
6. Generate the Android APK or AAB.
7. Generate the iOS archive and export the required artifact on a compatible macOS runner.
8. Run artifact checks and automated smoke tests where supported.
9. Store artifacts, logs, checksums, and build metadata.
10. Publish to the approved testing or distribution channel after required approval.

22.2 CI/CD Security Practices

• Use protected branches and release approvals.
• Limit which workflows can access production signing credentials.
• Avoid printing secrets in build logs.
• Pin or control dependency versions where appropriate.
• Use trusted build runners and restrict artifact access.
• Rotate credentials according to organizational policy.
• Keep build configuration separate from secret values.

22.3 Example Release Checklist for Automation

Release Pipeline:
1. Checkout source
2. Install dependencies
3. Run quality checks
4. Configure release version
5. Load signing secrets
6. Build Android artifact
7. Archive and export iOS artifact
8. Validate outputs
9. Store artifacts and checksums
10. Publish to the approved testing channel

This is a high-level pipeline outline, not a complete CI configuration. Actual steps depend on the chosen CI provider, project setup, platform credentials, and release policy.

23. Security and Privacy Before Distribution

Mobile artifacts are distributed to user devices, where client-side code and resources may be inspected. A release build must not be treated as a secure place to store server-side secrets.

23.1 Protect Secrets

• Never embed private server keys or database administrator credentials in the application.
• Use a backend service to protect privileged operations.
• Keep signing credentials outside the repository.
• Use environment configuration carefully because client-side values can be extracted.
• Review logs and error messages for personal or confidential data.

23.2 Review Permissions

Request only the permissions required by the application. Ensure permission descriptions accurately explain the feature and that the app handles denial gracefully.

23.3 Review Network Security

• Use HTTPS for production network communication.
• Do not disable certificate validation as a quick fix.
• Review Android network security configuration.
• Review iOS App Transport Security settings.
• Confirm that production services use the intended endpoints.

23.4 Check Third-Party Libraries

Review native dependencies, licensing, supported platform versions, and known security issues. Remove unused packages and rebuild the application after making dependency changes.

24. Practical Example: Preparing a React Native App for Release

Assume a project called ShopMobile is ready for a release candidate. The team wants an Android APK for internal testing, an Android AAB for Google Play, and an iOS IPA for a supported distribution workflow.

24.1 Step 1: Verify the Project

npm ci
npm test

Run the checks available in the project's package scripts. Confirm that all required dependencies are installed and that the app works before generating the release artifacts.

24.2 Step 2: Update Release Metadata

For example, the team chooses the following release metadata:

These values are illustrative. Follow each platform's versioning rules and the application's existing release history.

24.3 Step 3: Generate the Android APK

cd android
./gradlew assembleRelease

Locate the APK in the configured release output directory and install it on a test device.

24.4 Step 4: Generate the Android AAB

cd android
./gradlew bundleRelease

Locate the AAB and validate it using the intended testing workflow before uploading it to Google Play Console.

24.5 Step 5: Archive and Export iOS

Open the iOS workspace in Xcode, confirm the release scheme and signing settings, create an archive, and export the appropriate IPA using the selected distribution method.

24.6 Step 6: Perform Release Testing

• Install the Android APK on a physical device.
• Test the AAB using bundletool or a Google Play testing track.
• Distribute the iOS build through the approved testing channel.
• Test login, navigation, network requests, and key user journeys.
• Verify that production configuration is active.
• Inspect crash logs and record the test outcome.

24.7 Step 7: Archive Release Evidence

Store the approved artifacts, build logs, checksums, version metadata, and test results in the team's controlled release storage. Keep sensitive signing materials in a separate secure location.

25. Common Mistakes to Avoid

• Using a debug APK as the final production release without verifying the release workflow.
• Uploading an APK when the intended Google Play workflow requires an AAB.
• Assuming an AAB can be installed directly using adb install.
• Forgetting to increment the Android version code or iOS build number.
• Changing the production application ID or bundle identifier unintentionally.
• Using the wrong signing key or provisioning profile.
• Committing keystores, passwords, or private certificates to Git.
• Testing only on an emulator or simulator.
• Assuming a successful compilation guarantees a working release.
• Leaving the app dependent on the Metro development server.
• Shipping staging API endpoints or test credentials.
• Ignoring app size, native dependencies, or platform compatibility.
• Failing to preserve crash-symbol files and build metadata.
• Publishing without reviewing current app-store policies and submission requirements.

26. Best Practices for Production Build Artifacts

1. Use reproducible build steps: Document the commands, tool versions, and environment needed to generate each artifact.
2. Separate development and production settings: Make environment selection explicit and easy to verify.
3. Protect signing credentials: Use restricted storage and secure backups.
4. Use meaningful versioning: Maintain a consistent release history across platforms.
5. Test the actual release artifact: Install or distribute the built file rather than testing only through a development server.
6. Validate both clean installation and upgrades: Check data migration and compatibility with earlier releases.
7. Automate routine checks: Run tests and artifact validation in CI/CD.
8. Keep build records: Record source revision, build profile, versions, checksums, and results.
9. Review platform requirements: Check current Google Play and Apple distribution rules before every release.
10. Preserve diagnostic information: Keep relevant logs and iOS debug symbols securely.
11. Use controlled rollout: Release to internal testers or a limited audience before wider distribution where appropriate.
12. Prepare a rollback or mitigation plan: Understand how to pause a rollout or deliver a corrective release.

27. Mini Project: Generate and Validate Release Artifacts

Project Objective

Create release artifacts for a sample React Native application and document the process from project validation to distribution-ready output.

Project Requirements

• Use an existing React Native application.
• Configure a stable Android application ID and iOS bundle identifier.
• Set appropriate release version values.
• Configure Android release signing securely.
• Configure iOS signing and provisioning for the intended distribution method.
• Generate an Android APK and install it on a test device.
• Generate an Android AAB and validate it through a supported workflow.
• Create an iOS archive and export an IPA where the project and signing setup permit it.
• Test important application flows on physical devices.
• Record artifact names, checksums, source revision, and test results.

Expected Deliverables

Project Evaluation Criteria

• Build commands execute successfully in the configured environment.
• Artifacts are generated at the expected paths.
• Signing and version metadata are correct.
• The app launches without Metro.
• Core user journeys work on representative devices.
• Credentials are not exposed in source control or logs.
• The release record is complete and reproducible.

28. Interview Questions and Answers

Q1. What is a build artifact in React Native?

A build artifact is a file or package generated by the build process, such as an Android APK, Android AAB, iOS archive, or IPA.

Q2. What is the difference between APK and AAB?

An APK is an installable Android package. An AAB is a publishing bundle that allows Google Play to generate optimized APKs for supported devices.

Q3. Which Gradle command generates a release APK?

In a standard React Native Android project, ./gradlew assembleRelease generates a release APK, provided the project is configured correctly.

Q4. Which Gradle command generates an Android App Bundle?

./gradlew bundleRelease is the standard task for generating a release AAB in a typical Android project.

Q5. Can an AAB be installed directly using ADB?

Not in the same way as a normal APK. Use a supported workflow such as bundletool to generate and install APKs or use a Google Play testing track.

Q6. Why is Android release signing important?

Signing establishes the application's signing identity and is important for installation, distribution, and compatible application updates.

Q7. What is an Android keystore?

A keystore stores key material and certificates used by signing tools. The private key and associated passwords must be protected.

Q8. What is the difference between versionCode and versionName?

versionCode is the Android release sequence identifier used by the platform and distribution systems. versionName is the human-readable version string.

Q9. What is an IPA file?

An IPA is an iOS application archive used by supported Apple distribution and installation workflows.

Q10. What is an iOS .xcarchive?

An .xcarchive is an Xcode archive containing the built application and related distribution or diagnostic information used in validation and export workflows.

Q11. Why are code signing and provisioning required for iOS distribution?

They establish signing identity and authorize the application for the intended Apple platform workflow. Requirements vary by distribution method.

Q12. What is the purpose of an iOS bundle identifier?

It uniquely identifies the iOS application and connects the target to the relevant Apple developer and distribution configuration.

Q13. Why should a release build be tested without Metro?

A production build should normally contain the required JavaScript bundle and operate without depending on the local development server.

Q14. What should you do if an APK builds but crashes on launch?

Install it on a test device, inspect device logs, reproduce the issue, and investigate release-only configuration, native dependencies, assets, and runtime errors.

Q15. What is the purpose of an iOS dSYM file?

dSYM files contain debug symbols that help symbolicate crash reports and map compiled addresses back to useful diagnostic information.

Q16. What is the benefit of CI/CD for mobile builds?

CI/CD can standardize dependency installation, automated testing, signing, artifact generation, storage, and controlled distribution.

Q17. Why should signing credentials never be committed to a public repository?

Exposed credentials can allow unauthorized signing or distribution activities and may compromise the application's release process.

Q18. What is a product flavor in Android?

A product flavor defines a variation of an application, such as staging or production, with its own configuration, identifiers, or resources.

Q19. How can you verify that an artifact is the correct release?

Check its platform, application identifier, version, signing configuration, source revision, checksum, installation behavior, and test results.

Q20. Does a successful build mean the app is ready for the app store?

No. The artifact must also pass functional testing, signing and metadata checks, privacy review, compatibility checks, and the relevant store submission requirements.

29. Practical Exercises

1. Explain the differences between APK, AAB, .app, .xcarchive, and IPA.
2. Generate a release APK using the Gradle wrapper in a configured Android project.
3. Generate a release AAB and verify the output location.
4. Install a release APK on a physical Android device.
5. Configure an Android release keystore without committing its credentials.
6. Inspect the Android application ID, version code, and version name.
7. Open a React Native iOS workspace and inspect its bundle identifier.
8. Create an iOS archive using Xcode on a properly configured Mac.
9. Export an IPA for a supported distribution method.
10. Test release artifacts with Metro stopped.
11. Create a release record containing the source revision, artifact names, versions, and checksums.
12. Write a troubleshooting report for a failed build, including the first relevant error and the corrective action.

30. Quick Revision Checklist

• Understand the difference between development and release builds.
• Know when to use an APK and when to use an AAB.
• Know the standard Gradle commands: assembleRelease and bundleRelease.
• Verify Android application ID, SDK values, and version metadata.
• Protect Android keystores and signing passwords.
• Understand iOS .app, .xcarchive, IPA, and dSYM artifacts.
• Configure the correct iOS bundle identifier and version values.
• Verify Apple signing and provisioning for the chosen distribution method.
• Test the actual release build on physical devices.
• Confirm the app works without a development server.
• Validate production endpoints, permissions, icons, fonts, and assets.
• Inspect build logs and resolve release-only errors.
• Store artifacts and checksums securely.
• Automate repeatable release tasks with CI/CD where appropriate.
• Review current app-store requirements before publishing.

31. Conclusion

Generating Android APK/AAB and iOS build artifacts is a core step in preparing a React Native application for testing and distribution. Android APK files provide an installable package, while AAB files support the Google Play publishing workflow. On iOS, Xcode creates application builds and archives that can be exported as IPA files for supported distribution channels.

A dependable release process requires more than running a build command. Developers must configure identifiers and version numbers, protect signing credentials, validate production settings, test the generated artifacts on real devices, diagnose build errors, and preserve release metadata. Automating these steps with a carefully secured CI/CD pipeline makes releases more consistent and easier to maintain.

For structured learning and guided practice, explore the React Native Training course at JustAcademy, register through the course demo registration page, or visit the JustAcademy website.

Official Documentation and Further Reading

• React Native: Publishing to Google Play Store
• Android Developers: Android App Bundle
• Android Developers: App Signing
• Apple Developer: Distributing Your App
• App Store Connect: Upload Builds
• Expo: EAS Build Introduction