To put a web app on the App Store and Google Play, wrap your built web app in a native project with Capacitor, add a few native features, create Apple and Google developer accounts, sign and build the iOS and Android binaries, test them with real users, prepare the store listings and submit for review. Your existing HTML, CSS and JavaScript keeps running inside a native WebView, so you do not rewrite the app.
Below are the 11 steps in the order that avoids waiting, with commands for Capacitor 8 and the store rules that apply in October 2026.
Lo que necesitas
- Una aplicación web que se construye en archivos estáticos (React, Vue, Angular, Svelte, Next.js exportación estática, Nuxt generate, HTML plano, o una aplicación creada con un constructor de AI como Lovable o Bolt).
- Node.js 22 o posterior (Capacitor se requiere versión 8) y Bun o otro administrador de paquetes.
- Android Studio para construir Android.
- Xcode 26 en macOS para construir iOS, o un servicio de construcción en la nube si no tiene un Mac.
- Dólares 99 USD al año para Apple y 25 USD una vez para Google.
Planificación realista
| Fase | Tiempo típico | Puede ejecutarse en paralelo? |
|---|---|---|
| Registro de cuenta de desarrollador | Horas (individual) a 2 semanas (organización con nuevo D-U-N-S) | Sí, comience desde el día uno |
| Capacitor setup and first device run | 1 día | |
| Mejoras móviles y características nativas | 3 días a 3 semanas | |
| Registro y primeras compilaciones | 1 día | |
| Prueba cerrada de Google Play (nuevas cuentas personales) | 14 días como mínimo, luego revisión de acceso a producción | Sí, con iOS TestFlight |
| Lista de tienda | 1 a 2 días | Sí |
| App Review | Apple suele tardar 1 a 2 días, Google desde horas hasta varios días |
Paso 1: Inscríbete hoy en el programa de desarrolladores
Verificación de cuenta es el paso que no puedes acelerar, así que hazlo antes de empezar a codificar.
- Programa de Desarrolladores de Apple: 99 USD por año. Los individuos necesitan una cuenta de Apple con autenticación de dos factores y su nombre legal. Las organizaciones también necesitan un número D-U-N-S, un sitio web de la empresa y un correo electrónico de trabajo en ese dominio.
- Consola de Google Play: 25 USD una vez. Las organizaciones necesitan un número D-U-N-S. Espera la verificación de identidad.
Si te inscribiste en Google Play como individuo, tu cuenta está sujeta a la regla de pruebas cerradas (Paso 9). Recorrido completo: ¿Cómo crear cuentas de desarrolladores de Apple y Google Play?.
Paso 2: Prepara la aplicación web para un teléfono
Capacitor ejecuta tu app en una WebView. Algunas cosas que funcionan bien en una pestaña del navegador se sienten mal en una aplicación.
- Salida de compilación estática. Capacitor carga archivos desde el paquete de la aplicación. La renderización del lado del servidor no se ejecuta en el teléfono. Utilice el resultado estático de su framework ("
next buildwithoutput: 'export',nuxt generate, Vitebuild. API llama a su backend sobre HTTPS como antes. - Ruta cliente que funciona desde un origen de archivo. Utilice la ruta de historial (Capacitor sirve la aplicación desde)
https://localhosten Android ycapacitor://localhosten iOS, por lo que funciona) y asegúrese de que las URLs profundas se reemplacen porindex.html. - CORS. Agregar los orígenes de Capacitor a los orígenes permitidos de su API:
capacitor://localhost(iOS) yhttps://localhost(Android). - Presione, no sopese. Quitar menús de solo ratón. Asegúrate de que los blancos de clic sean al menos 44 x 44 puntos.
- Áreas seguras. Agregar
viewport-fit=covera la etiqueta meta del viewport y rellenar encabezados y barras inferiores conenv(safe-area-inset-top)yenv(safe-area-inset-bottom). - en redes sin conexión y lentas. Mostrar un estado adecuado en lugar de una pantalla en blanco. Los revisores prueban en Wi-Fi inestable.
- No hay letreros de ‘descargar nuestra aplicación’ y sin enlaces que envíen a los usuarios a su sitio web para realizar tareas básicas.
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
Paso 3: Agregar Capacitor
Desde la carpeta raíz de su proyecto web:
bun add @capacitor/core
bun add -d @capacitor/cli
bunx cap init "My App" com.example.myapp --web-dir dist
bun add @capacitor/ios @capacitor/android
bun run build
bunx cap add ios
bunx cap add android
Usar el verdadero carpeta de salida para --web-dir: dist para Vite, out para Next.js exportación estática, .output/public para Nuxt generate, build para Create React App, dist/<project>/browser para Angular.
El identificador de paquete (com.example.myapp) es permanente una vez que la aplicación está en las tiendas. Utilice un dominio inverso que controle.
Su capacitor.config.ts ahora se ve así:
import type { CapacitorConfig } from '@capacitor/cli';
const config: CapacitorConfig = {
appId: 'com.example.myapp',
appName: 'My App',
webDir: 'dist',
};
export default config;
Capacitor 8 crea el proyecto iOS con Swift Package Manager por defecto, por lo que no necesita CocoaPods. Cada vez que cambies el code
bun run build
bunx cap sync
Corra:
bunx cap run ios
bunx cap run android
Comita los ios/ y android/ carpetas. Son las fuentes code que editarás (permisos, iconos, firmado). Para más información de fondo, consulta How fácil es convertir una aplicación web en una aplicación móvil con Capacitor, and if you built with an AI tool, our Guía de amor a móvil.
Paso 4: Agregar características nativas que justifiquen una aplicación
La guía de Apple 4.2 (Funcionalidad mínima) rechaza aplicaciones que son solo una página web en una caja. No necesita docenas de características nativas, pero el aplicativo debe comportarse como un aplicativo. Añadidos comunes y útiles:
| Característica | Plugin |
|---|---|
| Notificaciones push | @capacitor/push-notifications |
| Inicio de sesión nativo con Google, Apple y Facebook | @capgo/capacitor-social-login |
| Autenticación con Face ID / huella dactilar | @capgo/capacitor-native-biometric |
| Cámara y fotos | @capacitor/camera |
| Compras y suscripciones en la aplicación | @capgo/capacitor-native-purchases |
| Panel de compartición nativa | @capacitor/share |
| Hapticas | @capacitor/haptics |
| Barra de estado y pantalla de bienvenida | @capacitor/status-bar, @capacitor/splash-screen |
| Prompt de calificación de la aplicación | @capgo/capacitor-in-app-review |
| Actualizaciones en vivo | @capgo/capacitor-updater |
Por ejemplo, muestra el panel de compartición nativa en lugar de un botón 'copiar enlace'.
import { Share } from '@capacitor/share';
import { Capacitor } from '@capacitor/core';
export async function shareLink(url: string, title: string) {
if (Capacitor.isNativePlatform()) {
await Share.share({ title, url });
} else {
await navigator.clipboard.writeText(url);
}
}
Si vende contenido digital o suscripciones, planifique los pagos ahora. Apple y Google requieren sus sistemas de compras en la aplicación para bienes digitales en la mayoría de los casos. En la tienda de aplicaciones de EE. UU., las aplicaciones también pueden enlazar a una página de pago web externa después de la sentencia del tribunal en 2025; otras regiones tienen sus propias reglas. Los bienes físicos y servicios (entregas, viajes) pueden utilizar Stripe o cualquier proveedor de pago. Consulte compras en la aplicación con Capacitor.
El catálogo completo de plugins Capgo está en la página de plugins.
Paso 5: Iconos, pantalla de bienvenida y cadenas de permiso
Generate all icon and splash sizes from two source images:
bun add -d @capacitor/assets
# assets/icon.png 1024x1024, assets/splash.png 2732x2732
bunx capacitor-assets generate
On iOS, cada permiso que utilices necesita una descripción de uso en ios/App/App/Info.plist, o la aplicación se cae cuando pregunta y Apple la rechaza:
<key>NSCameraUsageDescription</key>
<string>Take a photo of your receipt to attach it to an expense.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>Choose receipt photos from your library.</string>
Escriba razones específicas. “Esta aplicación necesita la cámara” se rechaza.
En Android, los plugins agregan la mayoría de las permisos al archivo de manifest. Elimine los permisos que no utilice; Google le pide que justifique los sensibles.
También agregue un archivo de manifest de privacidad (PrivacyInfo.xcprivacy) si su code utiliza APIs de razones requeridas. Consulte la guía de privacidad para Capacitor.
Paso 6: Configuración de firmado
iOS. Necesita un certificado de distribución de Apple (con su clave privada, generalmente exportada como .p12) and an App Store Connect provisioning profile for your bundle ID. Xcode can create them automatically, or you can create them yourself, even without a Mac. Read certificados y perfiles de configuración de iOS explicados; el generador de certificado de iOS gestiona el paso de CSR en el navegador.
Android. Crea un archivo de llave de carga y manténlo respaldado. Google Play utiliza Play App Signing, por lo que Google conserva la llave de firma final y tú firmas las cargas con la tuya.
keytool -genkeypair -v -keystore upload-keystore.jks -alias upload \
-keyalg RSA -keysize 2048 -validity 10000
O utiliza el generador de llave de Android.
Paso 7: Construye los binarios de liberación
Localmente
iOS (en un Mac con Xcode 26, necesario para subir aplicaciones a la Tienda de App desde abril de 2026):
bunx cap open ios- Seleccione el Aplicación objetivo, establezca la versión y el número de compilación, seleccione su equipo bajo Firmas y capacidades.
- Elija Cualquier dispositivo iOS (arm64), luego Producto > Archivar.
- En el Organizador, Distribuir aplicación > App Store Connect > Subir.
Android:
bun run build
bunx cap sync android
cd android
./gradlew bundleRelease
El AAB está en android/app/build/outputs/bundle/release/. Configuración signingConfigs en android/app/build.gradle con su keystore, cargando contraseñas desde variables de entorno.
Asegúrese targetSdkVersion is 36. Since August 31, 2026 Google Play requires new apps and updates to target Android 16 (API 36), which is the Capacitor 8 default.
En la nube
Si no tienes un Mac, o deseas builds reproducibles desde CI, Capgo Construcción construye ambas plataformas en máquinas hospedadas y puede subir directamente a TestFlight y Google Play:
bunx @capgo/cli@latest build credentials save --appId com.example.myapp --platform ios
bunx @capgo/cli@latest build credentials save --appId com.example.myapp --platform android
bunx @capgo/cli@latest build request com.example.myapp --platform ios --path .
bunx @capgo/cli@latest build request com.example.myapp --platform android --path .
Las credenciales se utilizan solo para la compilación y no se almacenan en los servidores Capgo. Consulte la Capgo Documentación de construcción.
Paso 8: Distribuir a los probadores
Coloca la compilación en teléfonos reales antes de que nadie en Apple o Google la vea.
- iOSSubir a TestFlight. Los probadores internos (hasta 100 miembros del equipo) lo obtienen después de un procesamiento; los probadores externos (hasta 10,000) después de una breve revisión Beta de la aplicación.
- AndroidCree un lanzamiento de prueba interno en Play Console y comparte el enlace de opt-in.
Prueba el registro y la autenticación, las pagos en entorno de pruebas, las notificaciones push, el comportamiento sin conexión, el teclado cubriendo los campos de entrada y el comportamiento del botón de atrás en Android. Detalles para cada opción: cómo distribuir aplicaciones de iOS y Android a los probadores.
Paso 9: Ejecuta la prueba cerrada de Google Play (nuevas cuentas personales)
Si su cuenta de Play es una cuenta personal creada después del 13 de noviembre de 2023, no puede publicar en producción hasta que haya ejecutado un prueba cerrada con al menos 12 probadores que se han suscrito durante 14 días consecutivosLuego, solicita acceso a producción en la consola de Play Console, que Google suele revisar dentro de una semana.
Comience esto tan pronto como tenga una versión de Android funcional. Utilice un grupo de Google como lista de pruebas para que las personas puedan unirse ellos mismos. Envíe actualizaciones durante los 14 días y recopile retroalimentación, ya que Google pregunta qué aprendió. Las cuentas de organización están exentas.
Paso 10: Prepara las listas de tienda y envía
Necesitas para ambos tiendas: nombre de la aplicación, descripciones, capturas de pantalla en las tamaños aceptados, icono, URL de la política de privacidad, declaraciones de privacidad (Apple App Privacy y Google Data safety), cuestionario de clasificación de edad, contacto de soporte y una cuenta de demostración si la aplicación tiene inicio de sesión. Google también necesita una imagen gráfica de características de 1024 x 500. Especificaciones y límites: Cómo preparar su lista de App Store y Google Play.
Enviar en iOS: En App Store Connect, crea la versión, selecciona la compilación de TestFlight, rellena la información de revisión de la aplicación (cuenta de demostración, notas) y haz clic Agregar para Revisión, luego Enviar.
Enviar en Android: Crea una versión de producción con el AAB (o promueve la probada desde un track de prueba), completa todos los App content y establece los países, y envía para revisión.
Los rechazos que golpean a las aplicaciones web más a menudo:
- 4.2 Funcionalidad mínimaLa aplicación es solo tu sitio web. Agrega valor nativo y elimina la interfaz de usuario de navegador.
- Login required but no demo account, o la cuenta no funciona.
- Opción de inicio de sesión enfocada en la privacidad cuando ofreces inicio de sesión con Google o Facebook en iOS. La directiva 4.8 requiere una opción equivalente que limita la recopilación de datos; Sign in with Apple es la elección habitual.
- No eliminación de cuenta dentro de la aplicación cuando los usuarios pueden crear cuentas.
- Compras digitales a través de Stripe donde se requiere compra en la aplicación.
- Diseño de pantalla roto de iPad porque el proyecto admite iPad por defecto.
- Faltan o son vagas las cadenas de permiso.
Nuestro Guía de revisión de aplicaciones para usuarios nuevos y guía de envío de aplicaciones iOS pasa por cada una en detalle.
Paso 11: Envía actualizaciones sin esperar a la revisión
Después de la lanzamiento, la mayoría de tus cambios todavía estarán en la web code. En lugar de una nueva construcción de tienda para cada corrección, agrega actualizaciones en vivo. El Capgo actualizador descarga nuevos conjuntos de paquetes web desde Capgo y los aplica en el próximo lanzamiento, con rollback automático si el nuevo conjunto de paquetes falla al iniciar.
bun add @capgo/capacitor-updater
bunx cap sync
bunx @capgo/cli@latest init
Llama notifyAppReady() Cuando tu aplicación ha iniciado para que el actualizador sepa que el paquete es saludable.
import { CapacitorUpdater } from '@capgo/capacitor-updater';
CapacitorUpdater.notifyAppReady();
Entonces cada liberación de la web code es un comando:
bun run build
bunx @capgo/cli@latest bundle upload --channel production
Ambas tiendas permiten esto para la code interpretada siempre que la actualización no cambie el propósito principal de la aplicación o evite sus reglas de pago. Los cambios nativos (nuevos plugins, nuevos permisos, Capacitor actualizaciones) todavía pasan por las tiendas. Lee más sobre Capgo actualizaciones en vivo y los documentos del actualizador.
Antes de tu primera presentación de tienda, agrega el plugin. Debe estar en el binario que los usuarios instalan, de lo contrario, tu primera live update solo puede llegar a los usuarios después de una segunda publicación de tienda.
Finalmente, automatiza: construye y sube en cada etiqueta desde GitHub Actions o GitLab CI, envía actualizaciones en vivo en cada fusión a mainy mantén las versiones nativas para cambios nativos.
Lista de comprobación previa al lanzamiento
- Las cuentas de Apple y Google aprobadas, acuerdos aceptados
- App works offline or shows a clear offline state
- Áreas seguras, teclado y botón de retroceso de Android manejados
- Al menos algunas características nativas que un sitio web no puede ofrecer
- Iconos, pantalla de inicio, cadenas de permisos, manifiesto de privacidad
- Derecho de distribución, perfil de App Store, subir keystore respaldado
- Objetivo SDK 36 en Android, construido con Xcode 26 en iOS
- Pruebas de TestFlight y Play realizadas en dispositivos reales
- Prueba cerrada de Google Play finalizada (cuentas personales)
- Listados completos en ambas tiendas, cuenta de demostración agregada
- In-app account deletion if users can sign up
- Plugin de actualizaciones en vivo incluido en la primera versión binaria
Solución de problemas
Ventana blanca al iniciar. webDir Señala a la carpeta incorrecta o te olvidaste bunx cap sync después de construir. Verifica ios/App/App/public y android/app/src/main/assets/public Incluir index.html.
Los API no funcionan solo en la aplicación. CORS: permitir capacitor://localhost y https://localhosttambién comprueba que no estás llamando http:// URLs, que iOS bloquea por defecto.
Rutas 404 después de refrescar o enlace profundo. Utiliza un router que se desplome a index.htmlo ruteo de hash para configuraciones más antiguas.
Errores de firma de Xcode. Ver la lista de errores en iOS certificados y perfiles de configuración explicados.
Gradle build fails después de actualizar. Capacitor 8 requiere Android Studio Otter (2025.2.1) o posterior y JDK 21, como se indica en la Capacitor 8 guía de actualización. Para otros errores de Gradle, consulte cómo resolver errores de compilación de Android en Capacitor.
Google Play rechazó la carga para el objetivo SDK. Configurar targetSdkVersion = 36 in android/variables.gradle.