Cómo probar una app de iOS sin Mac desde Windows o Linux

Probar iOS desde Windows o Linux se resume en un hecho: el iOS Simulator y Safari Web Inspector solo están disponibles en macOS. Todo lo demás se puede resolver. Esta guía propone una secuencia de pruebas que funciona sin Mac, desde el navegador hasta un iPhone real, y muestra dónde Build de Capgo y Live Updates olvídate de la espera.

La escala de testing

La mayoría de los bugs se detectan en los niveles 1 y 2. El nivel 3 detecta los exclusivos de iOS. El nivel 5 es raro en una app Capacitor, y si ocurre, alquilar un Mac una hora es más barato que comprar uno.

Nivel 1: el navegador con viewport de iPhone

Abre tu dev server en Chrome o Edge, activa la emulación de dispositivos y elige un perfil de iPhone. Capacitor expone info de la plataforma para que puedas aplicar lógica de UI:

import { Capacitor } from '@capacitor/core';

if (Capacitor.getPlatform() === 'ios') {
  // iOS-only behavior
}

Lo que esto no detecta: diferencias de renderizado en WebKit, safe area insets, el teclado de iOS desplazando el viewport y cualquier cosa que afecte a un plugin nativo.

Nivel 2: Android primero, ya que la capa web es compartida

Capacitor ejecuta el mismo web bundle en ambas plataformas. El wiring de los plugins, los permission prompts y las llamadas al bridge se pueden validar en Android desde Windows o Linux con Chrome DevTools en chrome://inspect. Si una llamada a un plugin funciona en Android, el lado de JavaScript es correcto; lo que queda es la implementación nativa de iOS, que probarás en el nivel 3.

Guías de configuración: Windows y Linux.

Nivel 3: un iPhone real mediante TestFlight

Esta es la principal vía de testing de iOS sin un Mac. Flujo:

1. Genera y sincroniza el proyecto iOS en local.
2. Solicita un cloud build con las credenciales de App Store Connect guardadas.
3. Abre TestFlight en el iPhone.

bun run build
bunx cap sync ios
bunx @capgo/cli@latest build request com.example.app --platform ios --build-mode release

Capgo compila y firma la app en macOS y luego la sube a App Store Connect. Apple procesa el build y TestFlight lo muestra a los testers internos en minutos. Los testers internos (miembros de tu equipo de App Store Connect) no necesitan Beta App Review, así que la primera instalación es rápida.

La configuración de credenciales se hace una sola vez; bunx @capgo/cli@latest build init --platform ios lo guía, y el certificado se puede crear sin un Mac usando OpenSSL o el generador de certificados iOS.

Lo que obtienes en el dispositivo: WebKit real, safe areas reales, el teclado real, push notifications reales, el comportamiento real de los plugins. Esa es la lista de cosas que el navegador no podía decirte.

Nivel 4: builds ad hoc para dispositivos específicos

Cuando un tester está fuera de tu equipo de App Store Connect, o quieres saltarte el procesamiento de Apple, usa un perfil Ad Hoc que liste el UDID del dispositivo:

bunx @capgo/cli@latest build request com.example.app \
  --platform ios \
  --ios-distribution ad_hoc \
  --output-upload \
  --output-record build.json

CLI devuelve un enlace de descarga temporal y un código QR code para el IPA. La retención se puede configurar de 1 hora a 7 días con --output-retention. Los perfiles ad hoc no necesitan una clave API de App Store Connect, solo el certificado y el perfil.

Para obtener el UDID de un tester desde Windows o Linux, pídeles que vayan a Ajustes > General > Información en el iPhone y lean el campo, o usa un UDID web helper. Añade el dispositivo en el portal de Apple y regenera el perfil.

Itera sin un nuevo build: Live Updates

Una vez instalado el build de TestFlight, no reconstruyas para cada cambio. En su lugar, haz push del web bundle:

bun run build
bunx @capgo/cli@latest bundle upload --channel beta

Los testers en el beta channel recibirán el nuevo bundle en el siguiente inicio. Para un equipo en Windows o Linux, esto reduce el feedback loop de iOS de "esperar un cloud build y el procesamiento de Apple" a "segundos". Los Native rebuilds solo son necesarios cuando cambia un plugin, un permiso o la versión de Capacitor.

Dirige tu build de TestFlight a un canal dedicado para que los beta testers nunca descarguen bundles de producción. El guía de canales explica la configuración.

Depuración de iOS sin Safari Web Inspector

El inspector de Safari solo se puede conectar desde macOS. Alternativas que funcionan en cualquier OS:

• Logging estructurado hacia un sink remoto. Enviar console.error y envía los errores a Sentry o una herramienta similar. El Firebase Crashlytics para la guía de Capacitor cubre la configuración nativa de SDK.
• Panel de debug en la app. Renderiza las últimas N líneas de logs en una vista oculta mediante un gesto. Barato y efectivo en builds de TestFlight.
• Logs de build. Los problemas de compilación nativa aparecen en el log de build de Capgo que se transmite a tu terminal. Añade --ai-analytics para que un build fallido se explique automáticamente.
• Reproducir en Android. Para cualquier cosa en la capa web compartida, Chrome DevTools en Android ofrece el debugger completo.

Para un crash nativo real que requiera el debugger de Xcode, alquila un Mac una hora o pide ayuda a un compañero. Ese caso es raro en una app de Capacitor; la mayoría de los problemas están en la capa web o en la configuración de plugins.

Un workflow semanal realista

• Diario: navegador y un dispositivo Android desde Windows o Linux. Live Updates al beta canal para testers de iPhone.
• Cuando los cambios nativos se aplican,: un Capgo Build a TestFlight. Unos minutos de espera, sin Mac.
• Release: Capgo Build con distribución de App Store, y luego promociona el bundle channel.

Resumen

No puedes simular iOS en Windows o Linux, pero puedes probarlo en un iPhone sin un Mac. Capgo Build envía la app firmada a TestFlight o a un link ad hoc con un solo comando, y Live Updates mantiene la iteración rápida una vez instalada. Deja el Mac para las sesiones de debugging nativo ocasionales.