Despliegue administrado de Xcode

Como administradores de Mac, suele ser complicada la relación con los desarrolladores de su organización que trabajan en macOS para crear apps para las plataformas de Apple. Pueden ser los más entusiastas y conocedores de macOS, pero también son muy exigentes en cuanto a las herramientas y la configuración de sus Mac o, mejor dicho, insisten en que se salga de su camino para configurar todo como es debido.

La herramienta más esencial para los desarrolladores en macOS es Xcode, pero su implementación en un entorno administrado plantea muchos retos a los administradores de Mac.

Nota: Mientras escribo esto, Xcode 14.3.1 es la versión vigente y Xcode 15 está en fase beta. Hubo algunos cambios relevantes para la administración de la implementación de Xcode en Xcode 14 y más en Xcode 15. Dado que Xcode 15 aún está en fase beta, es posible que se produzcan cambios en su comportamiento antes de su lanzamiento en septiembre.

Instalación de Xcode

El primer reto consiste en instalar la app Xcode en las Mac. Xcode es mayormente un reto especial por su gran tamaño. Xcode 14 se expande hasta ~23 GB de tamaño y Xcode 15 hasta ~11.7 GB. (Más adelante veremos por qué Xcode 15 es mucho más pequeño).

App Store de Mac

Apple ofrece Xcode en la Mac App Store. Para los administradores de Mac eso significa que deberíamos poder implementar Xcode mediante la compra por volumen con Apps and Books. Puede entrar en Apple Business Manager o Apple School Manager y "comprar" una serie de licencias gratuitas para Xcode y utilizar la funcionalidad de implementación de apps de su sistema de administración para impulsar esas apps. La implementación de apps de este modo tiene bastantes inconvenientes, y todos ellos se ven agravados por la naturaleza y el tamaño inusuales de Xcode.

Con el protocolo MDM actual (macOS Ventura y anteriores), no hay respuesta del cliente al servidor después de que éste envía la orden de instalar una app. Tampoco hay forma de que el usuario local vea el estado de la instalación. ¡Es probable que el usuario ni siquiera sepa que se está produciendo una importante descarga e instalación en segundo plano! Si la instalación en el lado del cliente falla por alguna razón, ni el usuario ni el servidor MDM serán notificados, y hay muchas razones por las que la descarga y la instalación pueden fallar.

Un usuario podría cerrar o poner en reposo una laptop o mover el dispositivo fuera del alcance de la red durante la descarga o la instalación, lo que provocaría fallos. Esto puede ocurrir con cualquier instalación, pero dado el tamaño de Xcode, es mucho más probable, sobre todo porque no hay forma de informar al usuario del estado.

Una de las ventajas de utilizar la instalación de la App Store es que puede beneficiarse de una Mac que tenga activada en su red el caché de contenidos . Esto debería acelerar la descarga de forma significativa.

Apple ha anunciado cambios en el protocolo MDM en iOS 17 y macOS Sonoma que deberían mejorar drásticamente el flujo de trabajo de la implementación administrada de las apps de la Mac App Store, pero los desarrolladores de MDM tardarán un tiempo en adoptar e implementar las nuevas funciones, y las organizaciones, los usuarios y los desarrolladores en adoptar las nuevas versiones de Xcode y los sistemas operativos. Quizá pase algún tiempo antes de que todos podamos beneficiarnos de estas nuevas funciones.

Instalación de políticas

En general, las instalaciones de la Mac App Store funcionan de forma más confiable cuando son iniciadas por el usuario a través de Self Service. Gran parte de ello consiste en que el usuario esté consciente de que se va a realizar una instalación y que ésta puede llevar algún tiempo. Pero (al menos hasta Ventura) las instalaciones a través de políticas son más confiables que con la compra por volumen a través de Apps y Libros.

Otra característica de la implementación de apps a través de Apps and Books es que siempre recibirá la versión más reciente, que no sea beta. Una vez instalado, Xcode también debería descargar y aplicar automáticamente las actualizaciones, al menos mientras Xcode no esté abierto. Tampoco puede administrar la implementación de versiones anteriores o beta. Dependiendo de su organización, esto puede ser una ventaja o una gran desventaja.

Reempaquetado de Xcode

Si desea instalar Xcode con una política Jamf, debe proporcionar un paquete de instalación o pkg con Xcode en su interior.

Apple ofrece descargas para Xcode en su portal para desarrolladores. La página de descargas enumera (entre otras muchas cosas) versiones antiguas y versiones beta de Xcode. Necesita una cuenta de desarrollador de Apple para acceder a esta página, pero el nivel gratuito es suficiente. (También me gusta la página de versiones de Xcode, que ofrece una útil reseña).

Xcode se descargará como un archivo xip. Puede hacer doble clic en el archivo, en el Finder, para expandirlo. Se tardará mucho en expandirlo porque, bueno, es un archivo grande con más de 100,000 archivos en su interior y también porque se verifican la firma y la integridad del archivo antes de expandirlo.

Una vez que haya desarchivado Xcode, puede volver a empaquetarlo. No necesita ninguna herramienta de empaquetado sofisticada. Solo tiene que utilizar productbuild:

% productbuild --component /path/to/Xcode.app /Applications Xcode-14.3.1.pkg

La primera ruta después de la bandera --component apunta a la ubicación del paquete de aplicación de Xcode, y la segunda es la ruta del archivo donde se instalará en el sistema de destino. El último argumento es el nombre de archivo del pkg que se creará. Recomiendo firmemente añadir la versión en los nombres de los archivos pkg. Xcode no tiene que estar en /Aplicaciones, y no tiene que ser lanzado o configurado para este comando de reempaquetado.

Esto llevará mucho tiempo.

Nota 1: Si le preocupa el tiempo de descarga y el tamaño del archivo, puede ahorrar ~25% añadiendo la opción '--componentcompression auto'. Esta opción tardará más tiempo en comprimirse (y más tiempo en descomprimirse en el cliente de destino), con el beneficio de un archivo de menor tamaño. Más detalles en este post.

Nota 2: Si necesita varias versiones diferentes de Xcode instaladas en el mismo sistema (como la versión beta y la actual), deberá desactivar la bandera "reubicable" en el paquete de instalación. Puede encontrar instrucciones sobre cómo conseguirlo en este post, pero la forma más sencilla es con mi herramienta quickpkg.

Configuración del primer lanzamiento para usuarios no administradores

El trabajo de un administrador de Mac no termina tras la implementación de la(s) app(s) de Xcode. También tenemos que configurar Xcode para que sea utilizable por los usuarios. Cuando lance una nueva versión de Xcode por primera vez en un nuevo sistema, éste le solicitará la instalación de componentes adicionales que requieren privilegios de administrador.

Si los usuarios de su implementación tienen privilegios de administrador, esto no debería representar un gran problema. Ellos mismos pueden autorizar estos pasos. Sin embargo, algunas implementaciones utilizan usuarios estándar que no pueden autorizar estos pasos.

Existe un buen argumento para afirmar que los usuarios estándar son una reliquia del pasado y que ya no son una buena práctica para muchas implementaciones, sobre todo porque con la arquitectura y la seguridad integrada de macOS, los beneficios de seguridad de los usuarios estándar son mínimos. (Consulte el post de Graham Gilbert y la presentación de MacSysAdmin).

Dicho esto, algunas implementaciones, como las de los centros educativos, no tienen esta opción. Es posible que algunos administradores de Mac prefieran una opción diferente, pero tienen que elegir cuidadosamente sus argumentos con la administración y los intereses de seguridad de su organización. Sea cual sea la razón, muchos de nosotros tenemos que tratar con usuarios estándar.

Además, dicho todo esto, automatizar parte de la configuración en segundo plano proporciona una experiencia más agradable en general, por lo que es posible que desee hacerla, incluso cuando los usuarios tengan privilegios de administrador.

Estos pasos que solicita Xcode en el primer lanzamiento requieren privilegios de administrador:

• Seleccione la nueva versión cuando haya varias versiones de Xcode instaladas
• Acepte el acuerdo de Xcode y los SDK de Apple
• Instalación de componentes adicionales
• Habilite la seguridad de las herramientas de desarrolladores para los usuarios que no sean administradores

Existen herramientas de la línea de comandos para realizar todos estos pasos, por lo que podemos automatizarlos con un script. Estos comandos deberán ejecutarse como root, por ejemplo desde una política de script postinstalación desde Jamf Pro.

En primer lugar, nos aseguramos de que las herramientas de la línea de comandos estén utilizando el último Xcode que acabamos de instalar con el comando xcode-select. A continuación, utilizamos xcodebuild para aceptar la licencia e iniciar el flujo de trabajo del "primer lanzamiento". Ambos pasos requieren privilegios de administrador.

En el siguiente paso anidamos el grupo everyone en el grupo _developer. Esto es en preparación para el siguiente comando donde habilitaremos DevToolSecurity. Esto permite a los administradores o miembros del grupo _developer ejecutar determinados depuradores o herramientas de análisis del desempeño sin necesidad de autorizarse con su contraseña.

Al anidar el grupo everyone en el grupo _developer hemos añadido de forma preventiva a todos los usuarios del sistema, incluso a los usuarios que puedan crearse después de que se ejecute este script, al grupo que concede los privilegios. Si prefiere ser más restrictivo, puede cambiar el dseditgroup para que solo añada al usuario conectado actualmente.

Los procesos que permite DevToolsSecurity parecen ser relevantes sobre todo para los flujos de trabajo de depuración y desempeño con herramientas de línea de comandos y scripts. Si es especialmente sensible a la seguridad, puede probar si sus desarrolladores pueden utilizar sus flujos de trabajo sin activar esta opción.

Administración de los SDK de plataforma con Xcode 14 y 15

Hay una cosa más que debe preinstalar. En los últimos años, Apple ha reducido enormemente el tamaño de las descargas de Xcode:

• Xcode 11: 7.5 GB
• Xcode 12: 11 GB
• Xcode 13: 10 GB
• Xcode 14: 7 GB*
• Xcode 15: 3.1 GB**

* no incluye los SDK de watchOS y tvOS
** no incluye los SDK de iOS, watchOS, tvOS y visionOS

La mayor parte de estos ahorros se deben a que la descarga de Xcode ya no incluye todos los SDK de la plataforma. (Xcode 14 viene con macOS e iOS; Xcode 15 solo incluye macOS.) Dado que los SDK de plataforma son necesarios para crear y simular apps en las distintas plataformas, en el primer lanzamiento se pide a los usuarios las plataformas que desean descargar e instalar.

Esto significa que las descargas grandes simplemente se aplazan, no se evitan. En total, Xcode 15 y todas las plataformas (iOS, watchOS y tvOS) suman más de 17 GB, con visionOS casi otros 7 GB por encima de ellos. Así pues, no hay un ahorro real de descargas en las nuevas versiones de Xcode, sino todo lo contrario, pero el tamaño muy reducido de la instalación inicial de Xcode debería hacer más confiables las instalaciones desde la Mac App Store o mediante Apps and Books.

La buena noticia para la implementación administrada es que el usuario de Xcode no necesita tener privilegios de administrador para descargar e instalar SDK adicionales. Pueden elegir qué descargar en el aviso inicial, o ir a la pestaña "Plataformas" de la configuración de Xcode para obtener plataformas adicionales más adelante.

Pero tal vez aún quiera facilitarle un poco la vida al usuario final. Cuando esté implementando Xcode en un entorno de aula, no puede hacer perder el tiempo a todo el mundo con la descarga requerida. O puede que esté implementando Xcode en una Mac para procesos de compilación automatizados sin que intervenga ningún usuario. En ese caso, es preferible automatizar la implementación de los SDK de plataforma necesarios.

Algo que sorprende es que Apple tiene alguna documentación para esto, que de nuevo nos señala el uso del comando xcodebuild.

Hay tres opciones en xcodebuild que son relevantes para esto: -downloadAllPlatforms que, bueno, descargará todas las plataformas disponibles. Esto es conveniente, pero estamos hablando de más de 20 GB para todas las plataformas para Xcode 15. -downloadAllPreviouslySelectedPlatforms debería ser útil depués de una actualización de Xcode.

Por último, tenemos -downloadPlatform que descarga la plataforma designada. En la documentación y en la ayuda del comando faltan los nombres de las distintas plataformas, pero en su mayoría son fáciles de adivinar: iOS, watchOS, tvOS y xrOS (para el SDK de visionOS; esto aún podría cambiar durante la fase beta...).

Si ejecuta de nuevo el comando cuando ya esté instalada una plataforma, se dará cuenta de eso y no la descargará de nuevo, por lo que solo tenemos que añadir las plataformas deseadas al final de nuestro script de configuración:

Xcode 14 viene con el SDK de iOS incluido, pero xcodebuild detecta el SDK existente y no lo descarga de nuevo. En mis pruebas, la descarga utilizó un servidor de caché local, lo que aceleró las cosas significativamente.

Con Xcode 15, vi aparecer una barra de progreso dirigida al usuario al mismo tiempo que verificaba la descarga. Esto podría resultar desconcertante para los usuarios cuando ocurre sin que ellos inicien el proceso, pero no debería ser un problema si forma parte de su flujo de trabajo de implementación inicial.

Conclusión

Puede encontrar un script con todos los pasos que puede utilizar en su política en GitHub.

Xcode es una app importante para muchos de nuestros usuarios. Plantea algunos retos particulares para las implementaciones administradas. Las herramientas y scripts mostrados aquí deberían ayudarle a crear una gran experiencia para usted y sus usuarios.

El enfoque que se muestra aquí me ha funcionado bien, pero probablemente no sea el único, ni el mejor, para determinados entornos.