> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # Publicación en las tiendas de aplicaciones Distingue una compilación que funciona de una versión que los usuarios pueden instalar. ## Prepara tu primer envío a tienda paso a paso Primero cree y pruebe una compilación de desarrollo nativa utilizando compilaciones móviles. Un envío a la tienda envía la aplicación compilada y su listado a Google o Apple para su revisión; no es lo mismo que abrir una vista previa de Expo Go. Necesita su propio Expo y cuentas de desarrollador de tienda relevantes, un backend HTTPS probado, nombre/ícono final de la aplicación, capturas de pantalla, contacto de soporte y una política de privacidad pública URL. Abra apps/mobile/app.json en el editor y configure el nombre de la aplicación, slug, ios.bundleIdentifier y android.package para su propio producto antes de la primera carga. Abra apps/mobile/eas.json y reemplace los identificadores de aplicaciones del equipo de envío de iOS con los suyos propios cuando sea necesario. Los identificadores enviados son ejemplos. Lea las compilaciones móviles para conocer los campos exactos y solicite a su agente de codificación que revise los dos archivos antes de compilarlas. Si eas no está instalado, ejecute npm install --global eas-cli. Desde la raíz del repositorio, use el comando de inicio de sesión a continuación, finalice la autenticación del navegador, luego seleccione el comando de compilación para una plataforma en Build y luego envíe. Leer los registros del panel de la compilación; espere a que .aab o .ipa sea exitoso antes de intentar enviarlo. EAS solicita credenciales de firma y vinculación de proyectos; estos pertenecen a sus cuentas, no a las del vendedor del kit. Después de cargar el binario, abra su aplicación en Play Console o App Store Connect, complete la lista y los cuestionarios requeridos, agregue las instrucciones de inicio de sesión del revisor en funcionamiento y luego envíelo para su revisión allí. Cargar un borrador interno no es un comunicado público. Si la revisión lo rechaza, abra el enlace de la política exacta en el rechazo y corrija ese problema antes de volver a enviarlo. [Prepare la compilación nativa y los identificadores](https://supastack.dev/es/docs/mobile/builds.md) [Instrucciones de envío de la tienda actual de Expo](https://docs.expo.dev/submit/introduction/) [Directrices actuales de revisión de aplicaciones de Apple](https://developer.apple.com/app-store/review/guidelines/) [Instrucciones de lanzamiento de Google Play](https://support.google.com/googleplay/android-developer/answer/9859455) ``` corepack pnpm --filter @supastack/mobile exec eas login ``` ## Configura las cuentas una sola vez Para enviar a las tiendas hacen falta tres cuentas: una cuenta Expo gratuita para EAS Build y Submit, el registro de desarrollador de Google Play Console y una membresía de Apple Developer Program para iOS. Instala EAS CLI y ejecuta eas login antes de compilar; la verificación de ambas inscripciones puede tardar días, así que empieza pronto. Cambia los identificadores de la aplicación antes de la primera carga: android.package e ios.bundleIdentifier se publican como com.supastack.app en apps/mobile/app.json. Google Play bloquea el nombre de paquete en la primera carga, así que un identificador incorrecto requiere una entrada nueva de aplicación en vez de renombrarla. ## Deja que EAS gestione la firma apps/mobile/eas.json define perfiles de compilación development, preview y production. El perfil production permite a EAS generar y guardar el keystore de Android y el certificado de distribución de iOS en su infraestructura; más tarde puedes inspeccionarlos con eas credentials y mantén los keystores locales fuera del repositorio. El envío automatizado a Play requiere una clave JSON de cuenta de servicio de Google vinculada en Play Console → Setup → API access con permiso de lanzamiento. Guárdala en apps/mobile/secrets/play-store-service-account.json, la ruta que espera eas.json y un directorio ignorado por git. La primera carga de una aplicación nueva aún se hace manualmente en Play Console; eas submit se encarga a partir del segundo lanzamiento. ## Compila y luego envía Las compilaciones se ejecutan en infraestructura EAS, así que no hace falta instalar Android Studio ni Xcode para generar el binario. El perfil production produce un .aab listo para la tienda para Play y un .ipa para App Store con números de versión gestionados remotamente. El perfil preview produce un APK de distribución interna para pruebas de control de calidad en dispositivos físicos. El perfil de envío incluido apunta a la pista interna de Play como borrador: nada llega a quienes prueban hasta que lo promociones dentro de Play Console después de superar la revisión. ``` corepack pnpm --filter @supastack/mobile build:android corepack pnpm --filter @supastack/mobile submit:android corepack pnpm --filter @supastack/mobile build:ios corepack pnpm --filter @supastack/mobile submit:ios # Internal-testing APK for a physical device: corepack pnpm --filter @supastack/mobile build:android:preview ``` ## Completa los formularios de Play Console La revisión de Play depende tanto del contenido declarado como del binario: URL pública de política de privacidad, formulario de seguridad de los datos, cuestionario de clasificación del contenido, público objetivo y categoría. Responde al formulario de seguridad de los datos según el comportamiento real de la aplicación: el kit recopila el correo de la cuenta para autenticación, guarda tokens de sesión en el almacenamiento seguro de la plataforma y se comunica solo con la API configurada; añade lo que incorpore tu producto. Para una aplicación de iOS que requiere inicio de sesión, proporcione a App Review una cuenta de demostración funcional e instrucciones en las notas de revisión. Revise la regla actual de servicios de inicio de sesión de Apple y sus excepciones antes de elegir opciones de inicio de sesión social; los requisitos dependen del flujo de inicio de sesión real de la aplicación. Las pautas oficiales están vinculadas en la sección anterior de primera presentación. ## Pon las compras detrás de RevenueCat primero Si tu app ofrece compras móviles, configura el flujo de RevenueCat incluido: establece `MOBILE_PURCHASES_PROVIDER=revenuecat` y `EXPO_PUBLIC_MOBILE_PURCHASES_PROVIDER=revenuecat`, y añade la clave SDK pública correspondiente a iOS o Android. La app nativa admite compras y restauraciones; después de cada operación, el acceso se actualiza con el derecho del espacio de trabajo verificado por el servidor. El flujo móvil no usa Stripe Checkout. Mantén el paywall desactivado si las compras están en off o falta una configuración necesaria. Valida los productos configurados, la compra, la restauración y la actualización del derecho en una compilación de desarrollo EAS con cuentas de prueba de las tiendas. Consulta las indicaciones actuales de cada tienda para los requisitos aplicables a tu app y a tus regiones. ## Lista previa al envío Antes de enviar, confirme cada elemento a continuación utilizando su propia aplicación de prueba y cuentas de tienda. - android.package e ios.bundleIdentifier cambiados a un identificador de tu propiedad - EXPO_PUBLIC_API_URL en el entorno de compilación apunta a la API de producción - Política de privacidad alojada en una URL pública y enlazada desde la ficha de la tienda - El formulario de seguridad de los datos coincide con la recopilación real: correo de autenticación, tráfico de API y cualquier dato que añada tu producto - Credenciales funcionales de una cuenta demo en las notas de revisión de App Store - Control de acceso de pago oculto o respaldado por un derecho de RevenueCat verificado - Retorno de enlace profundo, restauración de sesión y cierre de sesión verificados en un dispositivo físico - Capturas de pantalla y recursos de la ficha preparados para cada tienda ## Recupérate de un rechazo Los rechazos llegan con una referencia a la política: corrige la causa declarada en vez de adivinar el síntoma. Una discrepancia en Seguridad de los datos suele significar que el formulario está mal, no la aplicación. Un rechazo que exige inicio de sesión suele significar que las notas de revisión no incluían una cuenta demo. Vuelve a enviar con notas de versión que describan claramente la corrección. El recorrido completo —comandos de credenciales, orden de operaciones de consola y guía para rechazos— está en docs/mobile-store-submission.md del repositorio. ## Configuración y ajustes Para publicar una app nativa necesitas cuentas de desarrollador de Apple o Google, identificadores de app, credenciales de firma y la revisión de la tienda. El perfil de producción de EAS incrementa los números de compilación de la tienda; submit.production envía un lanzamiento en borrador al canal interno de Google Play. Los identificadores del bundle y el esquema de la app están en apps/mobile/app.config.ts. Los despliegues web y los lanzamientos en tiendas tienen ritmos distintos. Mantén la API compatible con la versión más antigua admitida o controla las nuevas funciones mediante el estado del servidor. ``` corepack pnpm --filter @supastack/mobile build eas build --profile production --platform ios eas build --profile production --platform android eas submit --profile production --platform ios eas submit --profile production --platform android ``` ## Flujo de implementación Antes de habilitar las compras nativas, configura el proyecto, los productos de las tiendas y el entitlement en RevenueCat. La clave secreta del servidor y el valor Authorization del webhook solo deben estar en la configuración del servidor; las claves SDK de iOS y Android son valores públicos de compilación. Desactiva el acceso sandbox en producción. Incluye los materiales de la tienda —capturas, descripción, respuestas sobre privacidad e información de compra— en los materiales de publicación del propio producto. RevenueCat comprueba las compras y restauraciones con el estado actual del suscriptor en el servidor antes de que la app muestre el acceso. ## Verificación y solución de problemas Prueba exactamente el artefacto que vas a enviar: callback de inicio de sesión, restauración de sesión, compra y restauración, actualización del derecho de acceso del servidor, cambio de espacio de trabajo, enlaces profundos y modo sin conexión en un dispositivo físico. Una exportación local correcta no es una compilación lista para la tienda. Registra el número de compilación, el canal de la tienda, el estado de revisión y el entorno de la API de cada lanzamiento. Un rechazo de revisión es un evento de lanzamiento: corrige los metadatos o los indicadores de capacidad en vez de hacer cambios a ciegas. Siguiente superficie: la pestaña Desktop recorre el mismo producto en la shell de Tauri. ## Siguiente [Descripción general de escritorio](https://supastack.dev/es/docs/desktop.md)