Mit einem Beleg beginnen und danach entscheiden
GitHub Actions kann Workflows derselben concurrency group so steuern, dass jeweils höchstens eine Ausführung gleichzeitig läuft. Das ist eine Eigenschaft der Workflow-Steuerung, nicht automatisch ein Hinweis darauf, wie viele Macs ein Team benötigt. Für die Auswahl eines iOS-Build-Servers gilt deshalb: Entscheiden Sie nicht anhand der App-Anzahl. Lassen Sie persönliche, seltene Builds zunächst auf einer Mac-Umgebung laufen und protokollieren Sie die Wartezeiten. Prüfen Sie zusätzliche Umgebungen erst, wenn voneinander unabhängige Aufgaben regelmäßig gleichzeitig warten oder Test und Veröffentlichung getrennte Berechtigungen benötigen. GitHub erklärt die Steuerung paralleler Workflow-Ausführungen.
Dieser Leitfaden richtet sich an unabhängige Entwickler, die Builds und Veröffentlichungen für eine oder mehrere iOS-Apps organisieren.
Kleine Teams erfahren, wann sich Aufgaben in einer gemeinsamen Warteschlange ausführen lassen und wann eine Trennung sinnvoller ist.
Verantwortliche für Veröffentlichungen können Test- und Signieraufgaben nach Werkzeugkette, Zugang und Zuständigkeit beurteilen.
Die Zahl der Apps von der tatsächlichen Auslastung trennen
Mehrere Projekte bedeuten nicht automatisch mehrere gleichzeitig laufende Builds. Entscheidend ist, ob Aufgaben tatsächlich zeitgleich eintreffen, voneinander unabhängig sind und dieselben Ressourcen oder Berechtigungen beanspruchen. Diese Unterscheidung verhindert sowohl unnötige Umgebungen als auch eine Warteschlange, die regelmäßig reale Arbeit blockiert.
| Situation | Was zuerst geprüft wird | Naheliegende Entscheidung |
|---|---|---|
| Eine Person baut eine App gelegentlich | Wann Aufgaben eingereicht, gestartet und beendet werden | Eine Mac-Umgebung zunächst weiterverwenden |
| Eine Person betreut mehrere Apps | Ob Projekte nacheinander oder zeitgleich gebaut werden; außerdem Werkzeugketten und Signierung | Gemeinsam nutzen, wenn Aufgaben nacheinander passen und Anforderungen kompatibel sind |
| Ein Team teilt sich Builds | Herkunft der Aufgaben, Zugriffsrechte und tatsächliche Wartezeiten | Gemeinsame Warteschlange oder getrennte Umgebungen je nach Risiko und Überschneidung |
| Test und Veröffentlichung liegen in verschiedenen Verantwortungsbereichen | Ob Zugangsdaten und Freigaben voneinander getrennt sein müssen | Eine eigenständige Veröffentlichungsumgebung prüfen |
Benötigt eine einzelne iOS-App einen eigenen Build-Server?
Bei einer einzelnen App und seltenen, manuell ausgelösten Builds reicht eine gemeinsame Mac-Umgebung häufig als Ausgangspunkt. Das gilt, solange die Wartezeit akzeptabel ist, keine Aufgabe dauerhaft auf eine andere wartet und die benötigte Xcode-Version sowie die zugehörige macOS-Version für das Projekt geeignet sind.
Notieren Sie dafür nicht nur, wann ein Build fehlschlägt. Halten Sie auch fest, wann er eingereicht wurde, wann die Ausführung tatsächlich begann, wann sie endete und ob eine andere Aufgabe den Start verzögerte. So lässt sich ein einmaliges Zusammentreffen von einer wiederkehrenden Blockade unterscheiden. Ohne diese Beobachtung führt ein gelegentlich langsamer Build leicht zu einer voreiligen Kauf- oder Mietentscheidung.
Eine Warteschlange, die selten stört, ist nicht dasselbe wie ein Kapazitätsproblem. Erst wenn Wartezeiten wiederkehren und konkrete Entwicklungs- oder Veröffentlichungsschritte verzögern, spricht das für eine Änderung.
Können mehrere iOS-Apps eine Mac-Umgebung gemeinsam nutzen?
Ja, wenn die Projekte abwechselnd gebaut werden können und sich ihre Anforderungen auf derselben Umgebung verlässlich erfüllen lassen. Die Anzahl der Repositories sagt nicht, ob sich Builds tatsächlich überschneiden. Zwei Projekte können nacheinander laufen, während schon eine einzelne App durch parallele Tests und einen zusätzlichen Veröffentlichungsbuild mehrere gleichzeitig anstehende Aufgaben erzeugt.
Bevor Aufgaben zusammengelegt werden, sind mindestens diese Punkte pro Projekt zu vergleichen:
- Erforderliche Xcode- und macOS-Versionen
- Abhängigkeiten und projektspezifische Einstellungen
- Signieranforderungen und Zugriff auf Zertifikate oder Profile
- Erlaubte Auslöser, insbesondere Änderungen aus externen oder nicht vertrauenswürdigen Beiträgen
- Zuständigkeit für Freigabe, Archivierung und Upload
Die Kompatibilität darf nicht aus dem Namen der Projekte abgeleitet werden. Apple veröffentlicht versionsbezogene Anforderungen für Xcode und macOS; die passende Kombination ist daher anhand der aktuellen Apple-Systemanforderungen für Xcode zu prüfen. Für Xcode 27 geben die Apple-Versionshinweise zu Xcode 27 an, dass diese Version nur auf einem Mac mit Apple silicon installiert und ausgeführt werden kann. Daraus folgt keine pauschale Empfehlung zur Zahl der Macs, sondern eine konkrete Prüfung der benötigten Toolchain.
Die Entscheidung nach Nutzergruppe und Verantwortung treffen
| Nutzergruppe | Typischer Engpass | Vor einer zusätzlichen Umgebung prüfen |
|---|---|---|
| Einzelentwickler | Einzelne Builds warten gelegentlich | Wiederholt sich die Verzögerung, und verschiebt sie tatsächlich die Arbeit? |
| Entwickler mit mehreren Apps | Projekte benötigen unterschiedliche Umgebungen | Sind die Anforderungen gleichzeitig relevant oder lassen sich die Builds nacheinander ausführen? |
| Kleines Team | Mehrere Personen starten Aufgaben oder teilen Zugänge | Sind es reine Warteschlangenprobleme oder gibt es unterschiedliche Vertrauens- und Berechtigungsgrenzen? |
| Veröffentlichungsverantwortliche | Tests und Release-Aufgaben vermischen sich | Müssen Signierung und Freigabe von gewöhnlichen Tests getrennt werden? |
Mehrere Projekte betreuen, aber Builds abwechselnd starten
Wenn ein Entwickler mehrere Apps pflegt, die Builds aber zu unterschiedlichen Zeiten anstößt, kann eine gemeinsame Umgebung sinnvoll sein. Das ist besonders dann naheliegend, wenn die Werkzeugketten zusammenpassen und keine getrennten Berechtigungen erforderlich sind. Der Vorteil liegt nicht in einer behaupteten Leistungssteigerung, sondern darin, vorerst keine zweite Umgebung zu verwalten.
Anders liegt der Fall, wenn verschiedene Projekte regelmäßig zeitgleich gebaut werden oder unterschiedliche Xcode- und macOS-Kombinationen benötigen. Dann kann eine gemeinsame Umgebung entweder Wartezeit erzeugen oder häufige Änderungen an Werkzeugen und Einstellungen erfordern. Prüfen Sie zuerst, ob getrennte Aufgaben in der Warteschlange ausreichen. Erst wenn diese Reihenfolge den tatsächlichen Ablauf behindert oder die Umgebungsanforderungen kollidieren, ist eine zusätzliche, getrennt eingerichtete Umgebung zu erwägen.
Im kleinen Team zwischen Warten und Isolation unterscheiden
Eine gemeinsame Warteschlange eignet sich für Aufgaben, die nacheinander laufen dürfen und keine voneinander unabhängigen Zugangsdaten oder Verantwortlichkeiten erfordern. Sie ist keine automatische Lösung, wenn der Code unterschiedlicher Herkunft ist oder Personen unterschiedliche Rechte haben. Für GitHub Actions beschreibt die Dokumentation sowohl die Aufgabenzuweisung an selbstverwaltete Runner als auch die Auswahl solcher Runner in einem Workflow. Das Routing kann festlegen, welcher Runner eine Aufgabe erhält; es beantwortet jedoch nicht, ob Teammitglieder dieselben Berechtigungen teilen sollten.
Bei selbstverwalteten Runnern ist die Herkunft des ausgeführten Codes relevant. GitHub warnt in seinen Hinweisen zur sicheren Nutzung selbstverwalteter Runner vor Sicherheitsrisiken, die entstehen können, wenn nicht vertrauenswürdiger Code auf einer solchen Infrastruktur ausgeführt wird. Auch die Hinweise zur sicheren Verwendung von pull_request_target machen deutlich, dass Workflow-Auslöser und der Umgang mit Beiträgen sorgfältig zu beurteilen sind. Eine zusätzliche Mac-Umgebung ist damit nicht automatisch sicher; sie kann aber eine Trennung ermöglichen, wenn die Zugriffs- und Ausführungsregeln tatsächlich getrennt gestaltet werden.
Behandeln Sie „mehr Builds gleichzeitig“ und „mehr Sicherheit“ als unterschiedliche Anforderungen. Eine zusätzliche Maschine erhöht nicht von selbst die Sicherheit, wenn Zugangsdaten, Workflow-Rechte und erlaubte Aufgaben unverändert gemeinsam genutzt werden.
Test und Veröffentlichung getrennt bewerten
Tägliche Prüfungen, Simulator-Tests und formelle Release-Aufgaben können unterschiedliche Anforderungen haben. Ein Testlauf kann häufig automatisch starten; eine Veröffentlichung kann dagegen an Signierung, Freigaben oder eine klar benannte Verantwortlichkeit gebunden sein. Bevor eine zusätzliche Umgebung eingeplant wird, sollte deshalb feststehen, welche Arbeit interaktiv erfolgen muss und welche Schritte zuverlässig automatisiert werden können.
Prüfen Sie außerdem, wer auf Zertifikate und Veröffentlichungsfunktionen zugreifen darf. Apple führt die verfügbaren Rollen und Berechtigungen im Apple Developer Program auf. Diese Rolleninformationen ersetzen keine interne Zugriffsprüfung, helfen aber dabei, Aufgaben und Rechte nicht nur nach technischer Bequemlichkeit zusammenzulegen. Eine separate Release-Umgebung ist besonders dann ein sinnvoller Prüfpunkt, wenn Testaufgaben aus unterschiedlichen Quellen stammen oder nicht dieselben Personen für Signierung und Freigabe verantwortlich sind.
Warteschlangen mit beobachtbaren Belegen prüfen
GitHub Actions bietet mit concurrency groups eine Möglichkeit, Ausführungen nach einer Gruppe zu steuern. Diese Regel wirkt auf die Workflow-Ausführung; sie beschreibt nicht die verfügbare Rechenleistung eines Macs und liefert keine allgemeine Zahl benötigter Geräte. In der Dokumentation zu GitHub-Actions-Concurrency sind die Regeln für laufende und wartende Ausführungen beschrieben. Prüfen Sie daher getrennt, ob eine Verzögerung aus der Workflow-Konfiguration, aus der Runner-Zuweisung oder aus der Mac-Umgebung selbst entsteht.
Eine einfache Aufzeichnung kann in einem CI-Protokoll oder einer Tabelle erfolgen:
| Beobachtung | Was sie erkennen lässt | Welche Frage als Nächstes zählt |
|---|---|---|
| Einreichungs- und Startzeit | Ob Aufgaben tatsächlich warten | Ist das regelmäßig oder nur ein Einzelfall? |
| Gleichzeitig laufende Aufgaben | Ob Builds einander zeitlich überschneiden | Können sie ohne Nachteil nacheinander laufen? |
| Wiederholungen nach fehlgeschlagenen Läufen | Ob Fehler die Warteschlange zusätzlich beanspruchen | Liegt die Ursache bei Code, Runner, Toolchain oder Berechtigungen? |
| Verzögerung bis zur Auslieferung | Ob die Warteschlange einen konkreten Termin oder Arbeitsschritt beeinträchtigt | Rechtfertigt die Auswirkung eine andere Aufteilung? |
Diese Beobachtungen sollten nicht zu einem unbelegten Grenzwert verdichtet werden. Ein kurzer Rückstau kann im Alltag akzeptabel sein, während ein einzelner blockierter Release-Prozess relevant sein kann. Umgekehrt macht eine hohe Zahl eingereichter Builds eine zweite Mac-Umgebung nicht notwendig, wenn sie zuverlässig nacheinander laufen und die Verzögerung keine Folgen für die Arbeit hat.
Vor einer weiteren Mac-Umgebung repräsentative Aufgaben prüfen
Wenn die Aufzeichnungen auf wiederkehrende Überschneidungen hindeuten, prüfen Sie die Entscheidung anhand echter Projekte statt anhand eines abstrakten Leistungsversprechens. Dabei geht es nicht nur darum, ob ein Build startet. Auch Abhängigkeiten, Tests, Signierung, Upload-Schritte und Berechtigungsgrenzen müssen zu den jeweiligen Aufgaben passen.
- Aufgaben auswählen: Nehmen Sie einen typischen Testbuild und, falls die Verantwortlichkeiten es erfordern, einen getrennten Veröffentlichungsablauf.
- Anforderungen erfassen: Dokumentieren Sie die benötigten Xcode- und macOS-Versionen, Abhängigkeiten, Signierung und Auslöser. Apple-Systemanforderungen und versionsbezogene Hinweise sind dafür geeignete Ausgangspunkte.
- Zugriffsregeln festlegen: Prüfen Sie, welche Personen und Workflows Quellcode, Zugangsdaten und Release-Funktionen verwenden dürfen. Berücksichtigen Sie dabei sowohl die Apple-Rollen als auch die Sicherheitsvorgaben für selbstverwaltete Runner.
- Aufgaben nacheinander und getrennt bewerten: Ermitteln Sie, ob eine gemeinsame Warteschlange die Arbeit ausreichend unterstützt oder ob gleichzeitige Ausführung beziehungsweise getrennte Verantwortung nötig ist.
- Ergebnis dokumentieren: Halten Sie fest, welche Aufgabe auf welcher Umgebung läuft, wo sie wartet und ob die Trennung ein konkretes Risiko oder eine Verzögerung adressiert.
- Erst dann die Beschaffung prüfen: Vergleichen Sie Kauf, vorhandene Hardware und zeitlich begrenzte Remote-Mac-Nutzung anhand der erforderlichen Laufzeit, Verantwortung und Verwaltungsarbeit.
Diese Prüfung beantwortet auch, wann unabhängige Entwickler mehrere Remote Macs benötigen: nicht bei einer pauschalen Zahl von Apps oder Mitarbeitenden, sondern wenn wiederkehrende, voneinander unabhängige Aufgaben nicht mehr passend nacheinander ausgeführt werden können oder die Release-Verantwortung eine echte Trennung verlangt.
| Ansatz | Geeignet, wenn | Vor der Entscheidung zu bedenken |
|---|---|---|
| Vorhandene Mac-Umgebung weiterverwenden | Aufgaben selten anstehen oder nacheinander laufen können | Verfügbarkeit, Speicherplatz, Toolchain-Wechsel und Zugriff im Alltag |
| Zusätzliche eigene Mac-Hardware | Eine dauerhaft verfügbare, selbst verwaltete Umgebung gebraucht wird | Anschaffung, Wartung, Standort und Verantwortung für Updates und Zugangsschutz |
| Remote-Mac-Umgebung mieten | Eine zusätzliche Umgebung für einen begrenzten Zeitraum oder eine bestimmte Aufgabe gebraucht wird | Projektanforderungen, Zugriffsmodell, Übergabe und tatsächliche Eignung vorab prüfen |
Wer Remote Macs erwägt, sollte vor der Auswahl die eigenen Aufgaben und Anforderungen schriftlich festhalten. Die Preisübersicht von RUVCLOUD kann anschließend in die wirtschaftliche Prüfung einbezogen werden; konkrete Eignung ergibt sich jedoch erst aus dem Abgleich mit den benötigten Projekten, Werkzeugketten und Zugriffsregeln. Für die Prüfung einer Buchungsoption lässt sich außerdem die Bestellübersicht von RUVCLOUD heranziehen. Angaben zu Kosten oder Ausstattung sollten ausschließlich anhand der dort tatsächlich ausgewiesenen Informationen verglichen werden.
Mit einer bedingten Entscheidung statt einer festen Gerätezahl planen
Nutzen Sie diese Entscheidungsliste, bevor Sie eine weitere Umgebung bestellen oder bereitstellen:
- Wenn eine Person Builds für ein Projekt selten startet und die Aufgaben gewöhnlich nacheinander laufen, dann bleibt eine einzelne Umgebung der erste Prüfpunkt.
- Wenn mehrere Apps betreut werden, die Builds aber nicht regelmäßig kollidieren und ihre Toolchain-Anforderungen zusammenpassen, dann können sie zunächst dieselbe Umgebung nutzen.
- Wenn Aufgaben wiederholt gleichzeitig warten und die Verzögerung konkrete Entwicklungs- oder Veröffentlichungsschritte blockiert, dann prüfen Sie eine zweite Umgebung oder eine gezielte Änderung der Warteschlange.
- Wenn unterschiedliche Vertrauensbereiche, Rechte oder Release-Verantwortlichkeiten bestehen, dann bewerten Sie Isolation unabhängig von der Build-Geschwindigkeit.
- Wenn die Verzögerung vor allem durch Runner-Zuweisung oder Workflow-Regeln entsteht, dann korrigieren Sie zuerst diese Konfiguration, statt automatisch weitere Mac-Hardware einzuplanen.
Eine lokale Mac-Umgebung kann für dauerhafte Arbeit sinnvoll sein, bindet aber Kapital und verlangt eigene Pflege; eine gemeinsam genutzte CI-Umgebung kann dagegen bei unterschiedlichen Werkzeugketten, Zugangsdaten oder Zuständigkeiten zu viele Aufgaben zusammenführen. Wenn die Aufzeichnungen einen zeitlich begrenzten Bedarf oder einen klar abgrenzbaren Test- und Release-Ablauf zeigen, kann eine Remote-Mac-Miete von RUVCLOUD eine passendere Alternative zur sofortigen Anschaffung sein. Vor der Entscheidung sollte ein repräsentativer Build einschließlich der nötigen Tests und Veröffentlichungsschritte geprüft werden; fehlen echte Überschneidungen und ein nachvollziehbarer Isolationsgrund, ist eine zusätzliche Umgebung nicht automatisch gerechtfertigt.