Guía de revisión de apps 2026: Checklist para Apple y Google Play

Respuesta rápida: Guías de revisión de apps son las reglas que Apple y Google aplican antes de que tu app se publique. Las de Apple Directrices de revisión de la App Store se organizan en Seguridad, Rendimiento, Negocio, Diseño y Legal. Google Play revisa tu versión según las Políticas del Programa de Desarrolladores además de los requisitos de Play Console como la clasificación de contenido y la seguridad de datos. Tiempos de revisión: Apple afirma que App Review funciona las 24 horas y suele completar al menos el 50% de los envíos en 24 horas y 90% en 48 horas (Revisión de la app). Google indica que algunas cuentas pueden esperar hasta siete días o incluso más en casos excepcionales (Publica tu app). Las nuevas cuentas personales de Play Console también pueden requerir al menos 12 testers que permanezcan activos durante 14 días consecutivos en closed testing, con al menos 12 testers activos al momento de solicitar el acceso a producción. Los primeros rechazos suelen deberse a 2.1 Integridad de la app (crashes, enlaces rotos, cuentas de demo defectuosas), 2.3 Metadatos precisos, y 5.1 Privacidad en iOS, además de políticas de Play incompletas o pasos de prueba en Android. Para las directrices 4.2 y 4.3 estrategia, lee cómo pasar la revisión de la App Store en 2026. Para valoraciones y controles parentales, consulta la guía de clasificación de edad de la app store. Para tasas de inscripción, consulta costo de publicar una app en el App Store.

Enviar tu primera app a la App Store o Play Store puede ser abrumador. Con directrices en constante evolución y una aplicación más estricta en 2026, conseguir la aprobación requiere mucha atención al detalle. Esta checklist repasa lo que se revisa en un primer envío tanto para iOS como para Android, con guías de rechazo de Apple más detalladas en nuestra cómo pasar la revisión de la App Store en 2026 guía cuando necesites detalles más profundos que este resumen.

Entender el proceso de revisión en 2026

Tanto Apple como Google han endurecido sus procesos de revisión en los últimos años, enfocándose especialmente en privacidad, seguridad y experiencia de usuario. Entender estos cambios es crucial para desarrolladores primerizos.

Plazos de revisión en la App Store de iOS

Apple publica los plazos en su Revisión de la app página:

• Plazos típicos: Al menos el 50% de los envíos se revisan en menos de 24 horas, y el 90% en menos de 48 horas
• Envíos incompletos: La revisión puede retrasarse o fallar si faltan metadatos, acceso a la demo o respuestas de cumplimiento
• Apps complejas: Apple indica que las apps que requieren mayor escrutinio pueden tardar más (Tras el envío)
• Revisión acelerada: Disponible para correcciones de bugs críticos o eventos con fecha límite tras enviar por App Store Connect y solicitar mediante el formulario de revisión acelerada de Apple

Planifica basándote en los promedios de publicación, no en picos anecdóticos, y trata cada nota de revisión faltante como un riesgo de retraso.

Estados de App Store Connect que verás

• Preparar para envío: Tu build o metadatos aún se están preparando
• Esperando revisión: Apple tiene tu envío en cola
• En revisión: El equipo de revisión está analizando la app
• Pendiente de lanzamiento del desarrollador: Aprobado, pero a la espera de tu lanzamiento manual
• Rechazado / Problemas sin resolver: Apple requiere cambios antes de aprobar

Tiempos de revisión en Google Play Store (actualización 2026)

Tiempos de revisión de Google Publica tu app:

• Publicación estándar: Las actualizaciones se procesan y publican lo antes posible tras la revisión
• Revisión extendida: En algunas cuentas de desarrollador, Google puede tardar hasta siete días o incluso más en casos excepcionales
• Requisito de pruebas cerradasLas cuentas personales creadas después del 13 de noviembre de 2023 requieren al menos 12 testers que permanezcan inscritos de forma continua durante al menos 14 días consecutivos de pruebas cerradas, y al menos 12 testers deben seguir inscritos cuando solicites el acceso a producción
• Tras las pruebas: La revisión de producción sigue sujeta a las políticas de Play antes de que la app se publique

Actualización importante: Google ahora exige pruebas mucho más rigurosas para algunas cuentas nuevas de Play Console, algo que explicaremos en detalle más abajo.

Configuración de la cuenta de Apple Developer

Antes de tu primer lanzamiento en iOS, asegúrate de configurar correctamente la parte de Apple:

• Inscríbete en el Apple Developer Program
• Activa la autenticación de dos factores en la cuenta de Apple usada para el registro
• Elige el tipo de membresía correcto:
  • Individual / Empresario individual: tu nombre legal personal será el nombre del vendedor en el App Store
  • Organizaciónrequiere una entidad legal, un número D-U-N-S, un sitio web público y una persona con autoridad para vincular a la empresa con los acuerdos de Apple
• Usa nombres legales al registrarte. Usar alias o nombres de empresa en los campos de nombre/apellido puede retrasar la aprobación
• Tras la aprobación, inicia sesión en App Store Connect y crea el registro de la app con el bundle ID, nombre, SKU e idioma principal

Importante: Apple cambia los requisitos mínimos de SDK con el tiempo. A partir de 28 de abril de 2026, las apps subidas a App Store Connect deben usar iOS & iPadOS 26 SDK o superior.

El requisito crítico de testing en Android

Este es el cambio que suele pillar desprevenidos a los nuevos editores de Android:

Requisito de 12 testers para nuevas cuentas personales de Android

Si tu cuenta de desarrollador de Google Play es una cuenta personal creada después del 13 de noviembre de 2023, debes completar un periodo de pruebas cerradas antes de que la app pueda pasar a producción:

Requisitos:

• Mínimo 12 testers: Debes tener al menos 12 testers que permanezcan inscritos de forma continua
• Periodo de pruebas de 14 días: Esos testers deben permanecer inscritos mientras la app esté en pruebas cerradas durante un mínimo de 14 días consecutivos
• Solicitud de acceso a producción: Al presentar la solicitud, al menos 12 testers deben seguir inscritos tras el periodo de pruebas cerradas
• Recopilación de feedback: Debes documentar los problemas encontrados, las correcciones realizadas y cómo los testers usaron la app

Cómo configurar tu canal de testing

Por qué Google implementó esto

Google introdujo este requisito para:

• Reduce el spam de apps de baja calidad
• Asegura que las apps se prueben bien antes de llegar al usuario
• Identifica apps maliciosas mediante patrones de uso real
• Mejora la calidad general de la Play Store

Comprobación realista: Esto añade al menos 2-3 semanas a tu cronograma de lanzamiento. Planifica con tiempo y empieza a reclutar testers pronto.

Requisitos de autenticación e inicio de sesión

Uno de los motivos de rechazo más comunes es la implementación incorrecta de sistemas de autenticación, especialmente el social login.

El requisito de Apple Sign-In (crítico para iOS)

Regla de Apple (Guideline 4.8, Login Services): Si tu app usa un servicio de login social o de terceros (Google, Facebook, X, etc.) para configurar o autenticar la cuenta principal, también debes ofrecer una opción de login equivalente que limite la recolección de datos al nombre y email del usuario, permita mantener el email privado y no recolecte interacciones para publicidad sin consentimiento. Sign in with Apple cumple las tres condiciones, por lo que sigue siendo la forma más sencilla de cumplir en 2026.

Esto se aplica a:

• Inicio de sesión con Google
• Facebook Login
• Inicio de sesión con Twitter/X
• Inicio de sesión con LinkedIn
• Cualquier otro servicio de autenticación de terceros

Esto NO aplica a:

• Autenticación solo con email/contraseña
• Sistemas de identificación gubernamental
• Sistemas SSO empresariales (si la app es para esa empresa)
• Sistemas de autenticación de proveedores educativos

¿Es obligatorio usar Sign in with Apple si mi app ofrece Google o Facebook login en 2026?

No estrictamente, pero en la práctica es el camino más fácil. Desde que Apple revisó la Guideline 4.8 en enero de 2024, cualquier app que use un login de terceros como Google o Facebook para crear o autenticar la cuenta principal también debe ofrecer una opción de login equivalente centrada en la privacidad: que limite los datos a nombre y email, permita un email privado y no rastree usuarios para anuncios sin consentimiento. Sign in with Apple cumple con esas reglas, por lo que la mayoría de los equipos lo añaden. Las excepciones incluyen apps que solo usan su propio sistema de cuentas, apps que requieren una cuenta educativa o empresarial existente, y apps que usan un sistema de ID ciudadano o ID electrónico respaldado por el gobierno o la industria. Ver el requisito de Apple Sign-In y la plugin de Capgo social login.

Implementar Sign in with Apple

Si usas social login, esto es lo que debes implementar:

import { SignInWithApple } from '@capacitor-community/apple-sign-in';

async function signInWithApple() {
  try {
    const result = await SignInWithApple.authorize({
      clientId: 'com.yourapp.service',
      redirectURI: 'https://yourapp.com/auth/callback',
      scopes: 'email name',
      state: '12345',
      nonce: 'nonce',
    });

    // result contains:
    // - identityToken
    // - authorizationCode
    // - email (may be null if user previously authorized)
    // - givenName
    // - familyName

    // Send to your backend for verification
    await verifyAppleToken(result.identityToken);

  } catch (error) {
    console.error('Apple Sign In failed:', error);
  }
}

Consideraciones importantes:

1. Privacidad del email: Los usuarios pueden elegir ocultar su email. Apple ofrece un email de relay privado (ej., abc123@privaterelay.appleid.com). Tu app debe gestionarlo.

2. Usuarios nuevos vs. recurrentes: Apple solo entrega los datos (nombre, email) en la primera autorización. Guárdalos, ya que los siguientes inicios de sesión no los incluirán.

3. Diseño del botón: Apple ofrece directrices de diseño estrictas para el botón de Sign in with Apple. Usa sus assets oficiales.

4. Verificación en el Backend: Verifica siempre el identity token en tu servidor backend; nunca confíes solo en los tokens del cliente.

Requisitos de Social Login en Android

Aunque Android no requiere un proveedor específico como iOS, Google tiene sus propias directrices:

Requisitos de Google Sign-In:

• Debes usar el SDK oficial de Google Sign-In
• Debes seguir las guías de branding de Google
• Debe ser la opción principal si la ofreces

Buena práctica para multiplataforma: Ofrece las mismas opciones de login en ambas plataformas para mantener la consistencia:

• Email/contraseña
• Sign in with Apple (solo iOS, o en Android si soportas el login con Apple vía web)
• Iniciar sesión con Google
• Otras opciones sociales (Facebook, Twitter, etc.)

Requisitos de la cuenta de demo

Crítico para la revisión: Si tu app requiere login, debes usar proporcionar credenciales de demo válidas en las notas de revisión de la app.

Demo Account Information:

Username: reviewer@demo.com
Password: ReviewTest123!

OR

Test Phone: +1 555-0123
Test OTP: 123456 (static for review)

Notes:
- This account has full premium features enabled
- All payment flows work in sandbox mode
- Account will reset daily

Errores comunes:

• Proporcionar credenciales caducadas
• La cuenta demo no tiene acceso a todas las funciones
• No mencionar cómo saltarse la verificación telefónica
• Olvidar mencionar los detalles de pago del sandbox

Política de privacidad y requisitos legales

Ambas tiendas de apps ahora exigen políticas de privacidad y términos de servicio accesibles antes se apruebe tu primer envío.

Requisitos de la política de privacidad

Tu política de privacidad debe:

1. Ser de acceso público

   • Estar alojada en una URL pública (sin login)
   • Poder cargarse en navegadores web estándar
   • Estar disponible en los mismos idiomas que tu app

2. Cubrir estos temas obligatorios:

   • Qué datos recopilas (sé específico)
   • Cómo usas los datos recopilados
   • Si compartes datos con terceros
   • Cuánto tiempo se conservan los datos
   • Derechos del usuario (acceso, borrado, portabilidad)
   • Contacto para consultas de privacidad
   • Privacidad infantil (si la app es para menores de 13/16 años)

3. Debe estar enlazada en la app

   • Accesible desde ajustes o la pantalla de cuenta
   • Debe estar a un solo toque (no oculto en menús)
   • Debe abrirse en el navegador predeterminado o en el navegador in-app

Dónde alojar tu política de privacidad

Opción 1: Tu sitio web (Recomendado)

https://yourapp.com/privacy-policy
https://yourapp.com/terms-of-service

Opción 2: GitHub Pages (Gratis)

https://yourusername.github.io/app-privacy-policy

Opción 3: Generadores de políticas de privacidad (Inicio rápido)

• Termly
• PrivacyPolicies.com
• FreePrivacyPolicy.com

Importante: Aunque los generadores sirven para empezar, asegúrate de que la política refleje con precisión tus prácticas reales de datos. Las plantillas genéricas que no coincidan con tu app serán señaladas.

Requisitos de Términos y Condiciones

Aunque no siempre es obligatorio, se recomienda encarecidamente tener Términos y Condiciones si:

• Ofreces compras in-app o suscripciones
• Tienes contenido generado por el usuario
• Ofreces algún servicio más allá de la funcionalidad básica de la app
• Buscas protección legal

Debe incluir:

• Política de uso aceptable
• Condiciones de terminación de cuenta
• Limitación de responsabilidad
• Derechos de propiedad intelectual
• Proceso de resolución de disputas
• Política de reembolsos (especialmente para IAP)

Implementación in-app

// Settings or Account Screen
function LegalLinks() {
  return (
    <div className="legal-section">
      <h3>Legal</h3>
      <a
        href="https://yourapp.com/privacy-policy"
        target="_blank"
        rel="noopener noreferrer"
      >
        Privacy Policy
      </a>
      <a
        href="https://yourapp.com/terms-of-service"
        target="_blank"
        rel="noopener noreferrer"
      >
        Terms of Service
      </a>
      <a
        href="https://yourapp.com/contact"
        target="_blank"
        rel="noopener noreferrer"
      >
        Contact Us
      </a>
    </div>
  );
}

Requisitos de metadatos de la App Store

Ambas tiendas exigen la URL de la política de privacidad al enviar la app:

iOS - App Store Connect:

• Información de la app > Información general > URL de la política de privacidad
• Debe ser HTTPS (HTTP se rechazará)
• Se mostrará en tu página de la App Store
• Añade una URL de soporte con datos de contacto reales para usuarios
• Completa el cuestionario de clasificación de edad antes de enviar

Android - Google Play Console:

• Presencia en la tienda > Configuración de la tienda > Política de privacidad
• Obligatorio para todas las apps dirigidas a niños
• Muy recomendado para todas las apps

Etiquetas de privacidad (iOS)

iOS requiere declaraciones detalladas de privacidad en formato de “etiqueta de privacidad”:

Categorías que debes declarar:

• Información de contacto: Email, nombre, número de teléfono
• Información financiera: Datos de pago, tarjeta de crédito, cuenta bancaria
• Ubicación: Ubicación precisa o aproximada
• Contenido del usuario: Fotos, videos, audio, mensajes
• Identificadores: ID de usuario, ID de dispositivo, ID de publicidad
• Datos de uso: Interacción con el producto, datos publicitarios, crash logs
• Diagnósticos: Datos de fallos, datos de rendimiento

Para cada tipo de dato, especifica:

• Ya sea que se recopile
• Si está vinculado a la identidad del usuario
• Si se usa para tracking
• La finalidad de la recopilación

Error común: Decir que no recopilas datos cuando tu SDK de analytics sí lo hace. Audita la recopilación de datos de todos los SDK de terceros.

Sección de seguridad de datos de Google Play

Al igual que en iOS, Android requiere una declaración de seguridad de datos:

Pasos:

1. Ve a Play Console > Contenido de la aplicación > Seguridad de los datos
2. Responde preguntas sobre la recolección de datos
3. Especifica los tipos de datos recolectados
4. Explica tus prácticas de seguridad (cifrado, etc.)
5. Proporciona el enlace a tu política de privacidad

Crítico: Esta información es legalmente vinculante. Mentir puede causar la eliminación de la app y la suspensión de la cuenta.

Motivos comunes de rechazo inicial

Entender por qué rechazan las apps te ayudará a evitar estos errores:

1. La app se bloquea o no inicia

Por qué sucede:

• Probar solo en emuladores y no en dispositivos reales
• No gestionar errores ante fallos de red
• Endpoints de API hardcodeados e inaccesibles
• Asumir capacidades específicas del dispositivo (cámara, GPS)

Cómo prevenirlo:

// Always implement proper error handling
async function loadData() {
  try {
    const response = await fetch('https://api.yourapp.com/data');

    if (!response.ok) {
      throw new Error(`HTTP ${response.status}`);
    }

    const data = await response.json();
    return data;

  } catch (error) {
    // Show user-friendly error
    showError('Unable to load data. Please check your connection.');

    // Log for debugging
    console.error('Data load failed:', error);

    // Graceful degradation
    return getCachedData();
  }
}

Checklist de pruebas:

• Probar en dispositivos reales (mínimo 2-3 modelos distintos)
• Probar con red deficiente (usa Network Link Conditioner)
• Probar con modo avión
• Probar con permisos denegados
• Probar con una instalación limpia (sin datos en caché)

2. Funcionalidad principal ausente o rota

Por qué sucede:

• Funciones que aparecen en las capturas y aún no existen
• La cuenta demo no tiene acceso a las funciones anunciadas
• Se muestran funciones premium pero no están implementadas
• Placeholders de “Próximamente” en la app

Cómo prevenirlo:

• Envía la app solo cuando todas las funciones estén listas
• Asegúrate de que la cuenta demo tenga acceso total
• Elimina o desactiva las funciones incompletas antes del envío
• Actualiza las capturas para que coincidan con el build actual

3. Contenido inapropiado para la clasificación por edad

Por qué sucede:

• Clasificación 4+ pero la app tiene funciones sociales
• La clasificación de edad no coincide con el contenido
• Contenido generado por usuarios sin moderación
• Enlaces a contenido externo sin moderar

Cómo configurar la clasificación de edad correcta:

Clasificaciones de edad en iOS:

• 4+ (sin contenido ofensivo)
• 9+ (contenido leve ocasional)
• 12+ (contenido moderado)
• 17+ (contenido frecuente/intenso)

Clasificación de contenido en Android:

• Todo el mundo
• Todo el mundo 10+
• Adolescentes
• Maduro 17+
• Solo adultos 18+

Importante: Si los usuarios pueden compartir contenido entre sí, necesitas:

• Sistema de moderación de contenido
• Funcionalidad para reportar/bloquear
• Normas de la comunidad claras
• Restricción por edad si es necesario

4. Metadatos engañosos o confusos

Por qué sucede:

• El nombre de la app promete funciones que no existen
• Capturas de la competencia o mockups
• Reseñas falsas o manipulación de valoraciones
• Descripción con superlativos sin pruebas

Ejemplos de metadatos problemáticos:

❌ MAL:

• Nombre de la app: “Best Fitness Tracker - #1 App”
• Descripción: “¡La app más increíble y revolucionaria jamás creada!”
• Capturas de pantalla: fotos de stock genéricas

✅ BIEN:

• Nombre de la app: “FitTrack - Workout Logger”
• Descripción: “Registra tus entrenamientos con rutinas personalizables y gráficos de progreso.”
• Capturas de pantalla: pantallas reales del build actual

5. Pruebas insuficientes (especialmente pruebas cerradas de Android)

Por qué sucede:

• Saltarse el periodo obligatorio de pruebas de 14 días
• No reclutar suficientes testers
• Los testers no usan la app realmente
• Sin monitoreo de crashes durante las pruebas

Cómo prevenirlo:

• Empieza a reclutar testers 3-4 semanas antes del lanzamiento previsto
• Usa Firebase Crashlytics o similar durante las pruebas
• Interactúa activamente con los testers (encuestas, formularios de feedback)
• Arregla los issues críticos antes de pasar a producción

6. Permisos sin justificación

Por qué sucede:

• Solicitar ubicación sin usarla
• Permiso de cámara sin explicación
• Acceso a contactos sin propósito claro
• Ubicación en segundo plano para apps no de navegación

Cómo solucionarlo:

iOS - Info.plist:

<key>NSCameraUsageDescription</key>
<string>Camera access is required to scan QR codes for quick login.</string>

<key>NSLocationWhenInUseUsageDescription</key>
<string>Location helps us show nearby fitness centers and outdoor running routes.</string>

<key>NSPhotoLibraryUsageDescription</key>
<string>Photo library access lets you upload a profile picture and share workout photos.</string>

Android - Estrategia de permisos:

<!-- Only request what you actually need -->
<uses-permission android:name="android.permission.CAMERA" />

<!-- Use when-in-use rather than always for location -->
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

<!-- Avoid if possible -->
<!-- <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /> -->

Solicitud de permisos en runtime:

import { Camera } from '@capacitor/camera';

async function takePicture() {
  // Request with context
  const permissionStatus = await Camera.requestPermissions();

  if (permissionStatus.camera === 'granted') {
    const photo = await Camera.getPhoto({
      quality: 90,
      allowEditing: true,
      resultType: 'uri'
    });

    return photo;
  } else {
    // Explain why permission is needed
    showDialog(
      'Camera access required',
      'To upload a profile picture, please enable camera access in Settings.'
    );
  }
}

Requisitos específicos de iOS

Capturas y vistas previas de la App Store

Tamaños requeridos:

• iPhone 6.7”: 1290 x 2796
• iPad de 13”: 2064 x 2752
• iPad de 12.9”: 2048 x 2732

ImportanteSi tu app es compatible con iPad, debes subir capturas de iPad. No estires las capturas de iPhone para que encajen en los espacios de iPad.

Buenas prácticas para capturas:

• Deben mostrar contenido real de la app (sin mockups)
• Elimina la barra de estado o muestra contenido realista
• Localiza en todos los idiomas compatibles
• Evita el exceso de texto superpuesto
• Muestra las funciones clave en las primeras 2-3 capturas

Configuración de metadatos en App Store Connect

Antes de enviar, completa estos campos en App Store Connect:

• URL de la política de privacidad: obligatorio para apps de iOS
• URL de soporte: obligatorio, y debe llevar a datos de contacto reales
• Age Rating: completa el cuestionario para poder publicar la app
• Información para la revisión de la app: añade un contacto de revisión, credenciales de demo funcionales si se requiere login y notas claras para el equipo de revisión
• Cumplimiento de exportación: responde a las preguntas de cifrado o configúralo ITSAppUsesNonExemptEncryption en Info.plist cuando corresponda para no repetir las mismas respuestas en cada upload

TestFlight antes de la revisión de Apple

Haz una pasada real por TestFlight antes de la revisión de producción:

• Instala la build exacta desde TestFlight
• Inicia sesión con la misma cuenta de revisión que vas a facilitar
• Prueba los flujos de compra, restauración y cancelación
• Confirma que el revisor pueda acceder a funciones clave sin configuración oculta
• Prueba en iPhone e iPad si ambos están soportados

Videos de vista previa (opcionales pero recomendados)

Requisitos:

• Duración: 15-30 segundos
• Debe mostrar imágenes reales de la app
• Puede incluir textos superpuestos breves
• Sin música con problemas de copyright
• Misma resolución que las capturas

Implementación de Sign in with Apple

Ya mencionado arriba, pero crítico para la revisión de iOS si usas social login.

Requisitos de compras in-app

Si ofreces bienes o servicios digitales:

Divulgaciones obligatorias:

• Precios claros antes de la compra
• Términos de suscripción bien definidos
• Instrucciones de cancelación visibles
• Botón de restaurar compras

Ejemplo de pantalla de suscripción conforme:

function SubscriptionOffer() {
  return (
    <div className="subscription-screen">
      <h2>Choose Your Plan</h2>

      <PlanCard>
        <h3>Monthly</h3>
        <p className="price">$9.99/month</p>
        <ul>
          <li>Unlimited workouts</li>
          <li>Personalized plans</li>
          <li>Progress tracking</li>
        </ul>
        <button>Subscribe</button>
      </PlanCard>

      <PlanCard>
        <h3>Annual</h3>
        <p className="price">$79.99/year</p>
        <p className="savings">Save 33%</p>
        <ul>
          <li>Everything in Monthly</li>
          <li>Priority support</li>
        </ul>
        <button>Subscribe</button>
      </PlanCard>

      <div className="subscription-terms">
        <p>
          Subscription automatically renews unless cancelled at least
          24 hours before the end of the current period. Manage your
          subscription in Settings.
        </p>
        <button onClick={restorePurchases}>Restore Purchases</button>
      </div>

      <div className="legal-links">
        <a href="/privacy/">Privacy Policy</a> |
        <a href="/terms">Terms of Service</a>
      </div>
    </div>
  );
}

Requisitos específicos de Android

Configuración de la cuenta en Google Play Console

Antes de tu primer lanzamiento en Android, asegúrate de tener la cuenta de Play Console y el app shell:

• Crea tu cuenta de desarrollador en el registro en Play Console
• En Play Console, ve a Inicio > Crear app
• Elige el idioma, el tipo de app/juego y el email de soporte
• Acepta las políticas de Play, exportación y Play App Signing
• Decide si la app es gratis o de pago

Importante: Google permite cambiar una app de pago a gratuita más adelante, pero una vez que una app se ha ofrecido gratis, no se puede volver a poner de pago.

Requisito de App Bundle

Importante: Google Play requiere el formato Android App Bundle (.aab), no APK:

# Sync the native Android project first
bunx cap sync android

# Then build the release app bundle
cd android
./gradlew bundleRelease

Requisito del nivel objetivo de API

Requisito actual: Las apps nuevas y las actualizaciones deben apuntar a Android 15 (nivel de API 35) o superior.

Actualiza en android/app/build.gradle:

android {
    compileSdkVersion 35

    defaultConfig {
        targetSdkVersion 35
        minSdkVersion 23  // Minimum supported version
    }
}

Seguridad de los datos en Google Play

Ya se mencionó arriba, pero es crítico para la aprobación en Android.

Canal de pruebas cerradas (requisito actual)

Este es el gran obstáculo para las nuevas cuentas de desarrollador personales: el requisito de los 14 días con 12 testers activos mencionado antes.

Cronograma:

1. Semana 1: Reclutar testers y configurar el testing cerrado
2. Semanas 2-3: Periodo de testing activo (mínimo 14 días)
3. Semana 4: Corregir errores y preparar el release a producción
4. Semana 5: Enviar a revisión para producción

Público objetivo y clasificación de contenido

Cuestionario de clasificación de contenido:

• Obligatorio para todas las apps
• Tarda entre 10 y 15 minutos
• Determina la clasificación por edad (Todos, Adolescentes, Adultos, etc.)
• Actualízalo siempre que tu contenido cambie de forma que afecte a las respuestas

Temas cubiertos:

• Violencia
• Contenido sexual
• Lenguaje soez
• Sustancias controladas
• Juegos de azar
• Funciones de interacción de usuarios

Importante: Si tienes contenido generado por usuarios o funciones sociales, debes declararlo e implementar moderación.

Requisitos de la ficha de tienda

Recursos necesarios:

• Icono de la app (512 x 512 PNG)
• Gráfico destacado (1024 x 500 JPG o PNG)
• Capturas de pantalla de móvil (mín. 2, máx. 8)
• Capturas de tablet de 7” (opcional, pero recomendado)
• Capturas de tablet de 10” (opcional, pero recomendado)

Requisitos de la descripción:

• Descripción corta (máx. 80 caracteres)
• Descripción completa (máx. 4000 caracteres)
• Debe describir con precisión la funcionalidad de la app
• No puede incluir datos de contacto ni precios

Checklist previo al envío

Antes de enviar, revisa esta lista de verificación completa:

Requisitos técnicos

• La app inicia correctamente en dispositivos reales
• Todas las funciones de las capturas funcionan
• Sin contenido de relleno o de “Próximamente”
• Todas las keys de API de terceros son de producción
• Manejo de errores de red implementado
• Las solicitudes de permisos incluyen explicaciones claras
• La app no crashea con mala conexión
• Probada con permisos denegados
• Probada en la versión mínima de OS soportada
• Memory leaks revisados y corregidos

Autenticación e inicio de sesión

• Si usas social login, se incluye Sign in with Apple (iOS)
• Credenciales de demo incluidas en las notas de revisión
• La cuenta demo tiene acceso a todas las funciones
• El flujo de recuperación de contraseña funciona
• La funcionalidad de logout funciona correctamente
• Opción de eliminar cuenta disponible (requerido por GDPR/CCPA)

Legal y privacidad

• Política de privacidad accesible públicamente
• URL de la política de privacidad en la tienda
• Términos de servicio públicos (si aplica)
• Política de privacidad en la app (Ajustes)
• Etiquetas de privacidad correctas (iOS)
• Sección de seguridad de datos completa (Android)
• Propósitos de recolección de datos explicados
• Revelar recolección de datos de SDK terceros

Contenido y metadatos

• Nombre de la app según guías (sin keyword stuffing)
• Descripción refleja la funcionalidad real
• Screenshots muestran la app actual
• Capturas de pantalla localizadas para todos los idiomas
• Sin menciones a la competencia en la descripción
• Sin superlativos sin pruebas
• Clasificación de edad acorde al contenido real
• El email de contacto se monitoriza

Específico de iOS

• Sign in with Apple implementado (si usas social login)
• Todos los tamaños de screenshot requeridos incluidos
• Capturas de iPad reales subidas si el soporte para iPad está activado
• Descripciones de permisos de Info.plist claras
• URL de soporte añadida con datos de contacto reales
• URL de Política de Privacidad añadida en App Store Connect
• Cuestionario de clasificación de edad completado
• Cumplimiento de exportación respondido correctamente
• Contacto de App Review y cuenta demo sin caducidad proporcionados
• Target iOS 15.0 o superior
• Si hay IAP: precios claros y botón de restaurar compras presente
• Sin referencias a Android ni a otras plataformas

Específico de Android

• Formato App Bundle (.aab) utilizado
• Target API 35 o superior
• Cuestionario de clasificación de contenido completado
• Gráfico de funciones subido
• Pruebas cerradas completadas si tu cuenta de Play Console lo requiere (12 testers inscritos de forma continua durante 14 días consecutivos, con al menos 12 aún inscritos en el momento de la solicitud)
• Informes de fallos de las pruebas revisados y corregidos
• Sin referencias a iOS ni a otras plataformas

Pruebas (requisito actual de Android)

• 12 o más testers reclutados si tu cuenta de Play requiere pruebas cerradas
• Canal de pruebas cerradas creado
• 12 o más testers permanecieron inscritos de forma continua durante 14 días consecutivos y al menos 12 seguían inscritos cuando presentaste la solicitud
• Los testers realmente usaron la app (no solo la instalaron)
• Monitoreo de crashes activado durante las pruebas
• Bugs críticos detectados en las pruebas corregidos
• Feedback de los testers documentado

Notas de revisión: qué incluir

Unas buenas notas de revisión pueden marcar la diferencia entre la aprobación inmediata y el rechazo. Esto es lo que debes incluir:

Plantilla para notas de revisión

APP REVIEW INFORMATION

=== Test Account ===
Email: reviewer@testapp.com
Password: TestReview123!
(This account has all premium features enabled)
(This account stays active during review)

=== Review Contact ===
Name: Jane Developer
Email: review@yourapp.com
Phone: +1 555-0100

=== Testing Instructions ===
1. Launch app and tap "Sign In"
2. Enter test credentials above
3. Navigate to "Dashboard" to see main features
4. Tap "Upgrade" to test subscription flow (sandbox mode)
5. Go to Settings > Account to see privacy policy and terms

=== Key Features to Test ===
- Workout tracking (tap "New Workout" on Dashboard)
- Progress charts (Analytics tab)
- Social sharing (Share button on workout details)
- Camera upload for profile picture (Settings > Profile)

=== Third-Party Services ===
- Firebase Authentication (for login)
- Stripe (for payments - sandbox mode)
- AWS S3 (for image uploads)
- Google Maps SDK (for location features)

=== Notes ===
- Location permission is optional, app works without it
- Camera permission only requested when uploading profile picture
- All subscription flows use Apple/Google sandbox environments
- Background location is not used
- Support URL and privacy policy are available from Settings > Account

=== Contact ===
For questions: developer@yourapp.com
Response time: Within 24 hours

Notas de revisión específicas para iOS

Para iOS, incluye también:

=== Device Coverage ===
Tested on: iPhone 15 Pro Max, iPad Pro 13-inch

=== App Store Connect Metadata ===
Support URL: https://yourapp.com/support
Privacy Policy: https://yourapp.com/privacy-policy

=== Submission Notes ===
- iPad screenshots match the current iPad UI
- Export compliance answered for this build
- Sign in with Apple is available on the login screen

Notas de revisión específicas para Android

Para Android, incluye también:

=== Testing Track Information ===
Closed testing period: [Start Date] to [End Date]
Number of active testers: 23
Critical issues found during testing: 2 (both fixed)
Test distribution method: Email invite list

=== Crash Data ===
Testing period crashes: 3 total
Crash rate: 0.8%
All crashes fixed in this build

=== API Levels ===
Target SDK: 35 (Android 15)
Min SDK: 23 (Android 6.0)
Tested on: Android 11, 12, 13, 14, 15

Qué hacer si te rechazan

No entres en pánico: los rechazos son comunes, sobre todo en los primeros envíos. Así puedes gestionarlo:

Pasos tras el rechazo

Motivos de rechazo comunes

Rechazo: “La app se cierra al iniciar”

Respuesta:

I sincerely apologize for the crash. I have identified and fixed
the issue:

Root cause: The app attempted to fetch data before network
initialization completed, causing a null reference exception.

Fix: Implemented proper async initialization with error handling
and offline mode. The app now gracefully handles network issues.

Testing: Verified on iPhone 12 (iOS 17), iPhone 14 Pro (iOS 17.1),
tested with WiFi, cellular, and airplane mode.

Build version: 1.0.2 (build 3)

Rechazo: “Falta la política de privacidad”

Respuesta:

Thank you for the feedback. I have added the privacy policy:

URL: https://myapp.com/privacy-policy
Location in app: Settings > Privacy Policy (tappable link)
Also added to: App Store Connect > App Information > Privacy Policy URL

The privacy policy covers all data collection as disclosed in the
Privacy Nutrition Labels.

Rechazo: “No cumple con 4.2 - Funcionalidad mínima”

Esto es más complejo. Significa que tu app no aporta suficiente valor. Lee cómo pasar la revisión de la App Store en 2026 nuestro playbook para respuestas 4.2 y 4.3. Ejemplo de texto para apelación:

Respuesta:

Thank you for the feedback. I'd like to clarify the app's
functionality:

Core Features:
1. [Feature 1 with specific details]
2. [Feature 2 with specific details]
3. [Feature 3 with specific details]

The app provides significant utility beyond a simple website by:
- Offline functionality for [specific feature]
- Native camera integration for [specific feature]
- Push notifications for [specific feature]
- Device hardware access for [specific feature]

Test account credentials have been provided to demonstrate all
features. Please let me know if you need additional clarification.

Buenas prácticas tras la aprobación

¡Felicidades! Tu app ha sido aprobada. Así puedes mantener ese estado:

Monitoreo tras el lanzamiento

Métricas críticas a vigilar:

• Tasa de crashes (mantener < 1%)
• Tasa de ANR (Android - mantener < 0.5%)
• Ratings en App Store/Play Store
• Contenido de reviews (responde a todas)
• Bugs reportados por usuarios

Herramientas recomendadas:

• Firebase Crashlytics
• Analytics de App Store Connect
• Google Play Console Vitals
• Sentry o un tracking de errores similar

Pautas de actualización

Al enviar actualizaciones:

• Prueba tan a fondo como en el envío inicial
• Actualiza las capturas si la UI cambió significativamente
• Actualiza las etiquetas de privacidad si cambió la recolección de datos
• Proporciona descripciones claras de “Novedades”
• Considera rollouts escalonados para cambios importantes

Mantenerse en cumplimiento

Requisitos anuales:

• Renueva el rating de contenido en Android (obligatorio anual)
• Actualiza la política de privacidad si cambian las prácticas
• Revisa y actualiza el rating de edad si cambia el contenido
• Audita el cumplimiento de los SDK de terceros

Monitoreo continuo:

• Stay updated on guideline changes
• Suscríbete a los boletines de Apple y Google
• Participa en comunidades de desarrolladores
• Sigue los blogs de políticas de App Store/Play Store

Recursos y lecturas adicionales

Documentación oficial

Apple:

• Directrices de revisión de la App Store
• Iniciar sesión con Apple
• Ayuda de App Store Connect
• Privacidad y uso de datos

Google:

• Centro de políticas para desarrolladores
• Checklist de lanzamiento
• Sección de seguridad de datos
• Pautas de prueba

Recursos de la comunidad

• r/androiddev - Comunidad de desarrolladores Android
• r/iOSProgramming - Comunidad de desarrolladores iOS
• Stack Overflow - Preguntas técnicas
• Indie Hackers - Comunidad de devs indie

Herramientas de política de privacidad

• Generador de política de privacidad de Termly
• PrivacyPolicies.com
• Política de privacidad gratuita

Preguntas frecuentes

¿Qué son las guías de revisión de apps?
Son las de Apple Directrices de revisión de la App Store y las de Google Políticas del Programa de DesarrolladoresLos revisores comprueban tu binario, metadatos, declaraciones de privacidad y la configuración de la cuenta antes del lanzamiento.

¿Cuánto tarda la revisión de una app en 2026?
Apple busca revisar el 50% de los envíos en 24 horas y el 90% en 48 horas. Google puede tardar hasta siete días o más en algunas cuentas. Las nuevas cuentas personales de Play Console también requieren al menos 12 testers que participen continuamente durante al menos 14 días seguidos de pruebas cerradas, con al menos 12 activos al momento de solicitar la revisión, cuando dicha regla aplique.

¿Cuáles son las cinco secciones de las directrices de Apple?
Seguridad, Rendimiento, Negocios, Diseño y Legal. Rendimiento cubre la integridad y metadatos (incluyendo 2.3). Legal cubre la privacidad (incluyendo 5.1).

¿Qué debo corregir antes de mi primer envío?
Logins de demo funcionales, HTTPS, enlaces de soporte, etiquetas de privacidad honestas, pruebas en dispositivos reales y assets de la tienda que coincidan con el build. Completa el cuestionario de clasificación por edad en ambas tiendas cuando sea necesario para tu app.

¿Dónde encajan las directrices 4.2 y 4.3?
Son rechazos de diseño de Apple por apps mínimas o duplicadas. Usa cómo pasar la revisión de la App Store en 2026 para ese alcance, no para esta checklist.

¿Cuánto cuesta publicar en Apple?
Ver costo de publicar una app en el App Store por las cuotas de inscripción y listado actuales.

¿Necesitas ayuda con la revisión de tu app?

Si te sientes abrumado o quieres asesoramiento experto para que tu app pase la revisión a la primera, ¡estamos aquí para ayudarte!

Reserva una llamada de consultoría con nuestro equipo para recibir asistencia personalizada en:

• preparación para la revisión en App Store y Play Store
• revisión de políticas de privacidad y documentación legal
• Implementación de Sign in with Apple
• Estrategia de testing y reclutamiento de testers
• Preparación de notas de revisión
• Respuesta a rechazos y apelaciones
• Proceso completo de envío de la app

Nuestro equipo ha ayudado a cientos de desarrolladores a superar con éxito el proceso de revisión de apps, ahorrándote semanas de errores y aciertos.

Conclusión

Enviar tu primera app puede ser abrumador, pero con la preparación adecuada, puedes pasar la revisión al primer intento. Ten en cuenta estos puntos clave:

1. Empieza pronto: Especialmente en Android: recluta a esos 12 testers al menos 3 semanas antes de tu lanzamiento
2. Privacidad ante todo: Ten lista tu política de privacidad y asegúrate de que refleje fielmente el manejo de tus datos
3. Iniciar sesión con Apple: Si usas algún social login, debes incluir Sign in with Apple en iOS
4. Testea a fondo: Prueba en dispositivos reales, con redes lentas y con permisos denegados
5. Sé honesto: Los metadatos precisos y la divulgación de privacidad evitan rechazos y problemas legales
6. Notas de revisión detalladas: Ayuda a los revisores a entender tu app rápidamente

Los requisitos actuales de testing en Android añaden tiempo al proceso, pero al final se traducen en mejores apps y menos problemas tras el lanzamiento. Reserva 3-4 semanas adicionales para los envíos a Android y estarás bien posicionado para tener éxito.

¡Mucha suerte con el lanzamiento de tu app! Recuerda que, incluso si te rechazan, es una oportunidad de aprendizaje. La mayoría de las apps exitosas pasan por varias rondas de revisión antes de ser aprobadas.

¿No quieres hacerlo solo? Agenda una consulta y deja que nuestros expertos te guíen durante el proceso.

¿Necesitas ayuda para implementar Live Updates tras la aprobación de tu app? Echa un vistazo a la solución live update de Capgo para actualizaciones fluidas sin pasar por la revisión de la app store.

Continuación de las App Review Guidelines 2026

Si estás usando esta guía de revisión de apps checklist para planificar seguridad y cumplimiento, conéctala con Cifrado para los detalles de implementación en Cifrado, Cumplimiento para los detalles de implementación en Cumplimiento, Escáner de seguridad de Capgo para el flujo de trabajo del producto en Capgo Security Scanner, Seguridad de Capgo para el flujo de trabajo del producto en Capgo Security, y Centro de confianza de Capgo para el flujo de trabajo del producto en Capgo Trust Center.