Making React Native Apps Production-Ready

Introduction

Building a React Native application that works on your development device is only the beginning.

Imagine you have completed a mobile application. The screens look good, navigation works, APIs return data, and everything seems perfect.

You create a release build and share it with users.

Suddenly, problems start appearing:

The application crashes on certain devices.
API requests fail unexpectedly.
The app takes too long to open.
Sensitive information is exposed.
Push notifications do not work consistently.
Users report bugs that you cannot reproduce.

This happens because a working application is not necessarily a production-ready application.

Production readiness means preparing an application to handle real users, real devices, unexpected failures, security risks, and changing network conditions.

In this blog, we will explore the important areas you should consider before releasing a React Native application.

1. Understand the Difference Between Development and Production

During development, we usually focus on implementing features.

We use:

Development servers.
Debugging tools.
Test API endpoints.
Console logs.
Hot reloading.
Development builds.

Production introduces different requirements.

Development	Production
Test API	Production API
Debug logging	Controlled logging
Development build	Release build
Local testing	Real-device testing
Temporary configuration	Managed environment configuration
Manual debugging	Crash and error monitoring
Developer-focused UX	User-focused reliability

A production application should be designed to handle failures instead of assuming everything will always work.

2. Configure Environment Variables Properly

One common mistake is hardcoding API URLs and configuration values directly inside application files.

For example:

typescript

const API_URL = "http://localhost:3000";

This may work during development, but it will not work correctly for users installing your application.

Your production app needs a production API endpoint.

Use Environment-Specific Configuration

A simple configuration structure might look like this:

text

src/
  config/
    env.ts
  services/
    api.ts

.env.development
.env.production

For an Expo application, you can use Expo's environment variable support.

Example:

env

EXPO_PUBLIC_API_URL=https://api.example.com

Read it inside your application:

typescript

// src/config/env.ts

const apiUrl = process.env.EXPO_PUBLIC_API_URL;

if (!apiUrl) {
  throw new Error("API URL is not configured");
}

export const ENV = {
  API_URL: apiUrl,
};

Use the configuration in your API client:

typescript

import axios from "axios";
import { ENV } from "../config/env";

export const api = axios.create({
  baseURL: ENV.API_URL,
  timeout: 15000,
});

Now the application does not need hardcoded API URLs in multiple files.

Important Security Rule

Variables prefixed with EXPO_PUBLIC_ are included in the client application and should be treated as public.

Never put these values in public environment variables:

Database passwords.
Private API keys.
JWT signing secrets.
Payment gateway secret keys.
Server credentials.

A mobile application runs on a user's device. Anything shipped inside the application should be considered potentially accessible.

3. Handle Errors Gracefully

Production applications must expect errors.

An API request can fail. A user can lose connectivity. A database operation can throw an exception.

Instead of allowing these failures to break the user experience, handle them properly.

API Error Handling

Example using Axios:

typescript

import axios from "axios";

try {
  const response = await api.get("/users");

  return response.data;
} catch (error) {
  if (axios.isAxiosError(error)) {
    if (!error.response) {
      console.log("Network or connection error");
    } else {
      console.log(
        "API error:",
        error.response.status
      );
    }
  }

  throw error;
}

Do not show raw technical error messages directly to users.

Instead, provide useful messages:

text

Technical error:
Request failed with status code 500

User-friendly message:
Something went wrong. Please try again.

Use Error Boundaries

An error boundary catches rendering errors in its child component tree and displays a fallback UI.

Example:

tsx

import React from "react";
import {
  View,
  Text,
  Button,
} from "react-native";

type Props = {
  children: React.ReactNode;
};

type State = {
  hasError: boolean;
};

export class ErrorBoundary extends React.Component<
  Props,
  State
> {
  state: State = {
    hasError: false,
  };

  static getDerivedStateFromError(): State {
    return {
      hasError: true,
    };
  }

  componentDidCatch(error: Error) {
    console.error("UI rendering error:", error);
  }

  render() {
    if (this.state.hasError) {
      return (
        <View>
          <Text>
            Something went wrong.
          </Text>

          <Button
            title="Try Again"
            onPress={() =>
              this.setState({ hasError: false })
            }
          />
        </View>
      );
    }

    return this.props.children;
  }
}

Use it around an appropriate part of your application:

tsx

<ErrorBoundary>
  <App />
</ErrorBoundary>

This is a basic example. A production error boundary should also report the exception and provide a safe recovery path.

Remember: error boundaries do not catch every error. They do not automatically catch errors in event handlers, asynchronous callbacks, or arbitrary background tasks.

4. Optimize Application Performance

Performance directly affects user experience.

A slow application can frustrate users even when all its features work correctly.

Some common performance problems include:

Unnecessary component re-renders.
Large images.
Long lists rendered at once.
Expensive JavaScript operations.
Heavy animations on the JavaScript thread.
Too many network requests.

Optimize Lists

Avoid rendering hundreds or thousands of items using a basic ScrollView.

For long lists, use FlatList.

tsx

import React from "react";
import {
  FlatList,
  Text,
  View,
} from "react-native";

const users = [
  { id: "1", name: "Manjit" },
  { id: "2", name: "Rahul" },
  { id: "3", name: "Aman" },
];

export function UserList() {
  return (
    <FlatList
      data={users}
      keyExtractor={(item) => item.id}
      renderItem={({ item }) => (
        <View>
          <Text>{item.name}</Text>
        </View>
      )}
    />
  );
}

FlatList virtualizes list rendering so that it does not need to mount every item at once.

For very large or complex lists, you can also evaluate libraries such as FlashList.

Avoid Unnecessary Re-Renders

React.memo can prevent a component from re-rendering when its props have not changed.

tsx

import React from "react";
import { Text } from "react-native";

type Props = {
  name: string;
};

export const UserCard = React.memo(
  function UserCard({ name }: Props) {
    return <Text>{name}</Text>;
  }
);

Use memoization when profiling shows it is useful. Adding memo everywhere can make code harder to maintain without improving performance.

Optimize Images

Images can consume significant memory and network bandwidth.

Consider:

Using appropriately sized images.
Compressing large assets.
Using thumbnails in lists.
Avoiding unnecessarily large PNG files.
Using caching where appropriate.
Loading remote images progressively when needed.

Profile Before Optimizing

Do not guess where performance problems exist.

Use profiling tools and test on real devices, especially lower-end Android devices.

5. Protect Sensitive Application Data

Security is not something to add after releasing an application.

It should be considered during architecture and development.

Avoid Storing Sensitive Data in Plain Storage

Do not store passwords, private keys, or sensitive tokens in ordinary unencrypted storage.

For small sensitive values, use platform-backed secure storage.

For Expo applications:

bash

npx expo install expo-secure-store

Example:

typescript

import * as SecureStore from "expo-secure-store";

export async function saveToken(token: string) {
  await SecureStore.setItemAsync(
    "access_token",
    token
  );
}

export async function getToken() {
  return SecureStore.getItemAsync(
    "access_token"
  );
}

export async function removeToken() {
  await SecureStore.deleteItemAsync(
    "access_token"
  );
}

SecureStore is suitable for small secrets such as authentication tokens, not for storing an entire application database.

Other Important Security Practices

Use HTTPS for API communication.
Validate data on the backend.
Never ship server secrets in the mobile application.
Apply proper authentication and authorization.
Avoid exposing sensitive information in logs.
Keep dependencies updated.
Do not trust client-side validation alone.
Protect sensitive screens and user data appropriately.

Remember that a mobile app can be reverse-engineered. Client-side checks should never replace backend security controls.

6. Manage API Requests and Network Conditions

Mobile networks are unpredictable.

Your application should handle:

Slow internet.
Network disconnections.
Request timeouts.
Server errors.
Expired authentication tokens.
Duplicate requests.

A centralized API client makes request handling easier.

Example:

typescript

import axios from "axios";

export const api = axios.create({
  baseURL: process.env.EXPO_PUBLIC_API_URL,
  timeout: 15000,
  headers: {
    "Content-Type": "application/json",
  },
});

You can add interceptors for common request and response behavior.

typescript

api.interceptors.response.use(
  (response) => response,
  async (error) => {
    if (error.response?.status === 401) {
      // Handle expired or invalid authentication.
      // Avoid blindly retrying the same request.
    }

    return Promise.reject(error);
  }
);

For applications that need offline support, use local persistence and a synchronization strategy rather than treating every failed request as a permanent failure.

7. Add Crash Reporting and Error Monitoring

You cannot always reproduce problems reported by real users.

A user might say:

"The app suddenly closed when I opened the profile screen."

Without crash reporting, finding the cause can be difficult.

Crash reporting tools help collect information about application crashes and errors.

Popular options include:

Sentry
Firebase Crashlytics

They can help developers understand:

Which version crashed.
Which device was affected.
Which operating system was used.
The error message and stack trace.
How frequently a crash occurs.

Example: Sentry

Install the React Native SDK using the setup instructions for your project type:

bash

npm install @sentry/react-native

Then initialize it according to the official React Native setup:

typescript

import * as Sentry from "@sentry/react-native";

Sentry.init({
  dsn: "YOUR_SENTRY_DSN",
  sendDefaultPii: false,
});

The DSN identifies the project endpoint and is not equivalent to a private server secret. Still, configure data collection and privacy settings carefully.

Do not send passwords, tokens, or sensitive personal information as error context.

8. Test on Real Devices

An application working in an emulator does not guarantee that it will work correctly on real devices.

Real devices have different:

Screen sizes.
Memory limits.
CPU performance.
Android versions.
Network conditions.
Permission settings.
Battery restrictions.

Test important application flows on both Android and iOS when you support both platforms.

Important Test Scenarios

Authentication

Login and logout.
Expired access token.
Invalid credentials.
Session restoration.

Network

No internet.
Slow internet.
API unavailable.
Network switching.

Application Lifecycle

Background and foreground transitions.
Application restart.
Permission changes.
Notification handling.

Device Compatibility

Different screen sizes.
Older supported OS versions.
Low-memory devices.
Keyboard and safe-area behavior.

Automate Important Tests

Useful testing tools include:

Jest for JavaScript and TypeScript tests.
React Native Testing Library for component tests.
Maestro for mobile UI automation.
Detox for end-to-end testing.

You do not need to automate everything immediately. Start with critical user journeys such as login, checkout, booking, and payment.

9. Prepare the Application for Release

A release build is different from a development build.

Before publishing, verify:

Application name.
App icon.
Splash screen.
Bundle identifier or Android application ID.
Version number.
Permissions.
API environment.
Signing configuration.
Privacy policy.
Store listing assets.

For Expo applications, EAS Build can simplify cloud-based native builds.

Install the CLI:

bash

npm install -g eas-cli

bash

eas login

Configure the project:

bash

eas build:configure

A simplified eas.json example:

json

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

Create a production build:

bash

eas build --platform android --profile production

For iOS:

bash

eas build --platform ios --profile production

The iOS build and distribution process requires the appropriate Apple developer account and signing configuration.

Always check the current Expo documentation for the supported build configuration and distribution requirements.

10. Understand OTA Updates

Sometimes, you need to fix a JavaScript bug without asking every user to download a new store release.

Over-the-air updates can help with this.

Expo Updates allows compatible JavaScript and asset updates to be delivered to installed applications.

For example:

text

User installs application version 1.0

        ↓

A small UI bug is discovered

        ↓

Developer publishes a compatible update

        ↓

Application downloads the update

        ↓

User receives the updated experience

However, OTA updates have important limitations.

They cannot replace every native application update.

Changes to native code, native dependencies, permissions, or the native runtime may require a new binary build.

Use runtime versioning and update channels carefully so that users receive updates compatible with their installed application.

11. CI/CD for React Native Applications

As an application grows, manually building and testing every release becomes repetitive.

CI/CD helps automate parts of the development and release process.

A typical pipeline might look like this:

Diagram

Scroll to zoom · Drag to pan

Common tools include:

GitHub Actions.
EAS Build.
EAS Submit.
Fastlane.

A basic CI workflow should check code quality and tests before generating a release build.

You can add automated distribution to internal testers before publishing publicly.

12. Production Readiness Checklist

Before releasing a React Native application, use this checklist.

Configuration

Production API URL configured.
Environment-specific configuration verified.
No private secrets shipped in the app.
Application identifiers and version configured.

Reliability

API errors handled.
Error boundaries added where appropriate.
Network failure states implemented.
Loading and empty states designed.
Authentication expiry handled.

Performance

Long lists optimized.
Images compressed and sized correctly.
Unnecessary re-renders investigated.
App tested on real devices.
Startup performance checked.

Security

Testing and Release

Important flows tested.
Android release build tested.
iOS release build tested if supported.
Crash reporting configured.
Privacy and store requirements reviewed.
Release process documented.

Conclusion

Building a React Native application is not just about creating screens and connecting APIs.

A production-ready application must be reliable, secure, performant, testable, and maintainable.

Remember these important areas:

Environment configuration
Error handling
Performance optimization
Security
Network management
Crash reporting
Real-device testing
Release management
OTA updates
CI/CD

The goal is simple:

Do not just build an application that works on your device. Build an application that users can depend on.

Making React Native Apps Production-Ready

Making React Native Apps Production-Ready

Introduction

1. Understand the Difference Between Development and Production

2. Configure Environment Variables Properly

Use Environment-Specific Configuration

Important Security Rule

3. Handle Errors Gracefully

API Error Handling

Use Error Boundaries

4. Optimize Application Performance

Optimize Lists

Avoid Unnecessary Re-Renders

Optimize Images

Profile Before Optimizing

5. Protect Sensitive Application Data

Avoid Storing Sensitive Data in Plain Storage

Other Important Security Practices

6. Manage API Requests and Network Conditions

7. Add Crash Reporting and Error Monitoring

Example: Sentry

8. Test on Real Devices

Important Test Scenarios

Automate Important Tests

9. Prepare the Application for Release

10. Understand OTA Updates

11. CI/CD for React Native Applications

12. Production Readiness Checklist

Configuration

Reliability

Performance

Security

Testing and Release

Conclusion

Further Reading