DEV Community: Anderson Begossi

Como configurar diferentes ambientes em apps React Native

Anderson Begossi — Mon, 21 Apr 2025 13:59:51 +0000

Em projetos React Native, é comum trabalhar com diferentes ambientes — como desenvolvimento, staging e produção. Cada um desses ambientes pode ter necessidades distintas — como um nome de app diferente, ícone específico, ou variáveis de ambiente próprias (como URLs de API ou chaves de serviços externos).

Configurar variantes de build permite isolar esses contextos, facilitando testes, distribuição e organização do projeto. Neste artigo, explico como configurar variantes de build no Android e no iOS, determinar um ícone, nome do app e outras configurações específicas por variante, além de como integrar com a biblioteca react-native-config. Para demonstrar as configurações na prática, criei um app React Native de exemplo que pode ser encontrado no GitHub, e compartilhei alguns trechos de código dele ao longo do texto. O resultado final do app e suas diferentes variantes pode ser visto abaixo:

Android

Build variants

No Android o que precisamos fazer é configurar diferentes build variants. Cada build variant tem um conjunto específico de configurações, código e recursos configurados nos build types e product flavors. Embora você não configure uma build variant diretamente, você o faz indiretamente configurando build types e product flavors.

Por exemplo, um product flavor chamado staging pode utilizar determinada URL de API, enquanto o build type release aplica diferentes configurações de assinatura. A build variant que combina esses dois se chamará stagingRelease, e irá incluir a combinação de configurações definidas no product flavor staging e no build type release.

Referência: https://developer.android.com/build/build-variants

Build types

Você pode configurar diferentes build types dentro do bloco android no arquivo android/app/build.gradle.

Quando você cria um projeto React Native, os build types debug e release já vem configurados por padrão, como mostra o trecho de código abaixo:

android {
    // ...
    buildTypes {
        debug {
            signingConfig signingConfigs.debug
        }
        release {
            // Caution! In production, you need to generate your own keystore file.
            // see https://reactnative.dev/docs/signed-apk-android.
            signingConfig signingConfigs.release
            minifyEnabled enableProguardInReleaseBuilds
            proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
        }
    }
    // ...
}

Referência: https://developer.android.com/build/build-variants#build-types

Product flavors

Configurar os product flavors é similar a configurar os build types, e também é feito no arquivo android/app/build.gradle. Adicione seus product flavors ao bloco productFlavors e inclua as configurações desejadas. Os product flavors aceitam as mesmas propriedades do defaultConfig. Você pode adicionar as configurações base de todos os product flavors no bloco defaultConfig, e, cada flavor pode alterar cada uma dessas configurações default, como, por exemplo, o applicationId.

No app de exemplo, configurei os product flavors development, staging, e production. Para os product flavors development e staging, adicionei as configurações applicationIdSuffix, para adicionar um sufixo específico no applicationId do app, e, versionNameSuffix, para adicionar um sufixo específico no versionName do app. O trecho de código onde isso foi feito é mostrado abaixo:

// ...

android {
    // ...
    defaultConfig {
        applicationId "com.buildvariants"
        minSdkVersion rootProject.ext.minSdkVersion
        targetSdkVersion rootProject.ext.targetSdkVersion
        versionCode 1
        versionName "1.0"
        resValue "string", "build_config_package", "com.buildvariants"
    }
    // ...
    flavorDimensions "version"
    productFlavors {
        development {
            applicationIdSuffix ".dev"
            versionNameSuffix "-dev"
        }
        staging {
            applicationIdSuffix ".staging"
            versionNameSuffix "-staging"
        }
        production {

        }
    }
    // ...
}

Referência: https://developer.android.com/build/build-variants#product-flavors

Configurações de assinatura

Para que você consiga fazer o build da build type release do app, você precisa definir as configurações de assinatura. Para isso, o primeiro passo é gerar uma upload key e uma keystore.

Após ter sua upload key e keystore, crie um arquivo chamado keystore.properties, dentro da pasta android, com as informações de assinatura geradas, como no exemplo abaixo:

storeFile=keystore.jks
keyAlias=keystore
storePassword=12345678
keyPassword=12345678

Após isso, no arquivo android/app/build.gradle, carregue as informações desse arquivo antes do bloco android e as referencie no bloco signinConfigs:

// ...

def keystorePropertiesFile = rootProject.file("keystore.properties")

def keystoreProperties = new Properties()

keystoreProperties.load(new FileInputStream(keystorePropertiesFile))

android {
    // ...
    signingConfigs {
        debug {
            storeFile file('debug.keystore')
            storePassword 'android'
            keyAlias 'androiddebugkey'
            keyPassword 'android'
        }
        release {
            storeFile file(keystoreProperties['storeFile'])
            keyAlias keystoreProperties['keyAlias']
            storePassword keystoreProperties['storePassword']
            keyPassword keystoreProperties['keyPassword']
        }
    }
    // ...
}

⚠️ Importante: não adicione o arquivo keystore.properties ou a sua keystore ao Git. Certifique-se de adicioná-los ao .gitignore.

Referência: https://developer.android.com/build/build-variants#signing

Nome do app

Para configurar um nome do app específico para cada product flavor, você precisa criar um pasta com o nome do product flavor dentro da pasta android/app/src. Dentro dela, crie uma pasta chamada "res”, e, dentro, uma chamada "values”. Dentro da pasta "values”, adicione um arquivo xml chamado "strings” com o nome do app desejado dentro de uma tag string com a propriedade name="app_name”. No app de exemplo, foi configurado o nome “DevBuildVariants" para o product flavor development, e, “StagingBuildVariants” para staging. Para o product flavor production, manteve-se o nome “BuildVariants”, que pode ser encontrado dentro do arquivo "strings” da pasta "main”. Caso o product flavor não sobrescreva o nome do app, o da pasta "main” é utilizado. Na screenshot abaixo, o arquivo "strings” com o nome do app do flavor development do app de exemplo é mostrado:

Ícone do app

Para configurar um ícone específico para cada product flavor, basta adicionar um novo Image Asset com o nome “ic_launcher” na pasta "res” de cada product flavor. Para o ícone do product flavor production, adicione um novo Image Asset com o nome “ic_launcher” na pasta “res” dentro da pasta “main”. O ícone do app da pasta "res" da pasta “main” será utilizado como padrão caso o product flavor não possua um ícone específico.

iOS

Build configurations

Build configurations definem como o Xcode deve compilar o projeto dependendo do ambiente ou propósito do build. Cada configuração representa um conjunto de regras e valores específicos usados durante a compilação, como flags de compilador, variáveis de ambiente, otimizações e arquivos de configuração. Por padrão, o Xcode cria duas configurações: Debug e Release.

Você pode criar configurações adicionais, como, Staging, Production, DebugStaging, etc., para ter mais controle sobre ambientes diferentes.

Essas configurações são frequentemente combinadas com schemes, permitindo, por exemplo, que o mesmo código-fonte seja compilado com diferentes endpoints de API, credenciais ou chaves de build.

Além disso, cada build configuration pode ser associada a um arquivo .xcconfig, facilitando a manutenção de valores separados por ambiente, como BASE_URL, BUNDLE_IDENTIFIER, APP_NAME, entre outros.

Em nosso app de exemplo, criei as build configurations DebugProduction, DebugStaging, ReleaseProduction e ReleaseStaging.

Para fazer isso, abra o arquivo `.xcworkspace`que está dentro da pasta iOS no seu Xcode, clique no seu projeto na aba lateral esquerda e depois no Project. Na aba Info, clique no ícone de + e adicione as novas build configurations. Na screenshot abaixo as build configurations do app de exemplo são mostradas:

Referência: https://developer.apple.com/documentation/xcode/adding-a-build-configuration-file-to-your-project

Build schemes

Quando você compila, executa ou testa seu app, o Xcode usa o build scheme selecionado para determinar o que fazer. Um build scheme contém as configurações que afetarão a ação selecionada. Por exemplo, quando você compila e roda seu app, o scheme fala para o Xcode quais argumentos de inicialização serão passados para o app. O Xcode cria schemes padrões na maioria das vezes, e você pode customizar esses schemes ou criar um novo caso necessário.

No app de exemplo, renomeei o scheme padrão para BuildVariantsDevelopment, e criei os schemes BuildVariantsStaging e BuildVariantsProduction. Você pode ver os schemes do seu app na barra superior do Xcode, como mostra a imagem abaixo:

Você pode criar ou editar um novo scheme através da janela que abre clicando no build scheme na barra superior, ou clicando em “Manage Schemes”.

Para cada build scheme, associe um build configuration correspondente. Na seção “Run”, associe o build configuration de debug do scheme. Na seção “Archive”, associe o build configuration de release do scheme, como pode ser visto nas screenshots do app de exemplo abaixo:

Referência: https://developer.apple.com/documentation/xcode/customizing-the-build-schemes-for-a-project

Bundle identifier

Para escolher um bundle identifier específico para cada variante do seu app, clique no seu app em “Targets”, e na aba “General” encontre a seção "Identity”. Nesta seção defina o bundle identifier desejado para cada build configuration. No app de exemplo foi definido o bundle identifier com.buildvariants.dev para a variante de development, com.buildvariants.staging para a variante de staging, e com.buildvariants para a variante de production, como mostra a imagem abaixo:

Nome do app

Para escolher um nome específico para cada variante do seu app, clique no seu app em “Targets”, e na aba “Build Settings” clique no ícone + na barra superior e adicione uma nova User-Defined Setting chamada APP_DISPLAY_NAME. Nessa User-Defined setting, escolha um nome específico para cada build configuration. No app de exemplo, escolhi os nomes “DevBuildVariants” para a variante de development, “StagingBuildVariants” para a variante de staging e "BuildVariants” para a variante de production. Na imagem abaixo isso pode ser visto:

Após isso, clique na aba “Info” e na key “Bundle display name” adicione o value $(APP_DISPLAY_NAME), como mostra a imagem abaixo:

Ícone do app

Para escolher um ícone específico para cada variante do app, você precisa primeiramente adicionar os ícones em "Images”, no seu projeto. Depois, você precisa vincular cada variante com seu respectivo ícone. No app de exemplo foi configurado um ícone específico para a variante de production, e, outro, para a variante de development e staging. Para fazer isso, primeiro, clique no seu projeto na aba lateral esquerda, abra a pasta com o nome do seu projeto e clique em “Images”. Clique em “AppIcon” e adicione seu ícone de produção, e, depois, adicione um novo iOS App Icon chamado “AppIconStaging” clicando no ícone + na barra inferior, e adicione seu ícone de development/staging. Na imagem abaixo o ícone de development/staging do app de exemplo pode ser visto:

Após isso, clique no seu app em “Targets”, e na aba “General" encontre a seção "App Icons and Launch Screen”. Nesta seção escolha o ícone correspondente para cada build configuration. A imagem abaixo mostra essa seção no app de exemplo:

CocoaPods

Por fim, precisamos mapear as build configurations criadas para configurações de build conhecidas pelo CocoaPods. Isso é importante porque o CocoaPods precisa entender se uma determinada configuração do Xcode deve ser tratada como um build de debug ou de release.

Para fazer isso no app de exemplo, adicionei o seguinte trecho no topo do arquivo Podfile:

project 'BuildVariants',
 'Debug' => :debug,
 'Release' => :release,
 'DebugProduction' => :debug,
 'ReleaseProduction' => :release,
 'DebugStaging' => :debug,
 'ReleaseStaging' => :release

Referência: https://guides.cocoapods.org/syntax/podfile.html#project

React Native Config

Para configurarmos diferentes variáveis de ambiente para cada ambiente do nosso app, instale o instale a biblioteca react-native-config seguindo a documentação, e crie os arquivos .env, .env.staging e .env.production na raiz do seu projeto. Em cada arquivo, defina as variáveis de ambiente de cada ambiente. Para que o Android e iOS carreguem as variáveis de ambiente corretamente, é preciso fazer alguns passos adicionais. Esses passos que foram seguidos no app de exemplo são descritos a seguir.

Android

Adicionalmente, precisamos manualmente aplicar um plugin no app. No arquivo android/app/build.gradle, foi adicionada a seguinte linha na segunda linha do arquivo:

apply from: project(':react-native-config').projectDir.getPath() + "/dotenv.gradle"

Para ter suporte a diferentes build variants, no mesmo arquivo foi adicionada a seguinte linha dentro de defaultConfig:

defaultConfig {
    // ...
    resValue "string", "build_config_package", "com.buildvariants"
}

Para que o Android saiba quais variáveis de ambiente utilizar para cada flavor, no arquivo android/app/build.gradle, associe cada product flavor com seu respectivo arquivo .env. Faça isso antes do apply from adicionado anteriormente, como mostra no trecho de código do app de exemplo abaixo:

project.ext.envConfigFiles = [
    development: ".env",
    staging: ".env.staging"
    production: ".env.production",
]
apply from: project(':react-native-config').projectDir.getPath() + "/dotenv.gradle"

Caso você tenha product flavors com nomes compostos, você deve defini-los nesta configuração usando lowercase.

Referência: https://github.com/lugg/react-native-config?tab=readme-ov-file#different-environments

iOS

Para que o iOS carregue as variáveis de ambiente corretamente, vincule cada build configuration com seu respectivo arquivo .env. Para fazer isso, foi adicionando o seguinte trecho no final do arquivo Podfile do app de exemplo:

// ...

target 'BuildVariants' do
  // ...

  ENVFILES = {
    'Debug' => '$(PODS_ROOT)/../../.env',
    'DebugStaging' => '$(PODS_ROOT)/../../.env.staging',
    'DebugProduction' => '$(PODS_ROOT)/../../.env.production',
    'Release' => '$(PODS_ROOT)/../../.env',
    'ReleaseStaging' => '$(PODS_ROOT)/../../.env.staging',
    'ReleaseProduction' => '$(PODS_ROOT)/../../.env.production',
  }

  post_install do |installer|
    // ...

    installer.pods_project.targets.each do |target|
      target.build_configurations.each do |config|
        if target.name == 'react-native-config'
          config.build_settings['ENVFILE'] = ENVFILES[config.name]
        end
      end
    end
  end
end

Referência: https://github.com/lugg/react-native-config?tab=readme-ov-file#different-environments

Scripts de build

Para facilitar o build de cada variante, adicione um script para cada no arquivo package.json.

Android

Utilize a flag mode para especificar a build variant, e a flag appId para especificar o applicationId que é para abrir no dispositivo depois do build. Se não especificado, o applicationId do defaultConfig será usado. Os scripts para o Android criados no app de exemplo podem ser vistos abaixo:

{
  "name": "buildvariants",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "android": "react-native run-android --mode=developmentDebug --appId=com.buildvariants.dev",
    "android-stg": "react-native run-android --mode=stagingDebug --appId=com.buildvariants.staging",
    "android-prod": "react-native run-android --mode=productionDebug",
  },
  // ...
}

Referência: https://github.com/react-native-community/cli/blob/main/packages/cli-platform-android/README.md#run-android

iOS

Utilize a flag scheme para especificar o build scheme, e a flag mode para especificar a build configuration. Os scripts para o iOS criados no app de exemplo podem ser vistos abaixo:

{
  "name": "buildvariants",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "ios": "react-native run-ios --scheme=BuildVariantsDevelopment --mode=Debug",
    "ios-stg": "react-native run-ios --scheme=BuildVariantsStaging --mode=DebugStaging",
    "ios-prod": "react-native run-ios --scheme=BuildVariantsProduction --mode=DebugProduction",
  },
  // ...
}

Referência: https://github.com/react-native-community/cli/blob/main/packages/cli-platform-ios/README.md#run-ios

Conclusão

Configurar variantes de build em projetos React Native é uma etapa essencial para organizar e isolar os diferentes ambientes em que o app será executado. Com a abordagem apresentada neste artigo, é possível definir nomes, ícones, variáveis de ambiente e configurações específicas para cada contexto, tanto no Android quanto no iOS. O projeto de exemplo disponível no GitHub pode servir como base para aplicar essas configurações em seu próprio app. Comente o que você achou ou deixe alguma pergunta!

How to set up MacOS for React Native development and maximum productivity

Anderson Begossi — Tue, 02 May 2023 23:24:58 +0000

After formatting my Mac, I set it up for my personal use and development workflow. I enjoy using various apps to enhance my productivity, so this time I decided to create a tutorial and share it with everyone.

Dependencies
Terminal
React Native environment
- iOS
- Android
- Flipper
- Expo
Other apps

Before starting I install three essential apps that help me with everything else:

Brave (browser) - Tks to my coworker Fig for the recommendation!
Notion (notes)
Raycast (launcher)

Raycast is my favorite one, as it has features that help me a lot with productivity and organization. I particularly enjoy the Window Manager, Quicklinks and Clipboard History built-in functionalities, and there are many extensions you can install on it. Here are some of the ones I use:

CPF/CNPJ Generator (Brazilian documents)
Google Search
Image Modification
Color Picker
Visual Studio Code - Project Manager

Dependencies

After that, I start setting up the development environment installing some dependencies:

Node.js

For install Node.js, I like to use the n node version manager.
To install n run:

curl -L https://raw.githubusercontent.com/tj/n/master/bin/n -o n
bash n lts
npm install -g n

To verify if the installation succeeds run:

node -v
npm -v
n --version

Homebrew

To install Homebrew run:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Git and GitHub CLI

To install Git run:

brew install git

To install the GitHub CLI run:

brew install gh

Watchman

To install Watchman run:

brew install watchman

Yarn

To install Yarn run:

npm install --global yarn

Terminal

After this, I like to configure my terminal.

For a long time, I used the Hyper terminal, but this time, I decided to give a chance for Warp. So far, I've really liked it. If you want to try it too, download it from their website, and install it like any other app.

One "disadvantage” of Warp is that you still can't use the Fig.io command line helper with it. However, Warp already has many of Fig.io features built-in.

In my terminal, I like to use the Hack Nerd Font and Starship custom prompt. If you want to use them too, download the font on this website:

Nerd Fonts Downloads

Extract the files, select all .ttf files and open.

In Warp, go to Settings → Appearance → Text and select the Hack Nerd Font on the Terminal font input.

To install Starship, follow this simple guide in their documentation:
Starship Installation Guide

NOTE: The default Warp shell is the Zsh. So, in Step 2 to configure Starship, choose the Zsh option.

Warp comes with some default themes, which you can choose by opening the command palette with Command + P and searching for 'Open Theme Picker'. However, I prefer to use the same theme that I use in my VSCode, which is the Catppuccin Mocha.

The final result is as follows:

React Native environment

Now it's time to configure the React Native environment. While I'll describe the main steps here, it's important to refer to the React Native documentation to ensure that no additional configurations or different steps are required.

iOS

Update Ruby

MacOS 13.2 is shipped with Ruby 2.6.10, which is not what is required by this version of React Native (2.7.6).

The easiest approach I found is to update Ruby using the RVM Ruby version manager:

curl -sSL https://raw.githubusercontent.com/rvm/rvm/master/binscripts/rvm-installer | bash -s stable
rvm install ruby@latest

Set the ruby default, replacing the X.X.X with the installed version:

rvm use ruby-X.X.X --default

Install CocoaPods

sudo gem install cocoapods

Install Xcode

Download on the App Store.

Android

Install the JDK 11 (LTS)

Download the .dmg file, and follow the installer steps.
Mac Apple Silicon JDK 11 Download
Mac Intel JDK 11 Download

Verify if the installation succeeds:

java -version

Create a folder to install the Android SDK. I like to create on ~/Android and named it as Sdk:

mkdir ~/Android/Sdk

Add the following lines to your ~/.zshrc file:

export JAVA_HOME=/Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home
export ANDROID_HOME=~/Android/Sdk
export PATH=$PATH:$ANDROID_HOME/emulator
export PATH=$PATH:$ANDROID_HOME/tools
export PATH=$PATH:$ANDROID_HOME/tools/bin
export PATH=$PATH:$ANDROID_HOME/platform-tools

NOTE: Make sure of the variables JAVA_HOME (path where you installed the JDK) and ANDROID_HOME (path of the folder you created to install the Android SDK).

Download Android Studio

Download and execute the .dmg file:
Android Studio Download

After installing Android Studio, the first time you open it you will need to make some configurations.

If the first screen asks if you want to import settings, choose "Do not import" and click OK.

After that, it should ask for the type of installation. Choose the Custom option.

Then, it should ask you to select the JDK path, make sure to choose the path you used in the JAVA_HOME variable previously.

After selecting the JDK path, Android Studio should ask for the theme.

After that, it should ask what you want to install and the path to install the Android SDK. Check all options and in the path, select the folder you created earlier (in my case it was /Users/ambegossi/Android/Sdk).

If everything is correct, just click on Next and then on Finish on the next screen.

Flipper

Flipper is a platform for debugging React Native apps. It's nice to visualize, inspect, and control your apps from a desktop interface.

Download the .dmg file on the official website and install it like any other app.

Expo

At the time of this publication, the Expo Go app from Expo is not yet supported by the new Apple chips. So I had to install Rosetta 2 so my apps wouldn't crash as soon as I opened them in the simulator.

To install Rosetta 2 run:

softwareupdate --install-rosetta --agree-to-license

Other apps

There are some other apps that I use and always install after formatting my computer. They are:

VSCode
AltTab (Windows alt-tab on macOS)
Spark Mail
Cron Calendar

These last two, I thank my coworker Vini for the recommendation.

If this post helped you, please show your support by liking and comment below if you have any suggestions 😉

DEV Community: Anderson Begossi

Como configurar diferentes ambientes em apps React Native

Android

Build variants

Build types

Product flavors

Configurações de assinatura

Nome do app

Ícone do app

iOS

Build configurations

Build schemes

Bundle identifier

Nome do app

Ícone do app

CocoaPods

React Native Config

Scripts de build

Conclusão

How to set up MacOS for React Native development and maximum productivity

Table of contents

Dependencies

Terminal

React Native environment

iOS

Android

Flipper

Expo

Other apps