Guía completa de Expo Image Picker para 2026

Probablemente estás en el punto donde la interfaz de usuario está lista, la pantalla de perfil tiene un botón 'Subir foto' y ahora la parte fácil de repente no es fácil. El flujo real de selección de imágenes toca permisos nativos, interfaces controladas por el sistema, diferentes formas de retorno que muchos desarrolladores esperan y un puñado de detalles de compilación que solo se muestran después de enviar un verdadero compilado.

Es ahí donde la Selección de imágenes de Expo entra en juego. 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 más tarde, análisis de resultados seguro y un patrón de subida 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 cliente de desarrollo de Expo.

Contenido de la Tabla de Contenido

• Configuración de inicio con Expo Image Picker
• Instalación y configuración esencial
  • Configuración de flujo administrado
  • Detalles de configuración de React Native sin administrar
• Acceso a la cámara y biblioteca de medios
  • Un componente seguro pero mínimo
  • Flujos de biblioteca y cámara
  • ¿Qué esperar del interfaz de usuario del sistema?
• Manipulación de resultados y opciones del selector
  • Leer el objeto de resultado correctamente
  • Opciones que cambian el comportamiento downstream
  • URI versus base64
  • A un resultado más seguro para aplicaciones reales
• Diferencias avanzadas de patrones y plataforma
  • Un patrón de carga práctica
  • ¿Dónde las diferencias de plataforma importan realmente?
  • Diferencias entre flujo de trabajo gestionado y desnudo
• Resolución de problemas comunes
  • Verificaciones rápidas de fallas comunes
  • Un breve checklist de producción

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 permiso 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 carga de backend.

expo-image-picker ¿Es el 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 reside en obtener la configuración nativa, el flujo de permisos y el manejo de resultados correctos en proyectos tanto gestionados como desnudos.

El principal equilibrio es claro. Dejas que iOS y Android presenten sus propias interfaces de media 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.

Integración nativa con interfaz de React.

Esa mentalidad ayuda porque los modos de falla rara vez están en el botón que llama al selector. Normalmente provienen de uno de tres lugares:

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

La elección del 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 desnuda, 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 está utilizando 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 de Expo cambia la prueba de módulos nativos.

That split matters for the rest of the guide because the happy path is only half the story. A picker implementation is solid when it works in both workflows, handles platform-specific permission quirks without surprising the user, and passes a usable file to your upload layer instead of stopping at a local preview.

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 tu versión de producción.

expo-image-picker gives a React-facing API over the platform pickers for photos, videos, and camera capture. The JavaScript call is simple. The setup is not, because photo access and camera access are controlled by iOS and Android, not by React Native.

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

npx expo install expo-image-picker

Usa expo install en lugar de npm install o yarn add. Expo ajusta la versión del paquete a tu SDK, lo que evita un tipo común de problemas de compatibilidad nativa. Si estás comparando cómo los módulos de Expo se integran en tu proceso de lanzamiento, esta Resumen de herramientas de Expo es una referencia útil.

Configuración de flujo administrado

En el flujo administrado, declara el plugin en la configuración de la aplicación para que Expo pueda aplicar los cambios nativos en tiempo de compilación.

Ejemplo con app.json:

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

Es el mínimo configuración. En la práctica, los equipos suelen agregar texto de permiso también, especialmente en iOS donde la solicitud del sistema debe explicar por qué la aplicación necesita acceso. Mantén el texto específico para la acción del usuario. ‘Subir una foto de perfil’ es mejor que ‘Necesita acceso a medios’.

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

Detalles de configuración de React Native sin envoltura

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

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

1. Instalar expo-image-picker con npx expo install expo-image-picker.
2. Añade la configuración del complemento si tu proyecto utiliza plugins de configuración de Expo.
3. Confirma que las descripciones de uso de iOS coinciden con las características que expone.
4. Reconstruye las aplicaciones de iOS y Android después de cualquier cambio en la configuración nativa.

El texto de permiso faltante a menudo parece un error de ejecución porque la interfaz code está bien y el manipulador del botón se ejecuta. El error está más abajo en la pila. Normalmente, reviso la configuración de la aplicación y si el último cambio nativo está incluido en la compilación antes de tocar el componente code. Info.plist, the app config, and whether the current build includes the latest native changes before I touch the component code.

Escribe el texto de permiso para la acción real:

• Los usuarios deben entender por qué están viendo la solicitud. Configura la cámara y la biblioteca por separado:
• Una puede funcionar mientras la otra sigue fallando. Reconstruye después de los cambios nativos:
• La recarga caliente y la actualización rápida no actualizan los permisos nativos. Hot reload and fast refresh do not update native permissions.
• Prueba en dispositivo: El comportamiento del simulador puede ocultar problemas de permisos y cámara.

Si el selector funciona durante el desarrollo pero se rompe en la compilación de TestFlight o la tienda Play, considera que es un problema de configuración primero. La mayoría de las veces, es así.

Acceso a la Cámara y Biblioteca de Medios

Un usuario hace clic en ‘Subir foto’, espera que se abra la cámara o la biblioteca, y tu aplicación tiene una sola tarea en ese momento. Abrir la interfaz de usuario del sistema adecuada, manejar la negación o la cancelación sin romper la pantalla, y devolver una referencia local de archivo usable para la visualización o el envío.

Suena simple hasta que pruebas 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 operativo, el hardware del dispositivo y cómo configuraste las permisiones nativas anteriormente.

Un componente mínimo pero seguro

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

Un componente de referencia 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.
• Trate 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 array 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 característica que funcione. Es más fácil de probar, funciona en más configuraciones de simulador y evita los casos de hardware de la 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 del 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 hacer que busques 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 La referencia de la biblioteca de fotos Capacitor es contexto útil.

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

What to esperar del sistema UI

expo-image-picker abre la plataforma picker o la interfaz de 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é.”

En 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 piel del proveedor. En proyectos de flujo administrado, Expo maneja más de la cableado nativo por ti. En proyectos de flujo desnudo, debes confirmar que tu aplicación compilada 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 en tiempo de ejecución difiere.

Normalmente pruebo estos casos antes de considerar la función lista:

• 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
• preview inmediato de la URI local devuelta

Aquellos 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 de conexión de publicación como el Instagram media publishing API.

Manejo de Resultados y Opciones del Selector

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

Leer el objeto de resultado correctamente

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

Usar 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 tienes la URI, renderizar una vista previa es directo:

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

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

Opciones que cambian el comportamiento downstream

Un par de 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.

Unos pocos trade-offs son fáciles de pasar por alto:

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

El último punto es importante en dispositivos con memoria baja. Una URI de archivo local es usualmente la mejor entrega para la vista previa y el subir archivos en partes. La base64 tiene usos válidos, pero es costoso en comparación con pasar una referencia de archivo.

URI versus base64

Para la mayoría de las aplicaciones, la regla es simple:

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

Ese patrón mantiene al selector code pequeño y fácil de probar. También se alinea con cómo se construyen muchos flujos de medios de backend, incluidos servicios que eventualmente publican en plataformas externas como el 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 la aplicación, las decisiones de tamaño de archivo aquí se reflejan en el resto de la canalización. Esta guía sobre optimización de imágenes para actualizaciones de la aplicación es una compañera útil para la configuración del selector.

Un patrón de resultado más seguro para aplicaciones reales

Para demostraciones code, almacenar solo imageUri es suficiente. En producción, almacena 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 te 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 se mantiene estable mientras trabajas a través de las diferencias nativas en otro lugar.

Una última comprobación ayuda. No habilite campos de resultado 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.

Patrones Avanzados y Diferencias de Plataformas

Un característica de selección suele dejar de ser simple en el momento en que la primera imagen seleccionada tiene que sobrevivir a las reintentos, encabezados de autenticación, diferencias de permisos nativos y un endpoint de carga 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 APIs 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();
}

Que 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 de nuevo la biblioteca.

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

• Confirmar el local uri existe antes de construir la solicitud
• Mostrar una vista previa antes de subir el archivo para que los usuarios detecten el archivo incorrecto temprano
• Prevenir pulsaciones repetidas mientras la solicitud está en vuelo
• Gestionar fallas de red por separado de la cancelación del selector o errores de permiso
• Esperar que la validación del servidor rechace archivos grandes, tipos MIME no admitidos o autenticación faltante

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

En dónde las diferencias de plataforma realmente importan

La interfaz del selector es nativa, por lo que hereda el comportamiento nativo. Eso afecta tanto lo que los usuarios ven como lo que su 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 su 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 administrar 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-orientado en lugar de perfectamente uniforme.

La regla práctica es simple. Confíe en los campos que puede validar, no en la interfaz de usuario o la metadata idéntica en dispositivos.

Unos ejemplos importan en aplicaciones reales:

• Edición y recorte: The UI and crop behavior are not identical between iOS and Android
• Datos de metadatos devueltos: fileName, mimeType, y fileSize pueden estar ausentes o inconsistentes, por lo que se deben agregar valores por defecto
• Permisos: El acceso a fotos de iOS puede estar limitado a elementos seleccionados, mientras que el comportamiento de Android depende más de la versión del sistema operativo y el soporte del selector del sistema
• Salida de la cámara: Las imágenes capturadas pueden regresar con diferentes nombres, orientaciones o características de compresión que las características de los activos de la biblioteca

Si su equipo también trabaja fuera de Expo, este 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 flujos de trabajo administrados y bare

At este punto, las opciones de configuración comienzan a tener importancia operativa.

En el flujo de trabajo gestionado, las cadenas de permiso y la configuración del plugin suelen vivir en la configuración de la aplicación, y los cambios nativos se aplican cuando creas 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. Los actualizaciones OTA no parchean permisos nativos faltantes.

En el flujo de trabajo desnudo, la misma característica tiene más partes en movimiento. Debes verificar las descripciones de uso de iOS nativas, el comportamiento del manifiesto de Android, la instalación de paquetes y el tiempo de compilación por tu cuenta. El beneficio 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.

Teams that switch between Expo and Capacitor often underestimate how different these abstraction layers are. Capgo has a useful explanation of how Capacitor handles platform differencesy es un punto de comparación bueno si estás decidido a saber cuánta configuración nativa quieres que tu equipo tenga.

My preference is consistent across both workflows. Keep picker code narrow, normalize the result once, upload through a dedicated API layer, and treat platform-specific behavior as something to configure and test explicitly rather than smooth over with assumptions.

Resolució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 más rápida es identificar qué capa está fallando: configuración, permiso, manejo de resultados o renderizado.

Verificaciones rápidas para fallas comunes

Si el selector no se abre o fallan los permisos, compruebe la configuración nativa primero. En aplicaciones bare 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 cierra el selector, inspeccione el manejo de resultados. Muchas implementaciones asumen aún una URI directa y omiten el canceled comprobación.

Unos pocos mapeos rápidos ayudan:

• Errores de permisos denegados: Verifique la configuración de la aplicación y las cadenas de permisos nativos, luego reconstruya.
• undefined URI de imagen: Lee desde result.assets?.[0]?.uri, no result.uri.
• Nothing happens after cancel: se traduce a "Nada sucede después de cancelar:", pero para mantener la estructura de la lista, se puede traducir a "Nada sucede después de cancelar". Eso puede ser correcto. Maneje cancelar como un estado sin operaciones.
• La imagen no se renderiza: 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: Pruebe en un dispositivo físico antes de perseguir un error de biblioteca.

Un breve checklist de producción

Use esto como una revisión final antes de enviar:

• Instale con herramientas de Expo: Use npx expo install expo-image-picker.
• Configure piezas nativas: Agregue la descripción del plugin y las descripciones de permisos requeridos.
• Solicite permisos de manera intencional: Separar flujos de cámara y biblioteca de medios.
• Proteger cada resultado: Comprobar result.canceled y leer de manera segura assets[0].
• Preferir subidas basadas en URI: Sólo para casos especiales, mantener base64.
• Probar dispositivos reales: Es especialmente relevante para la captura de cámara y las 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 la revisión de la tienda para cada cambio. Es relevante cuando se resuelven problemas relacionados con imágenes en su 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 medios.