Xcode6: ejecuta dos instancias del simulador

Tengo dos objectives diferentes para mi aplicación de iOS. ¿Es posible ejecutar simultáneamente las dos aplicaciones en dos instancias diferentes del simulador? Está bien si se requiere no beneficiarse del depurador de Xcode. Hasta ahora, la única solución que encontré fue instalar dos versiones de XCode, pero esa es una solución muy pesada / que consume mucho espacio.

Puede ejecutar dos instancias del simulador de iOS desde la línea de comando. No se adjuntarán a la depuración de Xcode; de ​​hecho, parece funcionar solo si lo haces sin ejecutar Xcode.

Primero, debe ejecutar la aplicación en el simulador desde Xcode, para instalarla en el simulador. Asegúrate de ejecutar los mismos simuladores que finalmente utilizarás

Ahora abra una ventana de Terminal, y haga esto.

cd /Applications/Xcode.app/Contents/Developer/Applications open -n iOS\ Simulator.app open -n iOS\ Simulator.app 

Actualización para Xcode 7: con Xcode 7, el nombre de la aplicación del simulador ha cambiado, por lo tanto, es esto:

 cd /Applications/Xcode.app/Contents/Developer/Applications open -n Simulator.app open -n Simulator.app 

Cuando se lanza el segundo, recibirá una alerta de error. Solo deséchelo y seleccione un dispositivo diferente de “Hardware” »” Dispositivo “. Ahora tiene dos simuladores en ejecución, y las aplicaciones que ya haya instalado en ellos desde Xcode estarán allí.

Xcode 9+

Xcode 9 ahora es compatible con el lanzamiento de múltiples simuladores. Esto fue anunciado en WWDC 2017.

Simplemente ve y cambia el simulador en Xcode, Cmd + R y verás aparecer un nuevo simulador.

enter image description here

Probé exitosamente que la solución de i40west funciona para lanzar el simulador manualmente pero parece tonto que en la actualidad, un simulador de iOS requiera diferentes versiones de Xcode Y diferentes tipos de dispositivos cuando se ejecutan pruebas concurrentes desde línea de comandos (caso de uso ligeramente diferente pero relacionado con la pregunta original en la parte superior) )

Consulte el artículo de Apple aquí que es más relevante para las comstackciones y pruebas de línea de comando: https://developer.apple.com/library/ios/technotes/tn2339/_index.html

Múltiples pruebas concurrentes han funcionado bien para nosotros si se pasa correctamente –args- a ‘iOS simulator.app’ antes de ejecutar el comando ‘xcodebuild test’ con el correcto ‘-destino’ que coincide con el lanzamiento del simultador con el valor de UUID desde la salida de ‘xcrun simctl list ‘, y establecer la variable de entorno DEVELOPER_DIR para seleccionar diferentes binarios de versiones de XCode (es decir, la ruta base a Xcode 6.1 y 6.4)

La razón de necesitar pruebas concurrentes en la misma máquina física y el mismo dispositivo simulador iOS como iPad o iPhone y la misma versión Xcode es principalmente para soportar CI (integración continua) de cualquier proyecto iOS mediante el cual el mismo sistema de comstackción puede ejecutar más de 1 comstackción de múltiples aplicaciones (nuestra empresa tiene 30 aplicaciones más o menos) a la vez al momento del check-in, las sucursales de características son escaneadas y comstackdas automáticamente por el agente de Bamboo sin necesidad de esperar a que se completen otras comstackciones en ejecución. Bamboo admite este tipo de comstackción automática en auto- twigs de características descubiertas si están habilitadas.

En cuanto a lo que ocurre cuando se ejecutan múltiples pruebas concurrentes, ejecutamos múltiples comandos ‘xcodebuild test’ dos veces seguidas en diferentes ventanas de Terminal.app, el resultado es que solo aparece una ventana del simulador y las pruebas fallan en la prueba más simple.

Cuando complicamos los criterios de entrada para nuestro lanzamiento de prueba, diferentes versiones de Xcode para cada simulación y lanzamiento de prueba, cuando usamos DEVELOPER_DIR como páginas man (xcodebuild test) estamos especificando un dispositivo diferente que se abre en dos ventanas separadas, pero el resultado es que las pruebas en ejecución en la primera ventana se interrumpen con la segunda ventana del simulador de iOS.

Parece que hay un recurso común compartido bajo el capó que se interpone en el camino, no está seguro de que sea intencionado o simplemente una nueva característica que requiere más de unos pocos días de reflexión sobre cómo implementar mejor las pruebas concurrentes sin impactos adversos.

No queremos usar máquinas virtuales para evitar las restricciones de sim, ya que nuestra experiencia y la de otros en general es que el rendimiento de comstackción iOS en máquinas virtuales con gran cantidad de archivos pequeños es más lento que el hardware físico. Por lo general, las máquinas virtuales disminuirán mucho la construcción debido a problemas de E / S en la combinación del software VMware y el hardware y / o firmware de Apple. Lo sentimos virtualmente pero las máquinas virtuales no funcionan bien: el sitio virtualmente gatas nos ha proporcionado instrucciones sobre cómo instalar ESXi 5.5 en Mac Mini para nuestra granja de servidores.

Hemos experimentado el problema de rendimiento de comstackción con ESXi 5.5 en Mac Mini siendo más lento que el bare metal incluso con SSD por un factor de 2 o más (es decir, una comstackción baremetal de 10 minutos requiere 20 en VM). Consulte el siguiente artículo cuadrado sobre por qué.

https://corner.squareup.com/2015/07/ios-build-infrastructure.html

La restricción de 1 dispositivo SIM a la vez para las pruebas de la unidad xcodebuild reduce drásticamente la productividad y agrega de manera exponencial costos significativos para Apple y el ecosistema.

El costo para Apple de no apoyar la simultaneidad para justificar más compras de hardware debe pensarse cuidadosamente, ponderando los riesgos de perder la velocidad del desarrollador frente a otros competidores que tienen menos restricciones en términos de SIM y EULA.

La ventaja de las pruebas concurrentes en el mismo inicio de sesión de usuario (cómo funcionan la mayoría de los sistemas ci) es la calidad de las aplicaciones de la tienda de aplicaciones Apple, que a su vez es en parte lo que hace que las personas compren los dispositivos iOS en primer lugar. La mala calidad del software hace que toda la marca sea un poco más tacaña y el soporte de simultaneidad en los simuladores de iOS definitivamente parece ser la forma inteligente de respaldar el ecosistema. Un poco de corolario del problema que nos ocupa son las recientes mejoras, como el servidor Xcode de Apple para CI, la funcionalidad de pruebas de interfaz de usuario automatizada de Xcode en Xcode 7.

Alentar los gastos innecesarios para que las personas compren cantidades masivas de hardware, configuración, configuración, sin mencionar a muchas personas necesarias para admitir todas las máquinas, redes y puntos de energía, etc., potencialmente dañará las ganancias de Apple al final, ya que no todos son como Apple y capaz de pagar racks de MacPro o Mac Mini solo para admitir pruebas concurrentes en simuladores. El objective de un simulador es evitar el uso del hardware y también acelerar las pruebas.

Además, las limitaciones de EULA en las máquinas virtuales hacen que el caso de las máquinas virtuales en Mac Pro sea bastante débil. Este tipo de hardware sería atractivo si se pudieran ejecutar varios sims, pero dado que las pruebas de unidades concurrentes no son compatibles (excepto en las dos condiciones anteriores, diferentes versiones de XCode y diferentes dispositivos simuladores), probablemente seguiremos con Mac Mini para la infraestructura de comstackción.

Estas limitaciones de SIM y EULA de Apple no solo hacen que el proceso de construcción sea más lento, sino que también agrega una complejidad y un costo innecesarios. Puede que no sea tan preocupante para las aplicaciones pequeñas, pero a medida que las aplicaciones crecen en tamaño y complejidad, la comstackción puede tardar más de una hora (escuché que las versiones de Facebook iOS pueden tardar tanto). Nadie quiere esperar una hora para saber si una comstackción pasó.

Sabemos de soluciones de pirateo como ejecutar máquinas virtuales ESXI en Mac Minis que no funcionan bien en cuanto a rendimiento con OS X y xcodebuild en proyectos grandes con comstackciones que tardan más de 10 minutos en un MacBook Pro o Mac Mini moderno, o diferentes cuentas de inicio de sesión en una máquina de metal desnudo para el entorno solo para poder ejecutar pruebas concurrentes en la misma versión de Xcode y el mismo dispositivo simulador.

ESXi no es oficialmente compatible, aunque funciona bastante bien. Una de las razones por las que VMware podría no ser compatible con el hardware Mac Mini es la falta de memoria ECC, aunque Mac Pro es compatible ya que tiene memoria ECC, es probable que tenga los mismos problemas que el Mac Mini en cuanto a iOS. pruebas en las mismas configuraciones de hardware y software (solo el cambio es VM frente a bare metal ejecutando OS X). MacPro no ha sido probado por nosotros en este momento. En nuestra experiencia, VMware Fusion es bastante lento en términos de rendimiento también.

Más importante aún, los desarrolladores necesitarán esperar más tiempo cuando los problemas antes mencionados se combinen a menos que el grupo de máquinas sea lo suficientemente grande como para admitir una línea de cambios (una comstackción de CI por cada 2 desarrolladores, una proporción muy alta de máquinas y desarrollador). Las máquinas de construcción CI deberían poder ejecutar comstackciones más concurrentes y más pruebas concurrentes que 1.

Una de las otras observaciones sobre los simuladores iOS es que parecen ser un trabajo en progreso y completamente inacabado incluso después de 7 versiones principales. El subcomando ‘xcrun simctl’ tiene una opción –set que puede permitir cierta flexibilidad de algún tipo, pero no está seguro de qué valor posible es válido, y lo mismo con –noxpc. Nadie debería tener que adivinar los valores adecuados y, además, debería haber una página de manual que cubra esta opción y, tal vez, ejemplo. ¿Cuáles son algunos casos de uso para estas 2 opciones interesantes?

Puede decir, bueno, ninguna aplicación debe diseñarse para tener una huella grande que garantice que se ejecute una prueba simultánea, y hacer uso de una mejor architecture basada en XPC, ya que las aplicaciones monolíticas son el problema. Esto puede ser correcto, no es una solución tan pragmática como podríamos esperar, y el problema persiste si tienes más de 20 aplicaciones para construir en la misma infraestructura.

Hacer una configuración de máquina y procesos tan generics y escalables como sea posible para un mayor rendimiento requerirá algo de trabajo en el simulador (app + core devs). También requiere un alto nivel de colaboración entre todos los desarrolladores de simuladores de Apple y los propietarios de los productos del simulador deben ordenar correctamente la acumulación de pedidos del producto para este problema para llamar la atención 🙂

FBSimulatorControl de Facebook proporciona una forma programática para hacer esto. Está disponible en https://github.com/facebook/FBSimulatorControl .

El método testLaunchesMultipleSimulatorsConcurrently Lanza testLaunchesMultipleSimulatorsConcurrently en FBSimulatorControlSimulatorLaunchTests.m tiene un código de ejemplo que ilustra cómo ejecutar múltiples simuladores.

Puede ejecutar varias instancias de simulador para diferentes perfiles de hardware y depurarlos. En primer lugar, debe ejecutar su aplicación desde XCode para cada tipo de hardware (iPhone 6, iPad, etc.) para instalarla en las instancias del simulador. Luego ejecute las instancias del simulador y su aplicación tal como se explicó anteriormente. Para depurarlo, puede adjuntar depurador a procesos en ejecución desde el menú “XCode-> Depurar-> Adjuntar al proceso”. Puede consultar esta entrada de blog para ver un ejemplo: http://oguzdemir.dualware.com/?p=43

aquí un pequeño script en .sh para listar UDID de simuladores en su computadora y ejecutarlo. Copie el siguiente código en un archivo con la extensión “.sh” y ejecútelo en la terminal.

Cómo:

Paso 1. Listar dispositivos con la opción 1 y copiar el UDID deseado

Paso 2. Ejecuta la opción 2 y pega el UDID luego presiona la tecla enter

Tenga cuidado: verifique que la ruta que contiene sus simuladores esté bien (si no la reemplaza por su ruta)

 #!/bin/sh PS3='Type the number of your choice (1, 2 or 3) and press Enter: ' options=("List Devices" "Run Simulator" "Quit") select opt in "${options[@]}" do case $opt in "List Devices") xcrun simctl list devices echo "\033[1m\n\nCopy the UDID in parentheses of the device which you want run and launch option 2 (Run Simulator)\033[0m" ;; "Run Simulator") read -p 'Type device UDID which you want launch: ' currentDeviceUDID open -n /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app/ --args -CurrentDeviceUDID $currentDeviceUDID ;; "Quit") break ;; *) echo invalid option;; esac done 

Gracias,