Guía completa de selección de imágenes de Expo para 2026

You’re probably at the point where the UI is ready, the profile screen has an “Upload photo” button, and now the easy part suddenly isn’t easy. The actual image selection flow touches native permissions, OS-controlled interfaces, different return shapes than many developers expect, and a handful of build-time details that only show up after you ship a real build.

Es ahí donde entra en juego Expo Image Picker. Es la biblioteca oficial de Expo para abrir la interfaz de sistema para elegir imágenes y videos de la biblioteca del dispositivo o tomar una foto con la cámara, como se describe en el Repositorio de paquetes de Expo. En la práctica, eso significa que obtienes un puente confiable hacia la entrada de medios nativos, pero no una experiencia de medios personalizada que se comporte de manera idéntica en todos los dispositivos.

Esta guía está escrita para la primera implementación, no para la demo. Se centra en las decisiones que importan en producción: configuración de flujo de trabajo administrado versus bare, manejo de permisos que no te sorprenderán después, parsing de resultados seguros y un patrón de carga práctico después de que el usuario elija un archivo. Si estás trabajando en un conjunto de configuración nativa personalizada, también ayuda a entender cómo esto difiere de un flujo de trabajo de cliente de desarrollo de Expo flujo de trabajo del cliente de Expo.

Empezando con Expo Image Picker

• Instalación y Configuración Esencial
• Configuración de flujo de trabajo administrado
  • Configuración de flujo de trabajo administrado
  • Accediendo a la Cámara y Biblioteca de Medios
• Getting Started with Expo Image Picker
  • A componente mínimo pero seguro
  • Flujos de biblioteca y cámara
  • ¿Qué esperar del UI del sistema
• Manipulación de resultados y opciones del picker
  • Leer el objeto de resultado correctamente
  • Opciones que cambian el comportamiento downstream
  • URI versus base64
  • A safer result pattern for real apps
• Patrones avanzados y diferencias de plataforma
  • Un patrón de carga práctico
  • ¿Dónde las diferencias de plataforma importan realmente
  • Diferencias entre flujo administrado y flujo desnudo
• Resolución de Problemas Comunes
  • Verificación rápida de fallas comunes
  • Lista de verificación de producción breve

Introducción a Expo Image Picker

Un gerente de producto solicita fotos de perfil. Una semana después, la misma característica también necesita subir recibos, capturar la cámara para informes de incidentes y reintentar cuando los usuarios deniegan la autorización la primera vez. La entrada de imágenes se expande rápidamente porque toca permisos nativos, UI propiedad del sistema, manejo de archivos temporales y flujos de subida al servidor.

expo-image-picker es la módulo de Expo SDK para ese trabajo. Abre el selector de plataforma o la interfaz de cámara y devuelve la media seleccionada en una forma que tu React Native code puede manejar. El JavaScript API es pequeño. El principal desafío está en obtener la configuración nativa, el flujo de permisos y el manejo de resultados correctos en proyectos administrados y desnudos.

El principal equilibrio es claro. Dejas que iOS y Android presenten su propia interfaz de medios en lugar de construir un selector personalizado. Eso suele dar un resultado mejor: los usuarios ya entienden las pantallas del sistema, las solicitudes de permiso se comportan de la manera que el sistema espera y tu equipo evita mantener una implementación de galería en JavaScript.

Trátalo como una característica de integración nativa con una interfaz de React.

Esta mentalidad ayuda porque los modos de falla raramente están en el botón que llama al selector. Normalmente vienen de uno de tres lugares:

• Configuración nativa: setup de plugin faltante, cadenas de permiso incorrectas o una compilación estancada después de cambiar la configuración
• Comportamiento en tiempo de ejecución: Los usuarios pueden denegar el acceso, conceder acceso a la biblioteca limitado en iOS o cancelar el flujo sin seleccionar nada
• Análisis de resultados: El actual API devuelve un assets array, por lo que los ejemplos antiguos que leen result.uri directamente fallan

El cambio de elección de flujo también cambia el camino de configuración. En una aplicación Expo administrada, la mayoría del trabajo nativo vive en la configuración de la aplicación y requiere una reconstrucción cuando esa configuración cambia. En una aplicación bare, todavía se obtiene el módulo Expo API, pero es necesario verificar los ajustes de proyecto iOS y Android subyacentes de manera más directa. Si su equipo utiliza un cliente personalizado en lugar de Expo Go, esta guía se combina bien con Capgo’s explicación de cómo un cliente de desarrollo Expo cambia la prueba de módulos nativos.

Es importante porque el camino feliz solo es la mitad de la historia. Una implementación de selector es sólida cuando funciona en ambos flujos, maneja las particularidades de permisos de plataforma sin sorprender al usuario y pasa un archivo usable a su capa de subida en lugar de detenerse en una vista previa local.

Instalación y Configuración Esencial

La instalación requiere un solo comando. Obtener la configuración nativa correcta es lo que determina si el selector funciona en un dispositivo real, en un cliente de desarrollo personalizado y en su versión de producción.

expo-image-picker proporciona un API de cara a React sobre los seleccionadores de plataforma para fotos, videos y captura de cámara. La llamada de JavaScript es simple. La configuración no lo es, porque el acceso a fotos y el acceso a la cámara están controlados por iOS y Android, no por React Native.

Comience con el instalador de versión consciente de Expo:

npx expo install expo-image-picker

Usar expo install en lugar de npm install o yarn add. Expo matches the package version to your SDK, which avoids a common class of native compatibility problems. If you are comparing how Expo modules fit into your release process, this Resumen de herramientas de Expo es una referencia útil.

Configuración de flujo de trabajo administrado

In the managed workflow, declare the plugin in app config so Expo can apply the native changes at build time.

en lugar de utilizar app.json:

{
  "expo": {
    "plugins": ["expo-image-picker"]
  }
}

That is the minimum setup. In practice, teams usually add permission text as well, especially on iOS where the system prompt should explain why the app needs access. Keep the wording specific to the user action. “Upload a profile photo” is better than “Needs media access.”

Un detalle operativo causa mucho tiempo desperdiciado. Cambiar pluginsLas cadenas de permiso o la configuración nativa requieren una reconstrucción. Recargar JavaScript no aplica esos cambios. En Expo Go, también está limitado por lo que ya incluye el cliente. En una compilación de desarrollo o producción, el proyecto nativo refleja la configuración solo después de una nueva compilación.

Bare React Native setup detalles

En una aplicación bare, el paquete API es el mismo, pero necesita verificar más del proyecto nativo usted mismo. Las descripciones de uso de iOS son la primera cosa a verificar. Si su flujo puede abrir la biblioteca, iniciar la cámara o grabar video con audio, su aplicación necesita las cadenas de permiso correspondientes en Info.plist antes de reconstruir.

Un checklist práctico para proyectos bare se parece a esto:

1. Instalar expo-image-picker con npx expo install expo-image-picker.
2. Agregar la configuración del plugin si su proyecto utiliza plugins de configuración de Expo.
3. Confirme que las descripciones de uso de iOS coinciden con las características que expone.
4. Reconstruya las aplicaciones iOS y Android después de cualquier cambio de configuración nativa.

El texto de permiso faltante a menudo parece un error de ejecución porque la interfaz de usuario code está bien y el manipulador de botones se ejecuta. El error está más abajo en la pila. Normalmente reviso Info.plistAntes de tocar el componente code, compruebe la configuración de la aplicación, y si la compilación actual incluye los últimos cambios nativos.

Unos hábitos hacen que la configuración sea más predecible:

• Redacte el texto de permiso para la acción real: Los usuarios deben comprender por qué están viendo la solicitud.
• Configurar la cámara y la biblioteca por separado: Una puede funcionar mientras la otra todavía falla.
• Recompilar después de los cambios nativos: La recarga caliente y la actualización rápida no actualizan los permisos nativos.
• Probar en dispositivo: El comportamiento del simulador puede ocultar problemas de permiso y cámara.

Si el selector de imágenes funciona durante el desarrollo pero se rompe en TestFlight o la tienda de Play, considere que es un problema de configuración. La mayoría de las veces, lo es.

Acceder a la Cámara y la Biblioteca de Medios

A un usuario le toca ‘Subir foto’, espera que se abra la cámara o la biblioteca, y tu aplicación tiene una tarea en ese momento. Abrir la interfaz de usuario correcta, manejar la negativa o la cancelación sin romper la pantalla, y devolver una referencia de archivo local usable para la vista previa o el envío.

Suena simple hasta que pruebes tanto compilaciones administradas como compilaciones desnudas en iOS y Android. El JavaScript API se mantiene compacto, pero el comportamiento en tiempo de ejecución sigue dependiendo de las solicitudes del sistema, el hardware del dispositivo y cómo configuraste las permisos nativos anteriormente.

Un componente mínimo pero seguro

El flujo básico es consistente en proyectos de flujo de trabajo administrado y desnudo de Expo. Solicita la permiso relevante, lanza el selector, comprueba si el usuario canceló, y lee el primer activo de result.assets.

Un componente de referencia básico se parece a esto:

import { useState } from 'react';
import { View, Button, Image, Alert } from 'react-native';
import * as ImagePicker from 'expo-image-picker';

export default function PhotoInput() {
  const [imageUri, setImageUri] = useState<string | null>(null);

  const pickFromLibrary = async () => {
    const permission = await ImagePicker.requestMediaLibraryPermissionsAsync();

    if (!permission.granted) {
      Alert.alert('Permission required', 'Please allow photo library access.');
      return;
    }

    const result = await ImagePicker.launchImageLibraryAsync({
      mediaTypes: ['images'],
      allowsEditing: true,
      quality: 1,
    });

    if (result.canceled) return;

    const asset = result.assets?.[0];
    if (!asset?.uri) return;

    setImageUri(asset.uri);
  };

  const takePhoto = async () => {
    const permission = await ImagePicker.requestCameraPermissionsAsync();

    if (!permission.granted) {
      Alert.alert('Permission required', 'Please allow camera access.');
      return;
    }

    const result = await ImagePicker.launchCameraAsync({
      allowsEditing: true,
      quality: 1,
    });

    if (result.canceled) return;

    const asset = result.assets?.[0];
    if (!asset?.uri) return;

    setImageUri(asset.uri);
  };

  return (
    <View>
      <Button title="Choose from library" onPress={pickFromLibrary} />
      <Button title="Take photo" onPress={takePhoto} />
      {imageUri ? (
        <Image
          source={{ uri: imageUri }}
          style={{ width: 200, height: 200 }}
        />
      ) : null}
    </View>
  );
}

Tres detalles son importantes aquí.

• Solicita permisos de biblioteca y cámara por separado. Fallecen de manera independiente.
• Trata la cancelación como una acción de usuario normal, no como un estado de error.
• Lea de assets[0]porque el selector devuelve un arreglo de activos en lugar de un nivel superior uri.

Flujos de biblioteca y cámara

Comience con el flujo de biblioteca si desea el camino más rápido a una función en funcionamiento. Es más fácil de probar, funciona en más configuraciones de simulador y evita casos de hardware de cámara. Agregue el soporte de cámara una vez que el camino de manejo de resultados esté establecido.

El camino de la cámara tiene más formas de fallar en desarrollo. El soporte de simulador de iOS es limitado. Los emuladores de Android pueden no exponer el comportamiento de la cámara que coincide con un dispositivo real. En proyectos desnudos, esas brechas pueden enviarlo buscando el componente code aunque el problema real es la configuración nativa o el entorno de prueba.

Un patrón de interfaz de usuario limpio es preguntar al usuario por la fuente antes de llamar al selector API:

const showPickerOptions = () => {
  Alert.alert('Upload image', 'Choose a source', [
    { text: 'Camera', onPress: takePhoto },
    { text: 'Photo Library', onPress: pickFromLibrary },
    { text: 'Cancel', style: 'cancel' },
  ]);
};

Esta separación mantiene cada función enfocada. También lo hace más fácil agregar análisis, banderas de características o reglas específicas del servidor más tarde. Por ejemplo, algunos equipos permiten subir archivos de biblioteca para imágenes de perfil pero requieren capturas de cámara frescas para la verificación de identidad.

Si su aplicación más amplia también admite patrones de acceso a archivos fuera de Expo o está comparando convenciones entre pilas nativas, esto Capacitor referencia de la biblioteca de fotos es útil contexto.

Un demo corto ayuda cuando está mostrando este flujo a compañeros de equipo o QA:

¿Qué esperar del UI del sistema

expo-image-picker abre el selector de plataforma o la UI de la cámara. Su aplicación no controla cada pantalla en ese flujo. Esa distinción importa porque “funciona en mi dispositivo” a menudo significa “el sistema operativo permitió el camino que probé.”

On iOS, los usuarios pueden otorgar acceso a la biblioteca limitado en lugar de acceso completo. En Android, el comportamiento del selector puede variar según la versión del sistema operativo y la capa de la piel del proveedor. En proyectos de flujo de trabajo administrado, Expo maneja más de la cableado nativo por ti. En proyectos de flujo de trabajo desnudo, debes confirmar que tu aplicación construida incluye los cambios de permiso nativo que hiciste. El sitio de llamada de JavaScript puede ser idéntico en ambos casos, mientras que el resultado de tiempo de ejecución difiere.

Normalmente, pruebo estos casos antes de llamar a la característica hecha:

• primera solicitud de permiso
• permiso denegado
• cancelación del usuario
• selección de biblioteca exitosa
• captura de cámara exitosa en un dispositivo físico
• previsualización inmediata de la URI local devuelta

Estos casos se relacionan directamente con el comportamiento de producción real. También establecen el siguiente paso limpiamente si necesitas enviar el archivo a un servidor, una pila de moderación o un punto final de publicación como el publicación de medios de Instagram API.

Manejo de resultados y opciones del selector

El resultado del selector es la parte que normalmente necesita lógica de producción real. La interfaz de usuario del sistema devuelve un objeto estructurado, no solo una ruta de archivo, y pequeños errores aquí llevan a vistas rotas, subidas vacías o crash después de que un usuario cancela.

Leer el objeto de resultados correctamente

La forma del resultado que importa en las aplicaciones de Expo actuales es result.assets[0].uri, no un nivel superior result.uriEse detalle afecta tanto proyectos de flujo de trabajo gestionados como de flujo de trabajo desnudo porque el JavaScript API es el mismo aunque la configuración nativa difiera debajo.

Usa un patrón de guardia primero:

const result = await ImagePicker.launchImageLibraryAsync({
  mediaTypes: ['images'],
  allowsEditing: true,
  quality: 1,
});

if (result.canceled) {
  return;
}

const asset = result.assets?.[0];
if (!asset) {
  return;
}

const { uri } = asset;
setImageUri(uri);

Esto maneja los dos casos de falla que veo con más frecuencia. Un selector cancelado no te da un activo para leer, y code que asume result.assets[0] siempre existe fallará en tiempo de ejecución

Una vez que tengas la URI, renderizar una vista previa es sencillo:

<Image source={{ uri: imageUri }} style={{ width: 240, height: 240 }} />

Si planeas subir más tarde, mantén todo el asset alrededor, no solo la URI. En la práctica fileName, mimeType, width, height, y fileSize son útiles a menudo para la validación, el registro o la creación de una solicitud multipart más limpia.

Opciones que cambian el comportamiento downstream

Algunas opciones del selector afectan más que la pantalla de selección. Configuran el tamaño del archivo, el comportamiento de edición y qué debe aceptar su backend.

Algunos compromisos pueden pasar desapercibidos.

• allowsEditing es útil cuando el slot de imagen tiene una forma o tamaño fijos. Es menos útil si tu servidor realiza su propio pipeline de recorte y deseas el archivo original.
• quality afecta el tiempo de carga, la presión de memoria y el almacenamiento del servidor. quality: 1 no es la elección automática correcta.
• mediaTypes debe coincidir con las reglas del servidor. Si el servidor rechaza videos, no permitas que el selector los devuelva.
• base64 aumenta el tamaño del paquete en memoria. Evítalo a menos que el servicio receptor lo requiera.

Ese último punto es importante en dispositivos con memoria baja. Un URI de archivo local es usualmente la mejor opción para la vista previa y la subida de archivos multipartite. La codificación Base64 tiene usos válidos, pero es costosa en comparación con pasar una referencia de archivo.

URI versus base64

For most apps, the rule is simple:

• Usar URI para vistas previas.
• Usar URI para subir archivos.
• Usar base64 solamente cuando el sistema receptor solicita explícitamente contenido codificado.

Este patrón mantiene al picker code pequeño y más fácil de probar. También se alinea con cómo se construyen las flujos de medios de backend, incluidos servicios que eventualmente publican en plataformas externas como la La publicación de medios de Instagram API.

Si su equipo envía actualizaciones OTA frecuentes o mueve activos de imágenes a través de la entrega de aplicaciones, las decisiones de tamaño de archivo aquí tienen un impacto en el resto de la canalización. Esta guía sobre optimising images for app updates es una compañera útil para la configuración del selector.

A safer result pattern for real apps

Para demostraciones code, almacenar solo imageUri es suficiente. En producción, almacene un objeto normalizado para que el siguiente paso, la vista previa, la validación, la carga o la repetición, no necesite reinterpretar la respuesta del selector bruta cada vez.

const result = await ImagePicker.launchImageLibraryAsync({
  mediaTypes: ['images'],
  allowsEditing: true,
  quality: 0.8,
});

if (result.canceled || !result.assets?.length) {
  return;
}

const asset = result.assets[0];

setSelectedImage({
  uri: asset.uri,
  fileName: asset.fileName ?? 'upload.jpg',
  mimeType: asset.mimeType ?? 'image/jpeg',
  width: asset.width,
  height: asset.height,
  fileSize: asset.fileSize ?? null,
});

Esto le da una forma predecible dentro de la aplicación. También hace que los proyectos administrados y bare sean más fáciles de mantener alineados porque la aplicación code permanece estable mientras trabaja a través de las diferencias nativas en otro lugar.

Una última comprobación ayuda. No habilite campos de resultados adicionales solo por si acaso. Solicite los datos que sabe que necesita, y mantenga al selector enfocado en la selección en lugar de convertirlo en un paso general de procesamiento de archivos.

Pautas avanzadas y diferencias de plataforma

Un característica de selector suele dejar de ser simple en el momento en que la primera imagen seleccionada tiene que sobrevivir a las repeticiones, las cabeceras de autenticación, las diferencias de permisos nativos y un punto de carga de subida real. expo-image-picker maneja la selección bien. El resto de la característica está en tu aplicación.

Un patrón de carga práctica

Para las API que esperan una carga de archivo FormData es todavía la opción de seguridad más segura por defecto. Funciona en backends comunes de Rails, Node, Laravel, Django y Go, y mantiene el selector separado de las preocupaciones de transporte.

async function uploadImage(imageUri: string) {
  const formData = new FormData();

  formData.append('file', {
    uri: imageUri,
    name: 'upload.jpg',
    type: 'image/jpeg',
  } as any);

  const response = await fetch('https://your-api.example.com/uploads', {
    method: 'POST',
    body: formData,
    headers: {
      Accept: 'application/json',
    },
  });

  if (!response.ok) {
    throw new Error('Upload failed');
  }

  return response.json();
}

Eso code es suficiente para probar que el camino funciona, pero las aplicaciones de producción suelen necesitar una capa adicional. Derive name y type desde el activo seleccionado cuando sea posible, adjunta autenticación fuera de la función del selector, y mantén el estado de carga separado del estado del selector para que una solicitud fallida no fuerce al usuario a abrir la biblioteca de nuevo.

Unos pocos controles previenen las fallas comunes que veo en la revisión:

• Confirmar que el archivo local uri existe antes de construir la solicitud
• Render a preview before upload so users catch the wrong file early
• Evita pulsaciones repetidas mientras la solicitud está en ejecución
• Maneja fallas de red por separado de errores de cancelación del selector o permisos
• Espera que la validación del servidor rechace archivos grandes, tipos MIME no soportados o autenticación faltante

Si tu servidor requiere base64 en lugar de multipart, eso es usualmente una restricción del servidor, no una exigencia del selector. Multipart es más barato en memoria y más fácil de razonar sobre en dispositivos móviles

Dónde las diferencias entre plataformas importan realmente

La interfaz del selector es nativa, por lo que hereda el comportamiento nativo. Eso afecta tanto lo que los usuarios ven como lo que tu code debe asumir

En iOS, los flujos de edición y las solicitudes de permiso siguen las convenciones de Apple. El acceso limitado a Fotos puede devolver un conjunto más estrecho de activos que tu cuenta de prueba vio en un dispositivo con acceso completo. En Android, el comportamiento del selector varía más según la versión del sistema operativo y la piel del fabricante, especialmente alrededor de álbumes, nombres de archivo y cómo se devuelven las capturas de cámara. Las aplicaciones de React Native sin gestión sienten estas diferencias más directamente porque se posee más de la configuración nativa, pero las aplicaciones de Expo administradas todavía necesitan code que trate al selector como plataforma-formado en lugar de perfectamente uniforme

La regla práctica es simple. Dependes de los campos que puedes validar, no de la interfaz de usuario o la metadata identica entre dispositivos

Unos ejemplos importan en aplicaciones reales:

• Edición y recorte: El comportamiento de la interfaz y la recorte no son idénticos entre iOS y Android.
• Metadata devuelta: fileName, mimeTypey fileSize pueden faltar o ser inconsistentes, así que agrega valores por defecto
• Permisos: iOS photo access can be limited to selected items, while Android behavior depends more on OS version and system picker support
• Salida de cámara: Las imágenes capturadas pueden regresar con diferentes características de nombre, orientación o compresión que las imágenes de biblioteca.

Si su equipo también trabaja fuera de Expo, esto Guía de desarrollo de aplicaciones de DesignStack proporciona contexto de Android útil para decisiones de manejo de medios que se presentan más allá de una sola biblioteca

Diferencias entre flujo administrado y flujo desnudo

Hasta este punto, las opciones de configuración importan operacionalmente

En el flujo de trabajo administrado, las cadenas de permisos y la configuración del plugin suelen vivir en la configuración de la aplicación, y los cambios nativos se aplican cuando se crea una nueva compilación. Esto mantiene la superficie de JavaScript limpia, pero también significa que una corrección de configuración no es visible hasta la próxima compilación nativa. Las actualizaciones OTA no parchean permisos nativos faltantes

In el flujo de trabajo básico, la misma característica tiene más partes en movimiento. Necesitas verificar las descripciones de uso nativas de iOS, el comportamiento del manifiesto de Android, la instalación del paquete y el tiempo de reconstrucción por tu cuenta. El lado positivo es el control. El costo es que un problema de selector puede estar causado por la configuración nativa, no por el sitio de llamada de JavaScript.

Los equipos que cambian entre Expo y Capacitor subestiman a menudo cuán diferentes son estos niveles de abstracción. Capgo tiene una explicación útil de ¿cómo Capacitor maneja las diferencias de plataforma?y es un punto de comparación bueno si estás decidido a saber cuánta configuración nativa quieres que tu equipo tenga.

Mi preferencia es consistente en ambos flujos de trabajo. Mantén el selector code estrecho, normaliza el resultado una vez, sube a través de una capa API dedicada y trata el comportamiento específico de plataforma como algo que debes configurar y probar explícitamente en lugar de suavizarlo con suposiciones.

Solución de Problemas Comunes

La mayoría de los errores de Expo Image Picker se clasifican en una pequeña serie de categorías. La solución rápida es identificar qué capa está fallando: configuración, permisos, manejo de resultados o renderizado.

Verificaciones rápidas para fallas comunes

Si el selector no se abre o los permisos fallan, verifica la configuración nativa primero. En las aplicaciones básicas, especialmente, las descripciones de uso de iOS faltantes son una causa común de raíz.

Si la aplicación se cae después de que un usuario cierre el selector, revisa cómo manejas tus resultados. Muchas implementaciones asumen aún una URI directa y saltan la canceled comprobación.

Una serie de mapeos rápidos ayudan:

• Errores de permiso denegado: Verifique su configuración de la aplicación y las cadenas de permiso nativo, luego reconstruya.
• undefined URI de la imagen: Lea desde result.assets?.[0]?.uri, no result.uri.
• Nada sucede después de cancelar: Eso puede ser correcto. Maneje cancelar como un estado de no-op.
• La imagen no se muestra: Confirme que la URI se almacenó en el estado y se pasó a <Image source={{ uri }} />.
• La cámara actúa de manera extraña en el simulador: Prueba en un dispositivo físico antes de perseguir un error de biblioteca.

Un breve checklist de producción

Utiliza esto como paso final antes de enviar:

• Instala con herramientas de Expo: Utiliza npx expo install expo-image-picker.
• Configura piezas nativas: Agregar el plugin y descripciones de permisos requeridos.
• Solicita permisos de manera intencional: Separa flujos de cámara y biblioteca de medios.
• Guarda cada resultado: Verifica result.canceled y leer de manera segura assets[0].
• Preferir subir archivos mediante URI: Sólo mantenga base64 para casos especiales.
• Probar dispositivos reales: Especialmente para capturas de cámara y solicitudes de permisos.

Si su equipo envía aplicaciones Capacitor o Electron junto con proyectos de React Native Capgo es una opción para entregar actualizaciones de JavaScript, CSS, configuración y recursos sin tener que esperar a que cada cambio sea revisado por la tienda. Es relevante cuando se resuelven problemas relacionados con imágenes en la capa web, como la interfaz de usuario de carga, las reglas de validación, el texto o el manejo de recursos alrededor del flujo del selector de imágenes.