Creating iOS build using Command in React Native

22 / Mar / 2025 by Vibhash Kumar 0 comments

Introduction

In the world of mobile app development, ensuring that your iOS application is correctly built and deployed is crucial. One of the most popular package managers used in modern JavaScript-based mobile development is YARN. It helps manage dependencies efficiently and provides a seamless experience for React Native and other JavaScript-based frameworks. In this blog post, we will discuss how to create an iOS build using the YARN command, its uses, advantages, disadvantages, and final thoughts.

Prerequisites

Before building an iOS application using YARN, ensure you have the following installed on your system:

  • macOS (iOS builds require Xcode, which is only available on macOS)
  • Xcode (latest stable version)
  • Node.js and YARN (install via Homebrew or nvm)
  • CocoaPods (for managing iOS dependencies)
  • React Native CLI (if working with React Native apps)
  • Apple Developer Account (to sign and distribute the app)
  • We are Shell Script to create an iOS build
  • What Does This Script Do?

This script automates the process of building an iOS app from Xcode using the command line instead of manually clicking buttons inside Xcode. It helps developers create different types of builds (staging, production, or debug) efficiently.

Step-by-Step Explanation of the Script

 #!/bin/bash

This shebang (#!) tells the system to use the Bash shell to run the script.

Step 1: Check if the Environment is Provided

Script for creating iOS build when we use command to create build.

Shell Script .sh file

  • This checks if the user provided an environment (staging, production, or debug).
  • If not, it prints a message explaining how to use the script and exits.

Step 2: Define Project Details

Check if the Environment is Provided

Environment Checks

  • These variables are stored:
    • WORKSPACE_NAME → The name of your project (inside Xcode).
    • SCHEME_NAME → The name of the scheme (a scheme defines how the app is built).

Step 3: Set Configuration Based on Environment

Define Project Details

Define Project Details

  • $1 stores the first argument passed to the script (staging, production, or debug).

Based on the environment, it sets the correct configuration:

  • staging → Staging.Release
  • production → Release
  • debug → Debug

If an invalid value is provided, the script shows an error message and exits.

Step 4: Define Export Paths

Set Configuration Based on Environment

Set Configuration Based on Environment

  • EXPORT_OPTIONS_PLIST → Points to a file that tells Xcode how to export the app.
  • ARCHIVE_PATH → Where the app’s archived version will be stored.
  • EXPORT_PATH → Where the final .ipa file (the installable app) will be saved.
  • $(date +%Y-%m-%d_%H-%M-%S) adds the current date and time so each build is saved separately.

What is ExportOptions.plist and Why is It Important?

When you build an iOS app using Xcode, you need a special file called ExportOptions.plist. This file tells Xcode how to export the app after it has been archived.

  • It’s required when you use command-line tools (like xcodebuild) to automate the iOS build process. This file contains important settings such as:
    • Whether the app is for the App Store, Ad Hoc distribution, or Enterprise use.
    • Whether to include Bitcode (a feature for Apple’s optimization).
    • Whether to upload the app to the App Store directly.
    • The team ID for signing the app.

Example of ExportOptions.plist
Here’s an example of how it might look:

ExportOption.plist

ExportOption.plist

  • Options:app-store → For App Store distribution.
  • ad-hoc → For testing on specific devices (without App Store).
  • enterprise → For distributing inside a company (without App Store).
  • development → For running on a developer’s device
  • The Apple Team ID ensures that the app is signed by the correct Apple Developer account.
  • You can find your Team ID in the Apple Developer Portal.

1. What is Bitcode?

Bitcode allows Apple to re-optimize your app for different devices.

  • Options: true → Enables Bitcode (needed for App Store submissions).
  • false → Disables Bitcode (recommended for local builds).

2. How Should the App Be Signed?

  • Options: automatic → Xcode will automatically choose the signing certificate.
  • Manual → You have to specify the exact provisioning profile.

3. Which Provisioning Profile Should Be Used?

  • This tells Xcode which provisioning profile to use.
  • You can find the correct profile Apple Developer Portal. under Profiles.

4. Where Should the App Be Exported?

  • This defines where the .ipa file should be saved.
  • export → Saves the .ipa file to a folder.

5. Should Swift Debug Symbols Be Removed?

  • true → Reduces the app size by removing unnecessary Swift symbols.
  • false → Keeps debug symbols (useful for debugging but increases size).

6. Should the App Be Optimized for Different Devices?

  • none → The app includes all assets (larger size but works on all devices).
  • thin-for-all-variants → Generates different versions for different devices.

Step 5: Navigate to the iOS Folder

Navigate to the iOS Folder

Navigate to the iOS Folder

  • Moves into the iOS directory where the Xcode project is located.
  • || exit → If the folder is missing, it stops the script.

Step 6: Install Dependencies (CocoaPods)

Install Dependencies (CocoaPods)

Install Dependencies (CocoaPods)

  • Installs required iOS libraries (dependencies) for the app.
  • –quiet make sure it runs silently without printing too much text.

Step 7: Clean the Build Folder

Clean the Build Folder

Clean the Build Folder

  • This removes old build files so we get a fresh build.

Step 8: Archive the App

Archive the App

Archive the App

What is archiving?

  • This creates an archive (a packaged version of the app that can be sent to the App Store or tested).

Explanation of options:

  • -workspace “$WORKSPACE_NAME.xcworkspace” → Uses the workspace file.
  • -scheme “$SCHEME_NAME” → Uses the correct scheme.
  • -configuration “$CONFIGURATION” → Uses the environment-specific build mode.
  • -archivePath “$ARCHIVE_PATH” → Saves the archive to the specified folder.
  • CODE_SIGN_IDENTITY=”iPhone Developer” → Ensures correct code signing (important for iOS security).
  • IPHONEOS_DEPLOYMENT_TARGET=12.0 → Sets the minimum iOS version.

Step 9: Export the Final .ipa File

Export the Final .ipa File

Export the Final .ipa File

  • Takes the archived app and creates a .ipa file (the installable app).

Step 10: Check if the Build was Successful

Check if the Build was Successful

Check if the Build was Successful

  • $? -eq 0 → Checks if the last command succeeded (0 means success).
  • If successful:
    • Prints a success message.
    • Opens the archived build in Xcode.
  • If failed:
    • Prints an error message.
    • Exits with an error code.

Option 1: How to Use This Script?

Use of Script

Use of Script

Option 2: Run with Yarn (Recommended)

    1. Open package.json and add:
Open package.json and add:

Open package.json and add:

2. Then run:

Then run:

Then run:

Summary:

  • This script automates iOS app builds.
  • It cleans, archives, and exports the app for different environments.
  • It saves time by eliminating manual steps in Xcode.
  • Works for staging, production (release), and debug builds.
  • Uses CocoaPods to install dependencies.
  • Can be run via Terminal or Yarn.

Uses of YARN in iOS Builds

  • Dependency Management: Ensures that the project dependencies are installed efficiently.
  • Consistent Builds: Provides a deterministic install algorithm, making sure every build remains consistent.
  • Faster Package Installation: Compared to npm, YARN is known for its speed and efficiency in dependency installation.
  • Supports Offline Mode: YARN caches previously downloaded packages, enabling offline installations.
  • Better Security: It verifies package integrity using checksums, reducing the risk of corrupted dependencies.

Pros and Cons

  • Pros
    • Faster dependency installation and package management.
    • Provides better security and integrity verification.
    • Works well with React Native for mobile development.
    • Supports parallel processing for efficient builds.
    • Reduces dependency conflicts with lock files.
  • Cons
    • Requires initial setup and configuration.
    • It can sometimes cause issues with specific package versions.
    • The learning curve for new developers transitioning from npm.
    • Not a complete replacement for Xcode when dealing with advanced iOS configurations.

Conclusion

Building an iOS application using the YARN command streamlines the development process, especially for JavaScript-based mobile frameworks like React Native. It offers several benefits, including faster dependency management, improved security, and consistency across builds. However, developers must ensure their environment is correctly set up and be prepared for occasional dependency conflicts. Overall, YARN remains an excellent tool for managing and building iOS applications efficiently.

FOUND THIS USEFUL? SHARE IT

Leave a Reply

Your email address will not be published. Required fields are marked *