Xcode 9 +

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

Simplemente vaya y cambie el simulador en Xcode, Cmd + R y verá un nuevo simulador apareciendo.

Probado con éxito que la solución de i40west funciona para lanzar manualmente el simulador, pero parece tonto que en este día y edad, un simulador de iOS requiere diferentes versiones de Xcode Y diferentes tipos de dispositivos cuando se ejecutan pruebas simultáneas desde la 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 compilaciones de línea de comandos y prueba: https://developer.apple.com/library/ios/technotes/tn2339/_index.html

Múltiples pruebas simultáneas han funcionado bien para nosotros si pasamos correct arg args to a 'iOS simulator.app 'antes de ejecutar el comando' xcodebuild test 'con el valor correcto' - destination 'coincidiendo el lanzamiento simultáneo con el valor de UUID de la salida de 'xcrun simctl list', y configurando la variable de entorno DEVELOPER_DIR para seleccionar diferentes binarios de versión de XCode (es decir, ruta base a Xcode 6.1 y 6.4)

La razón por la que se necesitan pruebas unitarias simultáneas en la misma máquina física y el mismo dispositivo simulador iOS como iPad o iPhone y la misma versión de Xcode es principalmente para admitir CI (integración continua) de cualquier proyecto iOS en el que el mismo sistema de compilación puede ejecutar más de 1 compilación de múltiples aplicaciones (nuestra compañía tiene 30 aplicaciones o más) a la vez al registrarse en las ramas de funciones son escaneadas y construidas automáticamente por Bamboo agent sin necesidad de esperar a que se completen otras compilaciones en ejecución -- Bamboo admite este tipo de compilación automática en ramas de características descubiertas automáticamente si está habilitada.

En cuanto a lo que sucede cuando se ejecutan múltiples pruebas concurrentes, ejecutamos múltiples comandos 'xcodebuild test' dos veces seguidas en diferentes Terminales.app windows, 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 sim y lanzamiento de prueba, al usar DEVELOPER_DIR como por páginas de manual (prueba xcodebuild) estamos especificando un dispositivo diferente que se abre en dos ventanas separadas, pero el resultado es que cualquier prueba en ejecución en la primera ventana se interrumpe por la segunda ventana del simulador de iOS.

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

Nosotros no quiero usar máquinas virtuales para evitar las restricciones de la sim, ya que nuestra experiencia y la de otros en general es que el rendimiento de creación de iOS en máquinas virtuales con una gran cantidad de archivos pequeños es más lento que el hardware físico. Las máquinas virtuales generalmente ralentizarán mucho la compilación debido a problemas de E/S en la combinación de software VMware y hardware y/o firmware de Apple. Lo sentimos virtuallyghetto, pero para nosotros las máquinas virtuales no funcionan bien the el sitio virtuallyghetto nos ha proporcionado instrucciones sobre cómo instalar ESXi 5.5 en Mac Mini para nuestra granja de construcción.

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

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

La restricción de 1 dispositivo sim a la vez para pruebas unitarias xcodebuild reduce severamente la productividad y agrega exponencialmente costos para Apple y el ecosistema.

El costo para Apple de no apoyar la concurrencia para justificar más compras de hardware debe ser pensado cuidadosamente, sopesando los riesgos de perder la velocidad del desarrollador contra otros competidores que tienen menos restricciones en términos de sims y EULA.

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

Fomentar gastos generales innecesarios para hacer que la gente compre cantidades masivas de hardware, configuración, configuración, por no hablar de numerosas personas requeridas para apoyar todas las máquinas, la red y los puntos de alimentación, etc, potencialmente dañarán las ganancias de Apple al final, ya que no todos son como Apple y pueden permitirse bastidores de MacPro o Mac Mini solo para soportar pruebas simultáneas en simuladores. El objetivo de un simulador es evitar el uso del hardware y también acelerar las pruebas.

Además de las limitaciones del CLUF en las máquinas virtuales, el caso de las máquinas virtuales en Mac Pro es bastante débil. Este tipo de hardware sería atractivo si varios sims podrían funcionar, pero desde las pruebas unitarias simultáneas no son compatibles (excepto en las dos condiciones anteriores: versión de XCode diferente y dispositivo de simulador diferente) es probable que nos quedemos con Mac Mini para construir infraestructura.

Estas limitaciones de sim y EULA de Apple no solo hacen que la canalización de compilación sea más lenta, sino que también agregan complejidad y 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 compilación puede tomar más de una hora (escuché que las compilaciones de Facebook iOS pueden tomar así de largo). Nadie quiere esperar una hora para saber si una construcción pasó.

Conocemos soluciones de hackeo como ejecutar máquinas virtuales ESXI en Mac Minis que no funcionan bien en cuanto al rendimiento con OS X y xcodebuild en proyectos grandes con compilaciones que toman más de 10 minutos en un Mac Book 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 simultáneas en la misma versión de Xcode y el mismo dispositivo simulador.

ESXi no es oficialmente soportado aunque funciona bastante bien. Una de las razones por las que VMware podría no ser compatible con el hardware de Mac Mini todavía 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 términos de versiones de iOS se ralentizan en comparación con las pruebas de metal desnudo en la misma configuración de hardware y software (solo el cambio es VM versus 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.

Lo que es más importante, los desarrolladores tendrán que esperar más cuando los problemas antes mencionados se combinen a menos que el grupo de máquinas sea lo suficientemente grande como para soportar pipleline de cambios (una compilación de CI por cada 2 desarrolladores, una proporción muy alta de máquinas por desarrollador). Las máquinas de compilación de CI deberían poder ejecutar más compilaciones 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 apropiados y además, debería haber una página de manual que cubra esta opción y tal vez un ejemplo. ¿Cuáles son algunos casos de uso para estas 2 opciones interesantes?

Puede decir, bueno, ninguna aplicación debe estar diseñada para tener una gran huella eso garantiza que se ejecuten pruebas simultáneas y que se haga uso de una mejor arquitectura basada en XPC, ya que las aplicaciones monolíticas son el problema. Esto puede muy bien ser correcto, no es una solución tan pragmática como podríamos esperar, y el problema sigue siendo si tiene más de 20 aplicaciones para construir en la misma infraestructura.

Hacer que la configuración de la máquina y los procesos sean tan genéricos 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 la colaboración entre todos los desarrolladores de Apple simulator y el propietario del producto del simulador necesita ordenar el backlog del producto correctamente para este problema para llamar la atención: -)

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

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

Puede ejecutar varias instancias de simulator para diferentes perfiles de hardware y depurarlas. Primero, debe ejecutar su aplicación desde XCode para cada tipo de hardware (iPhone 6, iPad, etc.) para instalarlo en instancias del simulador. A continuación, ejecute las instancias del simulador y su aplicación como se explica anteriormente. Para depurarlo, puede adjuntar el depurador a los procesos en ejecución desde el menú "XCode - > Debug - >Attach to Process". Puedes revisar esta entrada del 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 extensión". sh " y ejecútelo en terminal.

Cómo:

Paso 1. Enumere los dispositivos con la opción 1 y copie el UDID wanted

Paso 2. Ejecute la opción 2 y pegue el UDID y luego presione 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,