10 ejemplos para empezar con Operaciones de Store - 7 básicos y 3 intermedios. Cada ejemplo avanza un paso en el camino compilación → prueba → envío → lanzamiento → monitoreo para aplicaciones Expo SDK 57 en App Store Connect y Google Play Console.
Vincula el proyecto a EAS y configura al menos un perfil de compilación production en eas.json. Las cargas en la tienda requieren compilaciones store distribution - no artefactos development o de simulador.
Cada carga en la tienda necesita un nuevo número de compilación (iOS) y versionCode (Android). La version de marketing puede mantenerse igual para correcciones rápidas; los enteros nativos siempre deben aumentar.
// app.config.tsimport type { ExpoConfig } from "expo/config";const config: ExpoConfig = { expo: { name: "ShopApp", slug: "shop-app", version: "2.4.0", ios: { bundleIdentifier: "com.example.shopapp", buildNumber: "240012", // CFBundleVersion - aumenta en cada carga }, android: { package: "com.example.shopapp", versionCode: 240012, // entero monótono - aumenta en cada carga }, },};export default config;
version es semver visible al usuario en ambas tiendas
buildNumber / versionCode deben aumentar incluso para reconstrucciones de 'misma versión'
CI puede derivar enteros de git rev-list --count HEAD - documenta el esquema en README
Ejecuta npx expo config --type public antes de compilar para detectar errores tipográficos
El envío de la tienda comienza con binarios con forma de lanzamiento firmados con credenciales de producción.
# Un comando por plataforma (o ambos)eas build --profile production --platform ioseas build --profile production --platform android# Verifica que la compilación haya terminadoeas build:list --limit 5
Detecta desvío de SDK y errores de configuración antes de perder un ciclo de revisión.
npx expo-doctornpx expo config --type public > /tmp/public-config.jsonnpm run typechecknpm test -- --ci
<!-- docs/release-gates.md - copia en cada PR de lanzamiento -->## Compuerta previa al envío- [ ] expo-doctor en verde- [ ] Compilación de lanzamiento instalada en dispositivo iOS + Android- [ ] Inicio en frío, inicio de sesión, muro de pago, tap de push, enlace profundo, cierre de sesión, eliminación de cuenta- [ ] Las etiquetas de privacidad / Seguridad de datos coinciden con el inventario de SDK- [ ] Notas de revisión actualizadas con credenciales de demostración
expo-doctor marca versiones de paquetes incompatibles con SDK 57
Trata la prueba de humo del dispositivo como innegociable - Los rechazos de Directriz 2.1 suelen ser 'bloqueos al iniciar'
Mantén las compuertas en git para que los nuevos ingenieros no dependan de la memoria tribal
La copia de listado, URLs y palabras clave no deben existir solo en App Store Connect o Play Console - versiónalas junto al código.
// store/metadata.ts - fuente única para ambas tiendasexport const storeMetadata = { appName: "ShopApp", subtitle: "Escanea, guarda, paga rápido", shortDescription: "Compra más inteligente con escaneo de códigos de barras, listas guardadas y pago seguro.", fullDescription: `ShopApp te ayuda a crear listas de compras, comparar precios y pagar en segundos.• Escáner de códigos de barras para adiciones en el pasillo• Listas compartidas del hogar• Inicio de sesión seguro y eliminación de cuenta en Configuración`, keywords: ["compras", "escáner", "compra", "lista"], privacyPolicyUrl: "https://example.com/privacy", supportUrl: "https://example.com/support", marketingUrl: "https://example.com",} as const;
Pega desde este archivo en Connect y Play - reduce la desviación de errores tipográficos entre plataformas
URL de política de privacidad debe cargarse sin inicio de sesión - los revisores y bots de Play lo verifican
Localiza en store/metadata.en.ts, store/metadata.de.ts cuando agregues configuraciones regionales
Los revisores necesitan credenciales funcionales, banderas de características desactivadas y rutas de reproducción - especialmente para aplicaciones Expo con acceso por inicio de sesión.
<!-- store/review-notes-ios.md -->## Notas de App Review (iOS)**Cuenta de demostración**- Correo electrónico: reviewer@example.com- Contraseña: ReviewDemo2026!**Cómo probar el flujo principal**1. Inicia la aplicación → toca Iniciar sesión → usa la cuenta de demostración anterior2. Inicio → toca Escanear → otorga Cámara cuando se solicite → escanea cualquier UPC3. Perfil → Configuración → Eliminar cuenta (obligatorio para aplicaciones de creación de cuenta)**Backend**- API de Producción; no se requiere VPN- Notificaciones push: envía prueba desde Perfil → Prueba de notificación**ATT / rastreo**- No rastreamos usuarios entre aplicaciones; el aviso de ATT no se muestra- Analytics: solo de primera parte (bloqueos de Sentry, sin ID de anuncio)**Contacto**- engineering-mobile@example.com (responde dentro de 4 horas hábiles)
Adjunta el mismo contenido en App Store Connect → Información de App Review → Notas
Actualiza contraseñas en cada lanzamiento - las cuentas de demostración caducadas causan rechazos falsos
Menciona si las características están bloqueadas geográficamente o requieren hardware (NFC, LiDAR)
La aprobación de la tienda no es la meta - observa bloqueos y ANRs a medida que aumenta el porcentaje de lanzamiento.
// lib/releaseHealth.ts - etiqueta sesiones con compilación de tiendaimport * as Application from "expo-application";import Constants from "expo-constants";export function releaseContext() { return { appVersion: Application.nativeApplicationVersion, buildNumber: Application.nativeBuildVersion, updateId: Constants.expoConfig?.updates?.checkAutomatically, platform: Application.applicationId, };}
## Primeras 72 horas después de lanzamiento- [ ] Sesiones sin bloqueos ≥ 99.5% (Sentry / Play Vitals)- [ ] Sin picos en reseñas de 1 estrella que mencionen 'bloqueo' o 'inicio de sesión'- [ ] Lanzamiento por fases iOS día 1-2: mantén en 1% si los bloqueos aumentan- [ ] Lanzamiento por etapas Play: pausa en 20% si la tasa de ANR se duplica de la línea base- [ ] Macro de bandeja de soporte listo para respuestas de 'actualizar aplicación'
Compara número de compilación en reportes de bloqueos con la compilación que promocionaste - OTA no puede arreglar regresiones nativas
Un calendario recurrente previene sorpresas de 'envío del viernes' y alinea el marketing con el tiempo de lanzamiento por fases.
<!-- docs/release-train.md -->| Semana | Actividad | Propietario ||------|----------|-------|| T-14 | Congelación de características en `main` | EM || T-10 | Crea `release/x.y.z`, aumenta números de compilación | Líder móvil || T-7 | TestFlight + Interno de Play a QA | QA || T-5 | Metadatos + formularios de privacidad aprobados | PM + Legal || T-3 | `eas submit` ambas plataformas | Líder móvil || T-2 | iOS: enviar para revisión; Android: producción con lanzamiento de 5% | Líder móvil || T-0 | iOS: lanzamiento con 7 días por fases; Android: 20% → 50% → 100% | Líder móvil || T+1 | Go/no-go de paneles de crash | De guardia |
Lanzamiento por fases iOS tarda hasta 7 días en alcanzar el 100% - planifica los impulsos de marketing después del día 3-4 si las métricas están limpias
Lanzamiento por etapas Play es un porcentaje manual - documenta quién puede pausarlo (ver manual de incidentes)
Los formularios de comerciante de la Ley de Servicios Digitales de la UE y las clasificaciones por edad deben completarse antes de T-3 o los territorios de la UE bloquean