Kiro
Kiro convierte un prompt en una spec: requisitos con criterios de aceptación comprobables, un diseño y una lista de tareas que después ejecuta el agente. La preparación para las tiendas encaja muy bien en ese molde, porque Apple y Google publican reglas concretas que puedes convertir en criterios de aceptación. A continuación: un archivo de steering para el contexto WebView, un archivo de requisitos de preparación de la app nativa listo para pegar y cómo ejecutar la spec sin perder el control.
Desde $109 de pago único por plataforma, o deja que nuestro equipo lo haga todo desde $698.
Kiro, el IDE agéntico guiado por specs de AWS (también disponible como CLI y en la web), trabaja en dos capas. Las specs viven en .kiro/specs/<spec-name>/ y constan de tres archivos: requirements.md con historias de usuario y criterios de aceptación en notación EARS ("WHEN [condición] THE SYSTEM SHALL [comportamiento]"), design.md con la arquitectura, diagramas de secuencia, gestión de errores y estrategia de pruebas, y tasks.md, una lista de tareas de implementación concretas y fáciles de seguir. Las correcciones de errores usan una Bugfix spec con bugfix.md en lugar de los requisitos. Puedes ejecutar las tareas de una en una o todas a la vez; en ese caso Kiro construye un grafo de dependencias y ejecuta las tareas independientes en paralelo, en "oleadas".
Los archivos de steering dan a Kiro un conocimiento duradero sobre el proyecto. Viven en .kiro/steering/ (o globalmente en ~/.kiro/steering/; en caso de conflicto ganan las reglas del workspace). Kiro puede generar por ti product.md, tech.md y structure.md, y también lee AGENTS.md. Cada archivo de steering elige un modo de inclusión en su frontmatter: always, fileMatch, manual o auto (documentación de steering).
Para preparar la app para las tiendas, esta división es perfecta. El steering contiene los hechos permanentes (la app se ejecuta en un WebView, estas reglas se aplican siempre); la spec contiene el proyecto puntual de superar la revisión. Los archivos de la spec son Markdown simple, así que también sirven como encargo para Claude Code o Codex si cambias de agente más adelante; el resumen de agentes de programación con IA compara las opciones.
El frontmatter tiene que ser lo primero del archivo. #[[file:...]] incorpora otro archivo al contexto; quita esa línea si todavía no tienes notas para la revisión. Para reglas que solo importan al editar los proyectos nativos, crea un segundo archivo con inclusion: fileMatch y un fileMatchPattern para ios/** y android/**.
---
inclusion: always
---
# Native app context (WebViewGold)
This web app is published as iOS and Android apps built with WebViewGold.
The apps load https://app.example.com in a WKWebView (iOS) / Android WebView,
so every deploy is live in both apps without a store update.
- Detect the app with isNativeApp(): navigator.userAgent contains "WebViewGoldApp"
(set via useragent_iphone / useragent_ipad in Config.swift, USER_AGENT in Config.java).
- Native features are URL schemes handled by the wrapper. Use only schemes listed in
https://www.webviewgold.com/llms-full.txt and always keep a browser fallback.
- No window.open popups for sign-in or payment inside the app.
- Store rules: Apple 4.2 (more than a website), 4.8 (Sign in with Apple next to other
social logins), 5.1.1 (privacy policy, in-app account deletion), 3.1.1 (digital
goods use in-app purchase on iOS). Google Play: account deletion + Data safety.
- Never edit signing, provisioning, keystores or the purchase code in ios/ or android/.
#[[file:docs/store-review-notes.md]]Crea una Feature spec con el flujo Requirements-First (panel de Kiro, el botón + bajo Specs, o elige Spec en el chat) y sustituye el archivo generado por este, adaptado a tus rutas. Después ejecuta Analyze Requirements para encontrar huecos y contradicciones antes de empezar el diseño.
# Requirements: Native app readiness
## Introduction
Prepare the web app for publication as iOS and Android apps built with WebViewGold,
so that it can pass App Store and Google Play review on the first submission.
## Requirement 1: Mobile layout
**User story:** As a phone user, I want every screen to fit and respond to touch.
1. WHEN any route renders at a viewport width of 320 px THE SYSTEM SHALL show no horizontal scrolling.
2. WHEN a fixed header or tab bar renders THE SYSTEM SHALL pad it with env(safe-area-inset-top) or env(safe-area-inset-bottom).
3. WHEN an interactive element renders THE SYSTEM SHALL give it a touch target of at least 44 x 44 px.
## Requirement 2: Account deletion
**User story:** As a user, I want to delete my account inside the app.
1. WHEN a signed-in user opens Settings THE SYSTEM SHALL show a Delete account action.
2. WHEN the user confirms deletion THE SYSTEM SHALL delete their data and auth record server-side, sign them out and show a confirmation.
3. WHEN anyone opens /delete-account THE SYSTEM SHALL explain how to delete an account in the app and by email.
## Requirement 3: Sign-in
**User story:** As a user, I want to sign in the way I prefer without leaving the app.
1. WHEN the sign-in screen offers Google or another third-party login THE SYSTEM SHALL offer Sign in with Apple as an equivalent option.
2. WHEN sign-in runs inside the native app THE SYSTEM SHALL complete without opening a popup window.
## Requirement 4: Legal pages
**User story:** As a reviewer, I want to find the privacy policy and terms quickly.
1. WHEN /privacy or /terms is requested directly THE SYSTEM SHALL return the page with HTTP 200.
2. WHEN the user opens Settings THE SYSTEM SHALL link to both pages.
## Requirement 5: Resilience
**User story:** As a user on a weak connection, I never want to see a blank screen.
1. WHEN a data request fails THE SYSTEM SHALL show an error message with a retry action.
2. WHEN a list has no items THE SYSTEM SHALL show an empty state.
## Requirement 6: App-only presentation
**User story:** As an app user, I do not want to be told to download the app I am using.
1. WHEN the user agent contains WebViewGoldApp THE SYSTEM SHALL hide download-our-app banners, builder badges and links to store listings.
2. WHEN the user agent does not contain WebViewGoldApp THE SYSTEM SHALL keep the website unchanged.
## Requirement 7: Native value
**User story:** As a returning user, I want to be notified about things that matter to me.
1. WHEN a signed-in user finishes onboarding in the iOS app THE SYSTEM SHALL offer an Enable notifications button that calls registerpush://.
2. WHEN the app exposes a push subscription ID (onesignalplayerid) THE SYSTEM SHALL store it on the user profile.
## Requirement 8: Secrets
**User story:** As the owner, I want no secret key to reach a device.
1. WHEN the production bundle is built THE SYSTEM SHALL contain only publishable keys.
Mi WebView de iOS finalmente está aprobada. ¡Gracias!
Úsalo después de revisar requirements.md. Obliga a Kiro a basar el diseño en tu código real y a mantener las tareas lo bastante pequeñas como para revisarlas.
Lee .kiro/steering/ y AGENTS.md, y después los requisitos de la spec native-app-readiness. Inspecciona el código antes de escribir nada: basa cada decisión de diseño en las rutas, los proveedores de autenticación, la base de datos y el hosting que este proyecto usa de verdad, y enumera todo lo que un requisito da por hecho y que no hayas podido encontrar. Diseño: describe la utilidad isNativeApp() y dónde se usa, dónde se ejecuta en el servidor la lógica de eliminación de cuenta y cómo autentica a quien la llama, cómo llega el ID de suscripción push al perfil del usuario, el componente común de carga/vacío/error y cómo encaja Sign in with Apple en la configuración de autenticación existente. Añade un diagrama de secuencia para la eliminación de cuenta. Nada en el diseño puede llevar una clave secreta al código del cliente. Tareas: una tarea por cambio revisable, cada una con referencia a los números de sus requisitos y terminada con un paso de prueba manual a 375 px de ancho. Haz que la primera tarea sea un inventario de pagos solo de informe (dónde se venden bienes digitales o suscripciones), sin cambios de código. No crees tareas que toquen la firma, el provisioning, los keystores ni el bundle identifier en ios/ o android/. Detente después de design.md y espera mi revisión antes de escribir tasks.md.
Una spec solo es tan buena como los puntos de revisión que mantengas.
Genera los archivos base (product, tech, structure) y luego añade el archivo de steering native-app de arriba. Sin él, Kiro diseña para un navegador de escritorio.
Usa una Feature spec con el flujo Requirements-First, no Quick Spec: Quick Spec escribe requisitos, diseño y tareas de una sola vez, sin puntos de aprobación. Comenta pasajes concretos con Markdown Review y ejecuta Analyze Requirements.
Comprueba tres cosas: la eliminación ocurre en el servidor y borra el usuario de autenticación, no aparece ningún popup en ningún camino de inicio de sesión dentro de la app y ninguna clave secreta pasa al cliente. Todo lo demás es cuestión de gustos.
Una buena tarea se lee así: - [ ] 4. Add server-side account deletion (Requirements 2.2). Ejecútalas individualmente hasta que estén fusionadas las tareas de layout y de autenticación; las oleadas en paralelo que editan los mismos componentes producen conflictos que luego revisas dos veces.
Despliega la app web y ábrela en una compilación de prueba de WebViewGold. Los requisitos 3.2, 6 y 7 solo se pueden verificar ahí.
Define la URL, el token del user agent y los interruptores de push en Config.swift y Config.java. Kiro puede editarlos si el archivo de steering con fileMatch le indica que solo cambie valores; la firma sigue siendo cosa tuya.
| Requisito | Apple | Google Play |
|---|---|---|
| 1. Diseño móvil | 4.0 Diseño | Funcionalidad rota |
| 2. Eliminación de cuenta | 5.1.1(v) | Requisito de eliminación de cuenta |
| 3. Inicio de sesión | 4.8 Servicios de inicio de sesión | No es obligatorio en Android |
| 4. Páginas legales | 5.1.1 Privacidad | Política de datos de usuario, enlace a la política de privacidad |
| 5. Resiliencia | 2.1 Completitud de la app | Funcionalidad rota |
| 6 y 7. Interfaz solo para la app y valor nativo | 4.2 Funcionalidad mínima | Funcionalidad mínima / spam de webview |
En .kiro/specs/, con una carpeta por spec que contiene requirements.md, design.md y tasks.md. Haz commit de ellos: documentan por qué la app se comporta como la vieron los revisores y ayudan al siguiente agente o desarrollador.
Las specs y la ejecución de tareas están disponibles en el IDE, en el CLI y en la web. Analyze Requirements figura para el IDE y el CLI, y las pruebas de corrección basadas en propiedades solo para el IDE, así que haz la revisión de requisitos en uno de esos dos.
Easy Approach to Requirements Syntax. Cada criterio nombra un desencadenante y un comportamiento esperado (WHEN ocurre algo THE SYSTEM SHALL hace algo), lo que lo hace comprobable y fácil de convertir en código y pruebas para un agente.
Sí. Kiro lee AGENTS.md en la raíz del workspace, en subdirectorios y en la carpeta global de steering. Esos archivos siempre se incluyen y no admiten modos de inclusión, así que mantenlos breves y pon las reglas condicionales en archivos de steering.
Mantén la spec centrada en la app web. La parte nativa es un puñado de valores de configuración, no una funcionalidad; basta con un checklist breve y una edición revisada de Config.swift y Config.java.
El mismo resultado, con distinta cantidad de trabajo por tu parte. Las tres incluyen la garantía de aprobación y soporte humano 24/7.
$109 por plataforma, pago único
La licencia de WebViewGold: un proyecto de Xcode o Android Studio listo para usar. Pega tu URL, define nombre e icono, activa funciones, compila y envía. Actualizaciones gratuitas para siempre.
Ver planes en la página principal$349 por licencia, complemento de pago único
Sin Mac, sin Xcode, sin Android Studio: configura en el navegador, compilamos ambas apps en la nube y las entregamos a App Store Connect y a Play Console.
Cómo funciona el Cloud Builder Prueba la demo gratuita$698 por plataforma $798
Envíanos tu URL y tu icono. Nuestro equipo configura, compila y entrega tu app en 72 horas, en marca blanca y con los proyectos fuente. Ambas plataformas por $1,158.
Detalles del Full Service Con tecnología de
Precios de la Oferta de invierno válidos hasta el 31 de diciembre de 2026.
Garantía de aprobación en App Store & Google Play – o te devolvemos el dinero en 14 días
¿Prefieres delegarlo? Full Service: configuramos, compilamos y entregamos en 72 horas, desde $698 por plataforma. ¿Preguntas? Chatea con nosotros 24/7.
Los reembolsos se conceden bajo las condiciones indicadas en nuestras FAQ: un rechazo por motivos ajenos al contenido por parte de Apple y/o Google, reclamado dentro de los 14 días posteriores a la compra.