Conectar React Native a una API HTTPS en producción

Una app React Native puede llamar una API con fetch, pero el servidor de desarrollo no acompaña al binario cuando lo instalas desde Google Play o App Store. Debes desplegar el backend en una URL pública y configurar el build móvil para que use esa dirección.

Si todavía no sabes dónde ejecutar la API, empieza por la comparación de Projects y VPS para apps móviles. Si estás considerando Firebase frente a un servicio propio, aquí tienes una comparación de Firebase y backend propio. Si ahora mismo la llamada falla solo en producción, usa la guía de diagnóstico de API desde el frontend.

1. Comprueba la URL que usa el móvil

Una URL como http://localhost:3000/api solo sirve dentro del dispositivo que la interpreta. En un teléfono apunta al propio teléfono, no al ordenador donde ejecutas Metro. Configura una URL pública como https://api.ejemplo.com/v1 y separa ese valor del que usas para el simulador o la red local.

React Native documenta el uso de fetch para peticiones REST y avisa de que Android e iOS tienen requisitos distintos para conexiones sin cifrar. Para producción, usa HTTPS y evita añadir excepciones globales de HTTP que amplíen innecesariamente el acceso de la app. Networking en React Native

2. Maneja códigos HTTP y respuestas inesperadas

fetch permite configurar método y cabeceras. Comprueba response.ok antes de tratar el cuerpo como un éxito y maneja aparte fallos de red y errores HTTP. Por ejemplo:

type Profile = { id: string; displayName: string };

const API_BASE_URL = 'https://api.ejemplo.com/v1';

export async function getProfile(accessToken: string): Promise<Profile> {
  let response: Response;
  try {
    response = await fetch(`${API_BASE_URL}/profile`, {
      headers: { Authorization: `Bearer ${accessToken}` },
    });
  } catch {
    throw new Error('No se pudo conectar con el servidor');
  }

  if (response.status === 401) {
    throw new Error('La sesión ha caducado');
  }
  if (!response.ok) {
    throw new Error(`La API respondió HTTP ${response.status}`);
  }

  const contentType = response.headers.get('content-type') ?? '';
  if (!contentType.includes('application/json')) {
    throw new Error('El servidor no devolvió JSON');
  }

  return (await response.json()) as Profile;
}

El tipo TypeScript ayuda al editor, pero no valida el JSON recibido cuando la app está ejecutándose. Si la API puede cambiar o devolver datos externos, valida el objeto con el esquema que use tu aplicación. Añade también una política de timeout/cancelación y reintentos con límites adecuados para tu producto.

El ejemplo no implementa el inicio de sesión, el ciclo de renovación del token, el almacenamiento seguro del token, el timeout ni el contrato completo de errores. No lo uses como sistema de autenticación listo para producción sin integrar esos elementos.

3. No metas credenciales privadas en el cliente móvil

El código del cliente se distribuye a quien instala la app. Una variable de entorno incluida en un build no convierte una clave en secreta. En el cliente solo deben ir valores públicos de configuración, como la URL de la API o un identificador de aplicación. Las credenciales de base de datos, de administración o de un servicio servidor-servidor deben quedarse en el backend.

Autentica al usuario y autoriza cada operación en la API: que la app oculte una acción no impide que alguien construya la petición manualmente. Valida los datos recibidos, limita intentos y no guardes tokens en logs. La guía REST de OWASP ofrece una lista de controles para el servidor.

4. Distingue una app nativa de una web móvil

Las peticiones desde React Native nativo no pasan por el modelo CORS del navegador. Si la misma aplicación también tiene una interfaz web que llama a la API desde Chrome o Safari, esa parte sí está sujeta a CORS y puede requerir responder correctamente a OPTIONS. No abras todos los orígenes como parche: permite los orígenes web que realmente necesitas y conserva autenticación en el servidor.

React Native también señala que el transporte iOS y el tráfico en claro de Android tienen reglas propias. Comprueba la documentación vigente de la versión que usa tu app y prueba el build de release en ambos sistemas, no solo Expo/Metro en modo desarrollo.

5. Despliega el backend donde encaje su runtime

Projects sirve si tu API se ejecuta como servicio Node.js o contenedor compatible con el plan, conectada a Git. Comprueba recursos, comando de inicio y servicios de datos requeridos. Si el backend necesita configuración del sistema, Docker Compose o control de proxy, un VPS permite administrarlo directamente; ese control implica que también debes mantenerlo y hacer las copias necesarias.

No confundas publicar el frontend con publicar la API: una carpeta de React Native no arranca un proceso en el servidor. Consulta Projects, VPS y la guía de backend móvil para escoger según el proceso que tengas.

Antes de publicar

1. Busca localhost, 127.0.0.1 e IPs privadas en la configuración del build de release.
2. Prueba la URL HTTPS fuera de tu red de desarrollo.
3. Comprueba respuestas 200, 401, 404, 429 y 5xx según las rutas de tu API.
4. Verifica que no se haya incluido una credencial privada en el bundle.
5. Prueba errores de red y autenticación tanto en iOS como en Android.

Referencias: Networking en React Native, OWASP REST Security Cheat Sheet, OWASP Mobile Application Security Cheat Sheet.

Para comparar requisitos de despliegue y mantenimiento antes de contratar, consulta dónde alojar una API: Projects o VPS.