CircleCI macOS Executor: Welche Ressourcenklasse wählen? Auswahl 2026

Entscheidung: CircleCI zeigt für Jobs Angaben zur Ressourcennutzung, darunter CPU und Arbeitsspeicher; die Dokumentation zur Ressourcenklasse und Jobauslastung beschreibt, wo Sie diese Informationen prüfen. Wählen Sie Ihre macOS-Ressourcenklasse anhand repräsentativer Build-Aufzeichnungen und nicht nach Teamgröße. Ein Wechsel lohnt sich erst, wenn die Belege auf fehlende Ressourcen hinweisen. Brauchen Sie eine kontrollierbare, selbstverwaltete Buildumgebung, bewerten Sie diese Option getrennt.

Dieser Leitfaden ist für CircleCI-Administratoren gedacht, die Ressourcen für iOS- und macOS-Workflows festlegen.
Plattformingenieure finden Kriterien, um Messwerte von Workflow-Problemen zu unterscheiden.
IT-Verantwortliche erhalten eine Grundlage für die Entscheidung zwischen gehostetem Executor und selbstverwaltetem Mac-Buildhost.

Ressourcennutzung: erst den Engpass nachweisen

Eine höhere Ressourcenklasse ist nur dann eine plausible Lösung, wenn der Job tatsächlich durch verfügbare Rechenressourcen begrenzt wird. Die CircleCI-Referenz zur Konfiguration dokumentiert die Konfigurationsoptionen für macOS-Executors und Ressourcenklassen. Prüfen Sie dort, welche Optionen und Bedingungen für Ihr Projekt aktuell gelten, statt eine Konfiguration aus einem älteren Beispiel ungeprüft zu übernehmen.

Erfassen Sie die Ressourcennutzung in den Jobdetails und notieren Sie sie gemeinsam mit dem Jobnamen, dem Commit, der Xcode-Konfiguration und dem Ergebnis. Die Messwerte beschreiben, was während eines konkreten Laufs geschah; sie beweisen für sich genommen nicht, dass eine größere Klasse den Job verkürzen würde. Eine kurze Spitze kann anders zu bewerten sein als eine anhaltend hohe Auslastung während des Kompilierens oder der Tests.

Für die Diagnose trennen Sie drei Fragen:

• Ist CPU-Auslastung während der betroffenen Phase wiederholt hoch? Prüfen Sie, ob die Zeit tatsächlich in Kompilierung oder Tests anfällt oder etwa bei einem Skript, das auf einen externen Dienst wartet.
• Ist der Arbeitsspeicher ein plausibler Engpass? Suchen Sie nach wiederkehrenden Auffälligkeiten oder Fehlern, die zeitlich mit speicherintensiven Schritten zusammenfallen. Allein eine hohe Auslastung ist noch kein Grund für eine Änderung.
• Sind die Läufe vergleichbar? Ein anderer Commit, ein geänderter Cache-Zustand oder eine abweichende Abhängigkeitsinstallation kann die Messung beeinflussen.

Die CircleCI-Anleitung zum macOS-Ausführungsumfeld beschreibt die Plattform und die Konfiguration von macOS-Jobs. Nutzen Sie sie, um Änderungen an Executor- oder Xcode-Einstellungen mit der tatsächlich verwendeten Workflow-Konfiguration abzugleichen. Welche Ressourcenklassen verfügbar sind, kann von Projekt- und Kontobedingungen abhängen. Verifizieren Sie daher die aktuell auswählbaren Optionen in Ihrer CircleCI-Umgebung, bevor Sie einen Versuch planen.

Ein weiterer Fehler ist, einen langsameren Job vorschnell als Hardwareproblem zu behandeln. Prüfen Sie, ob ein Workflow unnötig seriell läuft, Abhängigkeiten wiederholt installiert oder ein Skript auf eine Antwort aus dem Netzwerk wartet. Auch ein unpassender Cache-Schlüssel kann einen Build verlangsamen, ohne dass eine andere Ressourcenklasse den eigentlichen Fehler behebt.

Laufzeit: die Jobphasen statt eines Einzelwerts vergleichen

Die Gesamtzeit ist für die Entscheidung zu grob. Teilen Sie den Ablauf in beobachtbare Phasen: Warten auf einen Executor, Installation von Abhängigkeiten, Kompilierung, Tests und nachgelagerte Schritte wie Artefaktbereitstellung. So erkennen Sie, ob zusätzliche Rechenressourcen überhaupt an der Stelle ansetzen, die Ihren Ablauf ausbremst.

Die CircleCI-Insights-Dokumentation erläutert die verfügbaren Workflow- und Jobinformationen. Verwenden Sie diese Verlaufsansicht zusammen mit den Details einzelner Jobs: Verlaufsdaten helfen, wiederkehrende Muster zu finden; für eine Ursachenanalyse benötigen Sie zusätzlich die konkrete Konfiguration und den Lauf, in dem die Verzögerung auftrat.

Ein belastbarer Versuch vergleicht Läufe, bei denen Sie die wichtigsten Einflussfaktoren konstant halten:

• Verwenden Sie denselben Workflow und möglichst denselben Codezustand.
• Halten Sie Xcode-Version, Abhängigkeiten und relevante Build-Einstellungen gleich.
• Dokumentieren Sie, ob der Lauf einen warmen oder kalten Cache verwendet.
• Ändern Sie bei einem Vergleich gezielt nur die Ressourcenklasse.
• Prüfen Sie nicht nur die gesamte Laufzeit, sondern die Phase, die Sie verbessern wollten.

Berücksichtigen Sie außerdem die Streuung zwischen Läufen. Ein einzelner besonders schneller oder langsamer Job kann durch Änderungen am Code, durch Cache-Effekte oder durch vorübergehende Abhängigkeiten beeinflusst sein. Eine Entscheidung sollte auf einem wiederholbaren Muster beruhen und nicht auf einem isolierten Ergebnis. Legen Sie vor dem Versuch fest, welche Beobachtung für Ihr Team eine Verbesserung bedeutet, etwa eine kürzere Kompilierungsphase ohne zusätzliche Fehler oder problematische Schwankungen.

Die Xcode-Buildkonfiguration ist dabei kein Nebenaspekt. Apples Dokumentation zu den Build-Einstellungen eines Xcode-Targets zeigt, dass Einstellungen des Targets zum Build-Verhalten gehören. Wenn sich diese Einstellungen zwischen den verglichenen Läufen unterscheiden, können Sie den Effekt einer Ressourcenklasse nicht sauber isolieren. Halten Sie deshalb Build- und Testkonfigurationen fest und ändern Sie sie nicht gleichzeitig mit dem Executor.

Warteschlange und Parallelität: getrennte Ursachen, getrennte Maßnahmen

Ein Job, der lange auf den Start wartet, hat nicht zwangsläufig zu wenig CPU oder Arbeitsspeicher. Prüfen Sie, ob die Verzögerung vor der Ausführung entsteht, und vergleichen Sie Job- und Workflow-Zeitpunkte mit den verfügbaren Warteschlangeninformationen. Die CircleCI-Anleitung zu Parallelität und die Hinweise zur Fehlersuche bei Warteschlangen helfen, diese Ursachen von einer langsamen Ausführung zu unterscheiden.

Mehr Ressourcen für einen einzelnen Executor und mehr gleichzeitig verfügbare Ausführungen sind zwei verschiedene Entscheidungen. Eine größere Ressourcenklasse kann eine passende Maßnahme sein, wenn der laufende Job an CPU oder Arbeitsspeicher gebunden ist. Sie ist nicht automatisch eine Lösung für fehlende Parallelität oder eine lange Warteschlange. Umgekehrt beschleunigt mehr Parallelität den einzelnen Kompilierungsschritt nicht zwingend und kann zusätzliche Konkurrenz um gemeinsame Ressourcen erzeugen.

Ermitteln Sie deshalb, ob mehrere Builds gleichzeitig auf einen Start warten, ob nur bestimmte Workflows betroffen sind und ob die Verzögerung bei der Ausführung oder davor entsteht. Prüfen Sie die für Ihr Konto geltenden Parallelitätsbedingungen und gleichen Sie diese mit der aktuellen CircleCI-Dokumentation ab. Verfügbare Optionen und Kontoberechtigungen sind keine allgemeingültige Eigenschaft einer bestimmten Teamgröße.

Achtung: Eine höhere Ressourcenklasse und eine höhere verfügbare Parallelität lösen unterschiedliche Probleme. Ändern Sie beides nicht zugleich: Sonst lässt sich aus dem Versuch nicht ablesen, welche Maßnahme die beobachtete Veränderung bewirkt hat.

Betriebsmodell: gehosteter Executor oder eigener Mac

Ein gehosteter macOS-Executor und ein selbstverwalteter Mac-Buildhost unterscheiden sich nicht nur nach Rechenleistung. Entscheidend ist, wer die Umgebung kontrolliert und wer für ihren Betrieb einsteht. Die Übersicht zu selbstverwalteten CircleCI Runnern beschreibt das Runner-Modell; die Installationsanleitung für den macOS Machine Runner ist relevant, wenn Sie die Einrichtung auf einem Mac prüfen. Behandeln Sie diese Pfade als unterschiedliche Betriebsentscheidungen, nicht als gleichartige Ressourcenklassen.

Ein gehosteter Executor passt eher, wenn:

• Sie den Workflow mit den angebotenen macOS- und Xcode-Konfigurationsmöglichkeiten abbilden können.
• Sie keine zusätzliche Verantwortung für Host-Updates, lokale Werkzeuge und den Zustand einer physischen oder selbstverwalteten Maschine übernehmen möchten.
• Ihre Netzwerk- und Sicherheitsanforderungen mit der tatsächlich verfügbaren Ausführungsumgebung vereinbar sind.
• Ihre Messungen keinen Bedarf für eine abweichende, selbst kontrollierte Host-Konfiguration zeigen.

Ein selbstverwalteter Mac ist prüfenswert, wenn:

• Sie konkrete Host-Einstellungen oder lokal verfügbare Werkzeuge benötigen, die sich im gehosteten Modell nicht passend umsetzen lassen.
• Ihre Build-Jobs einen Netzwerkpfad oder eine interne Abhängigkeit voraussetzen, die Sie im aktuellen Executor nicht ausreichend abbilden können.
• Sie die Kontrolle über Wartungsfenster, installierte Software und Host-Konfiguration benötigen und die dafür nötigen Betriebsressourcen bereitstellen können.
• Ihre Sicherheitsprüfung verlangt, dass Sie den Umgang mit Zugangsdaten, Signierschlüsseln, Logs und Artefakten in Ihrer eigenen Betriebsarchitektur festlegen.

Machen Sie aus Sicherheitsanforderungen keine pauschale Annahme über eine Plattform. Prüfen Sie mit Ihrem Datenschutz- und Sicherheitsteam, welche Daten an den Executor übergeben werden, wie Geheimnisse bereitgestellt werden, wer auf Logs und Artefakte zugreifen kann und welche Netzwerkziele der Workflow erreicht. Für eine DSGVO-Bewertung sind Ihre konkrete Datenverarbeitung, Verträge, Speicherorte und Zugriffsmodelle maßgeblich; aus der Bezeichnung „gehostet“ oder „selbstverwaltet“ folgt keine allgemeine Compliance-Garantie.

Der Eigenbetrieb bringt seinerseits Arbeit mit sich: Sie müssen unter anderem Betriebssystem- und Werkzeugpflege, Zugriffssteuerung, Schlüsselverwaltung, Überwachung und Fehlerbehebung organisieren. Ein eigener Mac ist daher nicht automatisch stabiler oder günstiger. Er kann die passende Wahl sein, wenn Ihre technischen und organisatorischen Anforderungen mehr Kontrolle verlangen und Sie die Betriebsverantwortung tatsächlich tragen können.

Für eine weiterführende Einordnung finden Sie auf unserer Seite Leitfäden zu Mac-Umgebungen verwandte Entscheidungshilfen. Wenn Sie Fragen zur Bereitstellung und zum Zugangsmodell klären müssen, fasst der FAQ-Bereich zu Mac-Angeboten verfügbare Informationen zusammen.

FAQ für die Ressourcenentscheidung

Wie wählen Sie die passende Ressourcenklasse für den CircleCI macOS Executor aus?

Beginnen Sie mit repräsentativen Builds und prüfen Sie in den Jobdetails die angezeigte CPU- und Arbeitsspeicherauslastung. Vergleichen Sie anschließend dieselbe Workflow-Konfiguration und denselben Codezustand. Wechseln Sie erst dann die Ressourcenklasse, wenn die Messwerte und ein kontrollierter Vergleich auf einen Ressourcenengpass hindeuten. Eine größere Klasse behebt weder fehlerhafte Jobaufteilung noch Warteschlangen.

Wann sollte ein macOS-Build in CircleCI auf mehr Ressourcen wechseln?

Ein Wechsel ist prüfenswert, wenn die Ressourcennutzung wiederholt hoch ist und ein kontrollierter Versuch mit einer anderen verfügbaren Klasse die relevante Build- oder Testphase nachvollziehbar verbessert. Prüfen Sie zuerst Abhängigkeiten, Caches, parallele Schritte und Schwankungen im Workflow. Wenn die Wartezeit vor dem Job entsteht, ist mehr Rechenleistung für den einzelnen Job nicht automatisch die passende Maßnahme.

Woran erkennen Sie, ob einem iOS-CI-Build Mac-Ressourcen fehlen?

Betrachten Sie die Ressourcennutzung zusammen mit der Aufteilung der Jobdauer: Warteschlange, Abhängigkeitsinstallation, Kompilierung und Tests. Ein einzelner langsamer Lauf ist kein ausreichender Nachweis. Wiederholte hohe CPU- oder Speicherauslastung während der betroffenen Phase ist ein Hinweis, den Sie mit gleichartigen Läufen und einer gezielten Änderung der Ressourcenklasse überprüfen sollten.

Wann braucht ein Unternehmen einen selbstverwalteten Mac-Buildhost?

Prüfen Sie eine selbstverwaltete Umgebung, wenn Sie die Host-Konfiguration, lokale Werkzeuge oder Netzwerkpfade verbindlich kontrollieren müssen und die Anforderungen im gehosteten Executor nicht abbilden können. Beziehen Sie Wartung, Zugriffsschutz, Updates, Schlüsselverwaltung und Störungsbehebung in die Entscheidung ein. Ein selbstverwalteter Host ist keine automatische Leistungssteigerung, sondern verlagert Betriebsverantwortung auf Ihr Team.

Pilot: Entscheidung mit überprüfbaren Kriterien absichern

Bevor Sie die Ressourcenklasse ändern oder eine eigene Umgebung beschaffen, halten Sie fest, was Sie geprüft haben. Die folgende Checkliste eignet sich als kurze Entscheidungsnotiz für Plattformteam und Einkauf:

• [ ] Haben Sie einen repräsentativen Workflow und einen nachvollziehbaren Codezustand für den Vergleich festgelegt?
• [ ] Haben Sie CPU- und Arbeitsspeicherauslastung aus den Jobdetails mit den betroffenen Build-Phasen verknüpft?
• [ ] Haben Sie Warteschlangenzeit, Abhängigkeitsinstallation, Kompilierung und Tests getrennt betrachtet?
• [ ] Haben Sie Cache-Zustand, Xcode-Konfiguration und Build-Einstellungen dokumentiert?
• [ ] Haben Sie bei einem Ressourcenklassenversuch nur eine relevante Variable geändert?
• [ ] Haben Sie die für Ihr CircleCI-Konto geltenden Ressourcen- und Parallelitätsbedingungen geprüft?
• [ ] Haben Sie Netzwerkzugriffe, Datenschutz, Geheimnisse, Signierschlüssel und Artefaktzugriff mit den zuständigen Stellen abgestimmt?
• [ ] Haben Sie festgelegt, wann Sie den Versuch erneut bewerten und welche Beobachtung eine Änderung des Betriebsmodells rechtfertigt?

Bewerten Sie die Ergebnisse anschließend mit drei qualitativen Kategorien. Beibehalten heißt: Die aktuelle Klasse erfüllt die Anforderungen, und es gibt keinen wiederholten Nachweis eines Ressourcenengpasses. Gezielt anpassen heißt: Messwerte deuten auf eine konkrete Engpassphase, die sich durch einen kontrollierten Versuch beeinflussen lässt. Selbstverwaltung prüfen heißt: Nicht die Jobleistung allein, sondern eine belegte Anforderung an Host-Kontrolle, Netzwerk oder Betrieb lässt sich mit dem aktuellen Modell nicht erfüllen.

Für die Entscheidungsakte genügt keine Aussage wie „der Build ist zu langsam“. Halten Sie fest, welche Phase betroffen ist, welche Daten die Diagnose stützen, welche Änderung Sie getestet haben und ob sich das Ergebnis wiederholen ließ. Wenn nur die Warteschlange auffällig ist, untersuchen Sie zuerst die Parallelität und die Kontoanforderungen. Wenn Installationsschritte dominieren, prüfen Sie Workflow und Abhängigkeiten. Wenn wiederkehrende Messwerte auf einen Ressourcenengpass hindeuten, testen Sie eine andere verfügbare Klasse. Erst wenn Anforderungen an die Umgebung selbst offenbleiben, vergleichen Sie gehosteten Executor und selbstverwalteten Mac als Betriebsmodelle.

Wenn der gehostete Executor nicht mehr zur Anforderung passt

Bleibt Ihr Team beim gehosteten CircleCI-Executor, vermeiden Sie zusätzliche Wartung und die Verantwortung für eine eigene Mac-Hostflotte; dafür müssen Sie Konfiguration, Netzwerkzugriff und die verfügbaren Ausführungsbedingungen innerhalb des angebotenen Modells akzeptieren. Ein selbstverwalteter Mac bietet Ihnen mehr Einfluss auf Host und installierte Werkzeuge, bringt aber Pflegeaufwand, Zugriffsschutz, Updateplanung und Störungsbehebung in Ihr Team. Diese Nachteile sollten Sie gegen eine konkrete, dokumentierte Anforderung abwägen – nicht gegen eine Vermutung über mögliche Performance.

Wenn Ihre Pilotdaten zeigen, dass Sie einen eigenen Mac-Buildhost oder eine kontrollierbare Mac-Umgebung benötigen, können Sie einen zeitlich begrenzten Einsatz mit einem dauerhaften Eigenbetrieb vergleichen. UDPMac bietet Mac-Zugriff über VNC, SSH oder eine Webkonsole mit Root-Rechten und Mietlaufzeiten nach Bedarf. Prüfen Sie vor einem Einsatz, ob Zugriffsmodell, Netzwerk, Signierablauf und Datenschutzvorgaben zu Ihrem Workflow passen; die verfügbaren Informationen finden Sie auf der UDPMac-Übersichtsseite. Für dauerhaft hohe, stabile Lasten oder Anforderungen an physische Schnittstellen kann ein eigener Mac weiterhin die passendere Wahl sein.

Häufig gestellte Fragen