Beheerde Xcode-implementatie

Als Mac-beheerder is de relatie met de ontwikkelaars in je organisatie die op macOS werken om apps te bouwen voor Apple platforms vaak een uitdaging. Ze kunnen het meest enthousiast en deskundig zijn over macOS, maar ze zijn ook erg veeleisend wat betreft de tooling en configuratie van hun Macs, of liever gezegd, ze staan erop dat je je uit de voeten maakt om alles precies op de juiste manier in te stellen.

De meest essentiële tool voor ontwikkelaars op macOS is Xcode, maar het implementeren van Xcode in een beheerde omgeving brengt veel uitdagingen met zich mee voor Mac-beheerders.

Opmerking: Op het moment dat ik dit schrijf, is Xcode 14.3.1 de huidige releaseversie en is Xcode 15 in bèta. Er waren enkele wijzigingen met betrekking tot beheerde implementatie van Xcode in Xcode 14 en meer in Xcode 15. Omdat Xcode 15 nog in bèta is, kunnen er gedragsveranderingen zijn voor de release in september.

Xcode installeren

De eerste uitdaging is om het programma Xcode geïnstalleerd te krijgen op de Macs. Xcode is vooral een speciale uitdaging vanwege de enorme omvang. Xcode 14 wordt ~23 GB groot en Xcode 15 ~11,7 GB. (We zullen later bekijken waarom Xcode 15 veel kleiner is)

Mac App Store

Apple biedt Xcode aan in de Mac App Store. Voor Mac-beheerders betekent dit dat we Xcode zouden moeten kunnen implementeren via volume-inkoop met Apps en Boeken. Je kunt naar Apple Business Manager of Apple School Manager gaan en een aantal gratis licenties voor Xcode 'kopen' en de app-implementatiefunctionaliteit van je beheersysteem gebruiken om die apps te pushen. Er zijn nogal wat nadelen aan het implementeren van apps op deze manier, en ze worden allemaal verergerd door de ongebruikelijke aard en grootte van Xcode.

Met het huidige MDM-protocol (macOS Ventura en eerder) is er geen terugkoppeling van de client naar de server nadat de server de opdracht heeft verzonden om een app te installeren. De lokale gebruiker kan ook niet zien wat de status van de installatie is. De gebruiker zal waarschijnlijk niet eens weten dat er op de achtergrond een belangrijke download en installatie plaatsvindt! Als de installatie aan de kant van de client om de een of andere reden mislukt, wordt noch de gebruiker noch de MDM-server hiervan op de hoogte gesteld en er zijn vele redenen waarom het downloaden en installeren kan mislukken.

Een gebruiker kan een laptop sluiten of in de slaapstand zetten of het apparaat buiten het netwerkbereik brengen tijdens het downloaden of installeren, wat kan leiden tot fouten. Dit kan gebeuren met elke installatie, maar gezien de grootte van Xcode is het veel waarschijnlijker, vooral omdat er geen manier is om de gebruiker te informeren over de status.

Een voordeel van het gebruik van App Store-installatie is dat je kunt profiteren van een Mac met Content Caching ingeschakeld in je netwerk. Dit zou het downloaden aanzienlijk moeten versnellen.

Apple heeft wijzigingen aangekondigd in het MDM-protocol in iOS 17 en macOS Sonoma die de workflow van beheerde implementatie van Mac App Store-apps drastisch zouden moeten verbeteren, maar het zal even duren voordat MDM-ontwikkelaars de nieuwe functies hebben aangenomen en geïmplementeerd en voordat organisaties, gebruikers en ontwikkelaars de nieuwe versies van Xcode en de besturingssystemen hebben aangenomen. Het kan nog wel even duren voordat we allemaal van deze nieuwe functies kunnen profiteren.

Beleidsinstallatie

Over het algemeen werken Mac App Store-installaties betrouwbaarder wanneer ze door de gebruiker worden gestart via Self Service. Een groot deel hiervan is dat de gebruiker zich ervan bewust is dat er een installatie zal plaatsvinden en dat deze enige tijd in beslag kan nemen. Maar (in ieder geval tot Ventura) zijn installaties via beleid betrouwbaarder dan bij volumeaankopen via Apps en Boeken.

Een ander kenmerk van app-implementaties via Apps and Books is dat je altijd de laatste, niet-beta versie ontvangt. Eenmaal geïnstalleerd zou Xcode ook automatisch updates moeten downloaden en toepassen, tenminste zolang Xcode niet geopend is. Je kunt de implementatie van oudere of bètaversies ook niet beheren. Afhankelijk van je organisatie kan dit een voordeel of een groot nadeel zijn.

Xcode herverpakken

Als je Xcode wilt installeren met een Jamf beleid, moet je een installatiepakket of pkg leveren met Xcode erin.

Apple biedt downloads voor Xcode aan op hun ontwikkelaarsportaal. Op de downloadpagina staan (naast veel andere dingen) oudere versies en bètaversies van Xcode. Je hebt een Apple Developer account nodig om toegang te krijgen tot deze pagina, maar het gratis niveau is voldoende. (Ik vind ook de pagina Xcode Releases een goed overzicht)

Xcode wordt gedownload als een xip-archief. Je kunt dubbelklikken op het archief in Finder om het uit te vouwen. Uitbreiden duurt lang, omdat het een groot archief is met meer dan 100.000 bestanden erin en ook omdat de handtekening en integriteit van het archief worden gecontroleerd voordat het wordt uitgebreid.

Zodra je Xcode hebt uitgepakt, kun je het opnieuw verpakken. Je hebt geen fancy verpakkingstool nodig. Je kunt gewoon productbuild gebruiken:

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

Het eerste pad na de --component vlag wijst naar de locatie van de Xcode applicatiebundel, en het tweede is het bestandspad waar het zal worden geïnstalleerd op het doelsysteem. Het laatste argument is de bestandsnaam van de pkg die wordt aangemaakt. Ik raad sterk aan om de versie toe te voegen aan de namen van pkg-bestanden. Xcode hoeft niet in /Applications te staan en het hoeft niet gestart of geconfigureerd te zijn voor dit herverpakkingscommando.

Dit zal lang duren.

Opmerking 1: Als je geeft om downloadtijd en bestandsgrootte kun je ~25% besparen door de optie '--componentcompression auto' toe te voegen. Deze optie kost meer tijd om te comprimeren (en meer tijd om te de-comprimeren op de doelclient), met als voordeel een kleinere bestandsgrootte. Meer details in dit bericht.

Opmerking 2: Als je meerdere verschillende versies van Xcode wilt installeren op hetzelfde systeem (zoals de bèta en de huidige versie), moet je de vlag 'relocatable' uitschakelen in het installatiepakket. Je kunt instructies vinden over hoe je dat kunt bereiken in deze post, maar de eenvoudigste manier is met mijn quickpkg tool.

Eerste startconfiguratie voor niet-beheerders

Het werk van een Mac-beheerder is niet gedaan na de implementatie van Xcode-app(s). We moeten Xcode ook configureren zodat de gebruikers het kunnen gebruiken. Wanneer je een nieuwe versie van Xcode voor het eerst start op een nieuw systeem, wordt er gevraagd om de installatie van extra onderdelen waarvoor beheerdersrechten nodig zijn.

Als de gebruikers in je implementatie beheerdersrechten hebben, zou dit geen grote uitdaging moeten zijn. Ze kunnen deze stappen zelf autoriseren. Sommige implementaties gebruiken echter standaard gebruikers die deze stappen niet kunnen autoriseren.

Er is een goed argument dat standaardgebruikers een overblijfsel uit het verleden zijn en niet langer een goede praktijk voor veel implementaties, vooral omdat met de architectuur en ingebouwde beveiliging van macOS, de beveiligingsvoordelen van standaardgebruikers minimaal zijn. (Zie Graham Gilbert's post en MacSysAdmin presentatie.)

Dat gezegd hebbende, sommige implementaties, zoals scholen en andere onderwijsinstellingen, hebben deze keuze niet. Sommige Mac-beheerders geven misschien de voorkeur aan een andere keuze, maar moeten hun argumenten met beheer- en beveiligingsbelangen in hun organisatie zorgvuldig kiezen. Wat de reden ook is, velen van ons hebben te maken met standaardgebruikers.

Met dat alles gezegd hebbende, het automatiseren van een deel van de configuratie op de achtergrond levert een mooiere ervaring op, dus je zou het kunnen doen, zelfs als de gebruikers beheerdersrechten hebben.

Deze stappen waar Xcode om vraagt bij de eerste keer opstarten vereisen beheerdersrechten:

• Selecteer de nieuwe versie als er meerdere versies van Xcode zijn geïnstalleerd
• Akkoord gaan met Xcode en Apple SDK's
• Extra onderdelen installeren
• Beveiliging van ontwikkelaarstools inschakelen voor niet-beheerders

Er zijn commandoregeltools om al deze stappen uit te voeren, dus we kunnen ze automatiseren met een script. Deze commando's moeten als root worden uitgevoerd, bijvoorbeeld vanuit een post-installatiescriptbeleid van Jamf Pro.

Eerst zorgen we ervoor dat de commandoregeltools de nieuwste Xcode gebruiken die we zojuist hebben geïnstalleerd met de opdracht xcode-select. Dan gebruiken we xcodebuild om de licentie te accepteren en de 'eerste lancering' workflow te starten. Beide stappen vereisen beheerdersrechten.

In de volgende stap nestelen we de 'everyone group' in de groep _developer. Dit is ter voorbereiding op het volgende commando waarbij we DevToolSecurity inschakelen. Hierdoor kunnen beheerderes of leden van de groep _developer bepaalde debuggers of tools voor prestatieanalyse uitvoeren zonder dat ze hun wachtwoord hoeven in te voeren.

Door de 'everyone group' in de groep _developer te nesten, hebben we preventief elke gebruiker op het systeem toegevoegd, zelfs gebruikers die kunnen worden aangemaakt nadat dit script is uitgevoerd, aan de groep die de bevoegdheden toekent. Als je restrictiever wilt zijn, kun je de dseditgroup zo aanpassen dat alleen de gebruiker die op dat moment is ingelogd wordt toegevoegd.

De processen die DevToolsSecurity mogelijk maakt lijken vooral relevant te zijn voor debuggen en prestatieworkflows met commandoregeltools en scripts. Als je bijzonder gevoelig bent voor beveiliging, kun je testen of je ontwikkelaars hun workflows kunnen gebruiken zonder dit in te schakelen.

SDK's voor platforms beheren met Xcode 14 en 15

Er is nog iets dat je vooraf wilt installeren. De afgelopen jaren heeft Apple de downloads van Xcode enorm verkleind:

• Xcode 11: 7,5 GB
• Xcode 12: 11 GB
• Xcode 13: 10 GB
• Xcode 14: 7 GB*
• Xcode 15: 3,1 GB**

* bevat geen watchOS- en tvOS-SDK's
** bevat geen iOS-, watchOS-, tvOS- en visionOS-SDK's

De meeste van deze besparingen komen doordat de Xcode-download niet meer alle SDK's voor het platform bevat. (Xcode 14 wordt geleverd met macOS en iOS; Xcode 15 bevat alleen macOS.) Aangezien de SDK's voor de platforms nodig zijn om apps op de verschillende platforms te bouwen en te simuleren, wordt gebruikers bij de eerste lancering gevraagd welke platforms ze willen downloaden en installeren.

Dit betekent dat de grote downloads slechts worden uitgesteld, niet vermeden. In totaal zijn Xcode 15 en alle platforms (iOS, watchOS en tvOS) samen goed voor meer dan 17 GB, met visionOS daarbovenop nog eens bijna 7 GB. Er zijn dus geen echte downloadbesparingen in de nieuwe Xcode-versies, integendeel, maar de sterk gereduceerde grootte van de initiële Xcode-installatie zou installaties vanuit de Mac App Store of via Apps and Books betrouwbaarder moeten maken.

Het goede nieuws voor beheerde implementatie is dat de Xcode-gebruiker geen beheerdersrechten hoeft te hebben om extra SDK's te downloaden en te installeren. Ze kunnen kiezen wat ze willen downloaden bij de eerste vraag, of naar het tabblad 'Platforms' gaan in Xcode-instellingen om op een later moment extra platforms te downloaden.

Maar misschien wil je het leven van de eindgebruiker toch wat makkelijker maken. Als je Xcode implementeert in een klaslokaalomgeving, kun je niet de tijd van iedereen verspillen met de vereiste download. Of je zet Xcode in op een Mac voor geautomatiseerde buildprocessen waar helemaal geen gebruiker bij betrokken is. In dat geval wil je de implementatie van de nodige SDK's voor het platform automatiseren.

Enigszins verrassend heeft Apple wat documentatie voor dit, die ons opnieuw wijst op het gebruik van het xcodebuild commando.

Er zijn drie opties in xcodebuild die hiervoor relevant zijn: -downloadAllPlatforms zal, wel, alle beschikbare platformen downloaden. Dit is handig, maar we hebben het over meer dan 20 GB voor alle platforms voor Xcode 15. -downloadAllPreviouslySelectedPlatforms zou handig moeten zijn na een Xcode-update.

Ten slotte is er -downloadPlatform waarmee het aangewezen platform wordt gedownload. De namen voor de verschillende platformen ontbreken in de documentatie en de commando-help, maar zijn meestal gemakkelijk te raden: iOS, watchOS, tvOS en xrOS (voor de visionOS SDK; dit kan nog veranderen tijdens de bètafase?).

Als je het commando opnieuw uitvoert wanneer een platform al geïnstalleerd is, zal het dit opmerken en niet opnieuw downloaden, dus we kunnen gewoon de gewenste platformen toevoegen aan het einde van ons configuratiescript:

Xcode 14 wordt geleverd met de iOS SDK, maar xcodebuild detecteert de bestaande SDK en downloadt deze niet opnieuw. Tijdens mijn tests maakte de download gebruik van een lokale cachingserver, waardoor het aanzienlijk sneller ging.

Met Xcode 15 zag ik een voortgangsbalk voor de gebruiker verschijnen terwijl de download werd geverifieerd. Dit kan verontrustend zijn voor gebruikers als het gebeurt zonder dat zij het proces starten, maar zou geen probleem moeten zijn als dit deel uitmaakt van je initiële implementatieworkflow.

Conclusie

Je kunt een script vinden met alle stappen die je in je beleid kunt gebruiken op GitHub.

Xcode is een belangrijke app voor veel van onze gebruikers. Dit brengt een aantal bijzondere uitdagingen met zich mee voor beheerde implementaties. De tools en scripts die hier worden getoond, zouden je moeten helpen om een geweldige ervaring te creëren voor jou en je gebruikers.

De hier getoonde aanpak heeft voor mij goed gewerkt, maar is waarschijnlijk niet de enige of zelfs de beste voor bepaalde omgevingen.