vphone-cli permite arrancar un iPhone virtual en Macs con Apple Silicon usando Virtualization.framework de Apple, pero se parece más a un laboratorio de investigación iOS que a un reemplazo directo del Simulator de Xcode.
Esa diferencia importa.
El Simulator de Xcode sigue siendo el camino normal para la mayoría del desarrollo de apps. Es rápido, integrado y está pensado para el ciclo cotidiano de compilar, ejecutar y depurar. vphone-cli juega en otro terreno: crea un entorno de iPhone virtualizado con kernel y filesystem de iOS, parches de firmware, variantes con jailbreak, acceso por SSH/VNC y un socket de control en el host para automatización.
Eso lo vuelve interesante para pruebas iOS, investigación de seguridad, reverse engineering y experimentos de UI controlados por agentes.
También lo vuelve una herramienta que conviene tratar con cuidado.
Al 30 de agosto de 2026, el proyecto requiere Apple Silicon, macOS 15+, Xcode con el SDK de iOS, dependencias instaladas por Homebrew y relajación de SIP/AMFI. No son requisitos casuales. Son el tipo de requisitos que te dicen exactamente qué clase de herramienta es esta: potente, práctica y con bordes filosos.
¿Qué es vphone-cli?
vphone-cli es una CLI open source para arrancar un iPhone virtual en Macs con Apple Silicon usando Virtualization.framework de Apple y la infraestructura de research VM de Private Cloud Compute.
El propio README del proyecto lo resume como una forma de arrancar un iPhone virtual mediante Virtualization.framework usando infraestructura de PCC research VM.
En la práctica, vphone-cli automatiza un flujo que de otra forma sería profundamente manual: crear un bundle de VM, preparar firmware de iPhone y cloudOS, parchear la cadena de arranque, restaurar en modo DFU, instalar firmware personalizado y lanzar el dispositivo virtual resultante.
El README expone esa complejidad en dos capas.
El camino rápido es pequeño:
vphone-cli vm create myphone -V jb
vphone-cli vm launch myphone
El camino manual muestra lo que ocurre por debajo: vm new, fw prepare, fw patch, lanzamiento en DFU, restore, stop, instalación de firmware personalizado y primer arranque.
Por eso esto no es simplemente otro wrapper del Simulator. vphone-cli trabaja con bundles de VM, IPSWs, parches de boot chain, variantes de firmware personalizado y restricciones de seguridad del host.
Para desarrolladores, el atractivo es claro: tienes un target iOS scriptable que puedes clonar, exportar, importar, lanzar, inspeccionar y controlar desde el host.
El costo también es claro: estás operando mucho más cerca de los internos de la plataforma.
¿En qué se diferencia vphone-cli del Simulator de iOS?
vphone-cli se diferencia del Simulator de iOS porque virtualiza un entorno de iPhone en lugar de ejecutar builds para Simulator como procesos alojados en macOS.
Esa diferencia es toda la historia.
El Simulator de iOS es excelente para el desarrollo normal de apps, pero no es un iPhone real. No corre como una VM completa de iPhone con la misma frontera de kernel, modelo de filesystem o comportamiento de dispositivo. Muchos equipos nunca necesitan preocuparse por esa diferencia. Otros empiezan a preocuparse cuando aparece un bug en un dispositivo real y se niega a reproducirse localmente.
La discusión en Hacker News alrededor de vphone-cli volvió varias veces a ese punto: el Simulator suele ser suficiente, hasta que deja de serlo. Los comentarios mencionaron categorías donde el comportamiento parecido al de un dispositivo importa más: investigación de seguridad, Network Extensions, funciones cercanas al hardware, comportamiento de sistema, fallos por configuración regional y casos donde una app funciona en Simulator pero falla en un dispositivo.
vphone-cli no convierte mágicamente un Mac en un iPhone físico perfecto. Las apps todavía pueden detectar que no están corriendo en un dispositivo normal. La compatibilidad con servicios de Apple también es una advertencia: una discusión en GitHub del proyecto sigue el comportamiento de App Store, iMessage y servicios relacionados, con participantes apuntando a obstáculos de virtualización y atestación.
Así que el modelo mental correcto no es “un Simulator mejor”.
Es “un target virtual de investigación iOS”.
Eso hace que la herramienta sea mucho más interesante y mucho menos universal.
¿Cómo instalar vphone-cli en Mac?
vphone-cli se instala con Homebrew, pero la instalación publicada también requiere prerrequisitos del host y pasos de relajación de seguridad.
El README lista los requisitos del host: Apple Silicon, macOS 15+ Sequoia, Xcode más el SDK de iOS, y relajación de SIP/AMFI para permitir entitlements privados PV=3 con binario sin firmar.
También lista estas dependencias:
brew install python@3.13 aria2 wget gnu-tar openssl@3 ldid-procursus sshpass keystone cmake libusb ipsw zstd
Luego, el comando de instalación es:
brew install zqxwce/tap/vphone-cli
Esa es la parte simple.
La parte incómoda es SIP/AMFI. El README documenta dos opciones al 30 de agosto de 2026.
La opción más permisiva desactiva SIP y luego desactiva AMFI mediante boot-args:
csrutil disable
csrutil allow-research-guests enable
Después de reiniciar en macOS:
sudo nvram boot-args="amfi_get_out_of_my_way=1 -v"
La alternativa mantiene SIP activo salvo por la relajación de debug y luego permite el binario con vphone-amfidont:
csrutil enable --without debug
csrutil allow-research-guests enable
Después:
vphone-amfidont
Esta es la parte que no conviene pasar por alto.
Relajar SIP y AMFI cambia la postura de seguridad del Mac host. Puede ser aceptable en una máquina dedicada de investigación. Puede ser inaceptable en una laptop principal con credenciales de producción, datos de clientes, claves de firmado o repositorios internos.
vphone-cli es instalable. Eso no lo vuelve casual.
¿Cómo crear y arrancar un iPhone virtual con vphone-cli?
Puedes crear y arrancar un iPhone virtual con vphone-cli vm create y vphone-cli vm launch.
El quick start del README es:
vphone-cli vm create myphone -V jb
vphone-cli vm launch myphone
La bandera -V selecciona una variante de firmware. Las variantes documentadas van desde less, que mantiene más mitigaciones de iOS activas, hasta regular, dev, jb y exp, que agregan niveles crecientes de bypass de seguridad y parches de investigación.
La variante jb incluye jailbreak completo con instalación automática de Sileo y TrollStore en el primer arranque. La variante exp va más lejos con parches de investigación contra detección de VM.
Ese rango es útil porque distintos lectores van a querer resultados muy distintos.
Un desarrollador de apps que intenta reproducir un fallo que solo aparece en dispositivo quizá no quiera el set de parches más invasivo. Un investigador de seguridad puede necesitar justamente las variantes más permisivas. Un experimento de automatización puede priorizar repetibilidad y control por encima de realismo.
vphone-cli también soporta comandos normales de gestión de VMs:
vphone-cli vm list
vphone-cli vm info myphone
vphone-cli vm clone myphone myphone-2
vphone-cli vm export myphone --out myphone.tzst
vphone-cli vm import myphone.tzst --name restored
vphone-cli vm delete iphone16
Esa superficie de gestión es una de las razones por las que el proyecto merece cobertura. No es solo un script de prueba de concepto. Tiene forma de herramienta para desarrolladores: instalar, crear, lanzar, inspeccionar, clonar, exportar, importar y automatizar.
¿Para qué sirve un iPhone virtual en Mac?
Un iPhone virtual en Mac sirve para pruebas cercanas a dispositivo, investigación de seguridad, reverse engineering, flujos con jailbreak, automatización de UI y experimentos repetibles que son incómodos sobre hardware físico.
El flujo más obvio es testing.
Si una app se comporta distinto en un dispositivo real que en el Simulator, un entorno virtualizado le da al equipo otro target entre “funciona en mi Mac” y “busca un iPhone físico”. No reemplaza las pruebas en dispositivos reales, pero puede reducir la cantidad de veces que un equipo necesita hardware solo para comprobar una hipótesis.
El segundo flujo es investigación.
El README incluye variantes de parches de firmware, comportamiento orientado a jailbreak, acceso SSH, acceso VNC y referencias a comparaciones de parches binarios. Eso vuelve relevante la herramienta para personas que trabajan cerca de los internos de iOS, no solo para quienes publican apps en App Store.
El tercer flujo es automatización.
vphone-cli expone un socket de control en el host en <bundle>/vphone.sock para control programático. El README dice que soporta capturas de pantalla, toques, swipes, botones de hardware y operaciones de portapapeles, con cada acción devolviendo una captura inline para pruebas end-to-end impulsadas por IA.
Ahí es donde vphone-mcp se vuelve interesante.
El proyecto separado vphone-mcp envuelve el socket de control de la VM como un servidor MCP. Su README describe herramientas para capturas, botones de hardware, apertura de apps, scroll, swipes, toques por coordenadas, apertura del Notification Center, apertura del Control Center y navegación por la UI de iOS. También dice que cada acción devuelve una captura compacta en escala de grises para que un LLM pueda ver qué ocurrió.
Este es el ángulo yoDEV escondido a plena vista.
Un iPhone virtual es útil. Un iPhone virtual que un agente puede ver, tocar, deslizar e inspeccionar es una superficie de testing distinta.
¿vphone-cli reemplaza a un iPhone físico para pruebas?
vphone-cli no reemplaza a un iPhone físico para pruebas finales, pero puede reducir la brecha entre probar solo en Simulator y depurar solo con hardware.
Esa es la respuesta sobria.
Todavía hay varios límites duros.
Primero, esto es virtualización, no un dispositivo físico. Todo lo que dependa de sensores, radios, hardware seguro, biometría, Apple Pay, comportamiento de carrier, cámara, NFC, atestación respaldada por SEP o servicios productivos de Apple puede no comportarse como en un iPhone real.
Segundo, la propia FAQ del proyecto incluye advertencias regionales. Durante la configuración de iOS, el README dice que no elijas Japón ni la Unión Europea porque hay checks regulatorios adicionales que la VM no puede satisfacer. Ese es exactamente el tipo de detalle que debería hacer que un equipo sea cuidadoso antes de usar la VM como prueba de comportamiento productivo.
Tercero, la configuración depende de internos de plataforma que pueden moverse. Apple puede cambiar iOS, cloudOS, el comportamiento de Virtualization.framework, supuestos de PCC research VM o detalles de enforcement. El proyecto ya documenta entornos probados como una matriz específica de versiones de host, iPhone y cloudOS. Esa matriz es útil, pero también es una etiqueta de advertencia.
Para confianza real de release, todavía necesitas cobertura en dispositivos físicos.
Para reproducir ciertas clases de bugs, explorar comportamiento de sistema, construir flujos de investigación y darles a agentes un target iOS controlable, vphone-cli es mucho más interesante.
¿Qué deberían revisar los equipos antes de usar vphone-cli?
Los equipos deberían revisar la seguridad del host, las limitaciones con servicios de Apple, la compatibilidad de versiones y la procedencia de los pasos privilegiados antes de adoptar vphone-cli.
La seguridad del host es el punto grande. La relajación de SIP/AMFI no es un detalle menor de instalación. Cambia lo que el host permite. Recomendar un Mac dedicado para este trabajo es mucho más sencillo que recomendar una máquina diaria con credenciales sensibles.
El tema de servicios de Apple también importa. La discusión de GitHub sobre App Store, iMessage y compatibilidad relacionada sugiere que esta no es una forma confiable de probar flujos que dependen del stack real de servicios de Apple. Eso puede afectar Apple Pay, iCloud, descargas desde App Store, Messages, Wallet o comportamiento vinculado a cuentas.
La compatibilidad es inevitable. Al 30 de agosto de 2026, el README documenta combinaciones específicas probadas de host, iPhone y cloudOS. Trátalas como hechos fechados, no como promesas permanentes.
Los pasos privilegiados merecen cautela normal de supply chain. La discusión en Hacker News incluye preocupación por binarios usados durante la configuración y operaciones con root. Eso no vuelve malo al proyecto; significa que es el tipo de herramienta que evalúas como infraestructura, no como un paquete pequeño para un proyecto de juguete.
Para investigadores individuales, eso puede estar bien.
Para equipos, el camino razonable es una máquina de laboratorio contenida, documentación fijada, notas de instalación repetibles y una línea clara entre testing experimental y aprobación de release.
¿Por qué importa vphone-cli ahora?
vphone-cli importa porque convierte la virtualización de iOS de una ruta oscura de investigación en un artefacto instalable para desarrolladores con hooks de automatización.
Ese es el cambio.
El repo tiene instalación por Homebrew. Documenta comandos. Tiene gestión de ciclo de vida de VMs. Expone automatización desde el host. Se conecta con MCP mediante vphone-mcp. Llegó a la portada de Hacker News el 29 de agosto de 2026 porque los desarrolladores entendieron de inmediato la forma de la oportunidad: no solo “correr iOS en un Mac”, sino volver más scriptables los entornos de prueba iOS.
Para desarrolladores en Iberoamerica, la pregunta práctica no es si todos deberían instalarlo mañana.
La mayoría de los equipos no deberían hacerlo.
La mejor pregunta es: ¿dónde tiene tu flujo iOS actual una brecha entre Simulator y dispositivo real?
Si esa brecha es trabajo común de UI, el Simulator sigue siendo la herramienta correcta.
Si esa brecha es comportamiento de sistema, investigación repetible, análisis con jailbreak, rarezas de Network Extension, testing de UI con agentes o una clase de bugs que solo aparece fuera del Simulator, vphone-cli merece seguimiento cercano.
Es potente porque no intenta ser amigable.
Y justamente por eso pertenece en el cajón de “usar con cuidado”.