¿Qué hace new-app-info?
Convierte la solicitud de «necesitamos información adicional» de Apple en un único archivo. El usuario responde con él en App Store Connect y también lo pega en el campo Notas de Información de revisión de la app, para que futuras presentaciones ya lo tengan. La grabación es la única parte que solo ellos pueden hacer.
Los seis elementos que Apple exige
Cada paquete responde a los seis elementos, numerados del 1 al 6 en este orden, incluso si el mensaje del usuario de Apple falta o está redactado de otra forma. Si el mensaje de Apple añade o modifica algún elemento, sigue la versión de Apple y anota qué era diferente.
| # | Apple pide | Respondido por |
|---|---|---|
| 1 | Una grabación de pantalla capturada en un dispositivo físico con el sistema operativo más reciente. Debe comenzar al abrir la app y mostrar el flujo de usuario típico, incluyendo, si la app los tiene: registro de cuenta, inicio de sesión y eliminación de cuenta; contenido generado por el usuario con su denuncia y bloqueo; y acceso a contenido o funciones de pago | Parte 1 (la lista de tomas) + respuesta §1 |
| 2 | El propósito y público objetivo de la app: el problema que resuelve y el valor que aporta | Respuesta §2 |
| 3 | Instrucciones para configurar y acceder a las funciones principales, incluyendo las credenciales de inicio de sesión o archivos de muestra necesarios | Respuesta §3 |
| 4 | Los servicios, herramientas o plataformas externas utilizados para la funcionalidad principal (proveedores de datos, autenticación, procesadores de pago, servicios de IA) | Respuesta §4 |
| 5 | Cualquier diferencia regional en funciones o contenido, o confirmación de que la app funciona igual en todas las regiones | Respuesta §5 |
| 6 | Para una industria altamente regulada o material protegido de terceros: documentación o credenciales que muestren autorización | Respuesta §6 |
Reglas estrictas
- La grabación debe ser de un dispositivo físico, con el sistema operativo más reciente, en una sola toma sin editar a velocidad normal, comenzando al pulsar el icono de la app. Nunca ofrezcas una grabación de simulador o una edición acelerada como envío. No puedes manejar el teléfono del usuario, por lo que la grabación es responsabilidad suya; tu trabajo es la lista de tomas.
- Afirma solo lo que está en la build. Cada función, servicio e idioma debe provenir del código, no de planes o notas.
- No aplicable sigue siendo una respuesta. Dalo en una oración con el motivo (ej.: «La app no tiene registro de cuenta ni inicio de sesión»).
- Cuentas: si los usuarios pueden crear cuentas, la eliminación de cuenta es obligatoria y debe aparecer en la grabación; si falta, repórtalo como un bloqueante. Si hay inicio de sesión, el elemento 3 necesita credenciales de demostración (un conjunto por tipo de cuenta): dile al usuario que las ingrese en App Store Connect. Nunca escribas contraseñas reales en el archivo.
- Nunca envíes, presentes ni edites nada en App Store Connect. El usuario pega la respuesta y adjunta el vídeo.
- Rellena todos los marcadores de posición que puedas del repositorio o del dispositivo. Enumera los que queden y qué los completa.
Paso 1: Leer el mensaje de Apple
Si el usuario ha pegado uno, comprueba sus elementos numerados con la tabla anterior y anota qué condiciones de grabación (cuentas, UGC, contenido de pago) aplican a esta app.
Paso 2: Basarse en el código
Lee el código en el commit enviado, no en la copia de trabajo (fíjalo primero, como en el Paso 6 → La build de revisión, paso 0). La copia de trabajo suele ser una rama de funcionalidades con características no publicadas, y describirlas a Apple es una afirmación sobre una build que no tienen. Usa git grep <patrón> <commit> -- <rutas> y git show <commit>:<ruta>.
Excluye build, Pods, .dart_tool, node_modules y .git en cada búsqueda.
| Elemento | Dónde buscar |
|---|---|
| 1, 3: flujo principal desde el inicio | Router y pantallas; onboarding; el bucle principal |
| 1, 3: cuentas, inicio de sesión, eliminación | firebase_auth, sign_in_with_apple, supabase, Auth, login, signUp, deleteAccount, delete.*data |
| 1: contenido generado por el usuario | Publicaciones, comentarios, chat, subidas; report, block, flag |
| 1, 3: contenido de pago | purchases_flutter, revenuecat, StoreKit, product_id, pantallas de paywall. Encuentra qué funciones están restringidas, si hay pruebas gratuitas, cuándo puede aparecer el paywall y dónde está Restaurar Compras |
| 1: bloqueo de captura de pantalla | trucos no_screenshot, isSecureTextEntry, UIScreen.capturedDidChange, FLAG_SECURE. Una pantalla bloqueada aparece en blanco en la grabación, por lo que la respuesta debe explicar por qué |
| 2: propósito y audiencia | Copia de la ficha de la tienda, documentos de marca o voz, README, lista de verificación de lanzamiento, textos de onboarding (.arb, .strings, strings.xml) |
| 3: archivos de muestra | Importaciones de archivos, selectores de documentos, escáner de QR/código de barras, hardware que la app necesita |
| 4: servicios externos | Dependencias (pubspec.yaml, Podfile, package.json, Gradle) y definiciones de build (--dart-define, archivos de claves, scripts de release). Para cada uno: qué hace y qué datos recibe. Enumera solo los SDK que la build de release realmente activa |
| 5: regiones | Idiomas incluidos; comprobaciones de región (locale, countryCode, region); precios, funciones o contenido específicos por región |
| 6: regulado o protegido | Contenido y afirmaciones sobre salud, medicina, finanzas, juegos de azar, legal o infantil; contenido con licencia, música, imágenes, fuentes y sus licencias |
| Contacto | Correos de soporte en ajustes, documentos de privacidad y archivos del sitio web |
| Plataforma | IPHONEOS_DEPLOYMENT_TARGET, TARGETED_DEVICE_FAMILY (solo iPhone, o también iPad) |
Comprueba que la redacción sobre análisis en el elemento 4 coincide con la política de privacidad en el repositorio. Señálalo si no es así, o si no puedes confirmar las respuestas de Privacidad de la app en App Store Connect.
Paso 3: El dispositivo y el sistema operativo (elemento 1)
xcrun devicectl list devicesmuestra los dispositivos emparejados. Toma el propio iPhone del usuario que esté disponible.xcrun devicectl device info details --device <id> | grep -i osVersionmuestra su versión de iOS.- Busca en la web la última versión de iOS publicada. Si el teléfono está atrasado, dilo: el usuario lo actualiza en Ajustes → General → Actualización de software antes de grabar, luego vuelves a leer la versión. El sistema operativo del teléfono es responsabilidad del usuario actualizarlo.
- Si no hay ningún teléfono emparejado, deja
[versión de iOS]e indica al usuario dónde encontrarlo (Ajustes → General → Información).
Paso 4: Prevenir problemas comunes
Comprueba cada uno de los problemas comunes de Apple y pon el resultado en el informe para el usuario. Estas son comprobaciones para el usuario, no parte de la respuesta.
| Directriz | Comprobación |
|---|---|
| 2.1 Errores y cierres inesperados | La grabación utiliza la build de TestFlight de la versión enviada, en un dispositivo real. Plataformas compatibles según TARGETED_DEVICE_FAMILY: si se admite iPad, dile al usuario que pruebe también en un iPad |
| 2.1 Acceso a la app | Inicio de sesión → las credenciales de demostración se ingresan en App Store Connect, un conjunto por tipo de cuenta, y siguen funcionando |
| 2.3.3 Capturas de pantalla | Enumera las capturas de pantalla de la tienda (ej.: app-store-assets/*screenshots*). Señala si alguna parece solo arte de título, una pantalla de inicio o una pantalla de inicio de sesión |
| 3.1.1 Compra dentro de la app | Cada identificador de producto en el código está configurado en App Store Connect y adjunto a este envío. Enumera los identificadores para que el usuario los verifique |
| 3.2 Otros modelos de negocio | Si la app es para una empresa, organización o sus empleados, señala que necesita una opción de distribución diferente (apps personalizadas o distribución no listada) |
Paso 5: Escribir el archivo
Escribe app-store-assets/new-app-info.md si esa carpeta existe, si no ./new-app-info.md. Mantén esta estructura (un ejemplo completo está en examples/seven-minute-math/new-app-info.md):
# Información de revisión de la app — <Nombre de la app>
Responde en App Store Connect con la Parte 2 y adjunta la grabación. Luego pega la Parte 2 en
Información de revisión de la app → Notas, para que futuras presentaciones ya la tengan.
<Marcadores de posición aún por rellenar, si los hay.>
## Parte 1 — la grabación de pantalla (elemento 1; grábala tú mismo)
Por qué: un dispositivo físico, el sistema operativo más reciente, una sola toma, velocidad normal, comenzando al pulsar el icono.
Configuración (por defecto: una build de release instalada desde el Mac; ver «La build de revisión» más abajo):
crea un probador sandbox (App Store Connect → Usuarios y acceso → Sandbox → Cuentas de prueba);
borra la app del teléfono; construyes e instalas la build de revisión; Grabación de pantalla en
Centro de control con el micrófono apagado; No molestar activado; inicia sesión en la hoja de compra de Apple con
el probador sandbox (la hoja que dice «Sandbox» es esperada).
Lista de tomas, numerada: pulsa el icono → onboarding → el flujo típico de principio a fin → resultados →
cada condición de grabación que aplique (registrarse, iniciar sesión, eliminar la cuenta; publicar, denunciar,
bloquear; paywall, compra sandbox, la función desbloqueada, Restaurar Compras) → cómo los usuarios
eliminan sus datos → parar.
Cualquier pantalla que aparecerá en blanco (bloqueo de captura) y por qué.
## Parte 2 — la respuesta (pégalo)
Saludo, más el dispositivo y la versión de iOS en la que se realizó la grabación.
**1. Grabación de pantalla** … **6. Industria regulada / material de terceros**: una sección en negrita para cada una.
Línea de cierre con el correo de soporte.
Redacción:
- §1: qué muestra la grabación, qué condiciones de grabación no aplican y por qué, y cualquier pantalla en blanco.
- §2: para quién es, el problema, cómo lo resuelve la app, el valor. Tres o cuatro frases.
- §3: qué se necesita para empezar (las credenciales van en App Store Connect, nunca en el archivo), luego las funciones principales en una lista breve, con gratis vs. pago y cuándo aparece el paywall.
- §4: una viñeta por servicio con lo que hace. Luego una línea que diga qué no usa la app (IA, proveedores de datos, autenticación), donde sea cierto.
- §5: idiomas y cualquier diferencia regional, o «funciona igual en todas las regiones».
- §6: documentación, o «No aplica» con el motivo.
- Sencillo, objetivo y cortés. Sin lenguaje de marketing.
Paso 6: El vídeo completo (elemento 1)
La build de revisión
Graba una build de release de exactamente la versión que está en revisión, instalada en el teléfono directamente desde el Mac. Tú la construyes e instalas; el usuario graba.
- Fija la versión enviada. Pregunta al usuario por la versión y el número de build que aparecen en App Store Connect para el envío en revisión (ej.: 1.0.0 (1)), a menos que ya lo haya dado. Encuentra el commit que la produjo: una etiqueta de release, la rama release o main, un mensaje de commit como «enviado a la App Store», o el commit donde
pubspec.yaml/Info.plistestablecen esa versión y build. Si dos commits podrían coincidir, pregunta cuál. Nunca construyas desde la copia de trabajo: a menudo está en una rama de funcionalidades con cambios sin confirmar que Apple no ha visto. Construye en un worktree aislado en su lugar (git worktree add --detach <scratch>/review-build <commit>). Copia cualquier archivo de claves ignorado por git (ej.:keys.json) concp, sin leerlos. Dile al usuario qué commit estás construyendo y qué hay en ramas más nuevas que no estarán en el vídeo. - Encuentra la build de dispositivo normal del proyecto (scripts de ejecución,
tool/*.sh, Makefile, Fastlane). Elimina cualquier indicador que simule compras, comoDUMMY_PURCHASES,MOCK,FAKE,USE_TEST_STORE, una clavetest_de RevenueCat o un archivo de configuración de StoreKit. Una compra simulada nunca muestra la hoja de Apple, y un revisor que vea funciones de pago desbloqueadas sin ella puede considerarlo una forma de evitar la compra dentro de la app (3.1.1). Comprueba que la clave de compra es la clave de la tienda en vivo solo por su prefijo (ej.:grep -q '"REVENUECAT_IOS_KEY": "appl_'); nunca imprimas valores de claves. - Construye en modo release, nunca en debug: las builds de debug de Flutter y React Native no se pueden abrir desde el icono de la pantalla de inicio, y Apple quiere que la grabación comience ahí. Flutter:
flutter build ios --releasecon las definiciones habituales del proyecto menos las simuladas. - Comprueba que la app construida coincide con el envío:
/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" -c "Print CFBundleVersion" build/ios/iphoneos/Runner.app/Info.plistdebe imprimir la versión y build enviadas. Si no es así, detente e informa al usuario. - Pide al usuario que primero borre la app del teléfono (borra sus datos en el teléfono, por lo que es decisión suya), luego instala:
xcrun devicectl device install app --device <id> build/ios/iphoneos/Runner.app. - Las builds instaladas desde el Mac compran a través del sandbox de Apple, por lo que el usuario necesita un probador sandbox para iniciar sesión en la hoja de compra. Una instalación de TestFlight del mismo número de build también funciona (las compras son gratuitas con su propio ID de Apple) y garantiza el binario exacto que tiene Apple. Úsala si el usuario lo prefiere.
Grabación y comprobación
El paquete no está terminado hasta que la grabación existe y se ha comprobado. El usuario la graba; tú lo guías a través del proceso. En el chat, dale la configuración de la Parte 1 (incluyendo el probador sandbox) y la lista numerada de tomas. Pídele que envíe el archivo por AirDrop a app-store-assets/review-recording/ y que te avise cuando esté allí. Luego:
ffprobe -v error -show_entries format=duration:stream=width,height,codec_name -of default=nw=1 <archivo>. Comprueba que la resolución coincida con una pantalla de iPhone real (no una ventana de simulador o una edición recortada) y que la duración cubra todo el flujo.- Crea una hoja de contactos con un fotograma cada 10 segundos:
ffmpeg -i <archivo> -vf "fps=1/10,scale=240:-1,tile=8x8" -frames:v 1 <dir>/contact.png. También guarda el primer fotograma por separado. Lee ambos. - Comprueba, en orden: el primer fotograma muestra la pantalla de inicio o el icono de la app siendo pulsado; cada paso de la lista de tomas aparece en orden y dura el tiempo suficiente; el último fotograma muestra un estado final (app cerrada o pantalla de confirmación). Si la grabación omitió un paso, indica al usuario qué paso volver a grabar.
- Si todo está bien, el paquete está completo. Si no, pide al usuario que regrabe los pasos faltantes.