Lösung

macOS Build Server für iOS, ohne eigenen Mac im Büro

iOS- und macOS-Builds brauchen macOS-Hardware. Oft übernimmt das ein Mac mini unter dem Schreibtisch, der Updates braucht und bei Ausfall blockiert. Die Plattform stellt macOS-Geräte für die Pipeline bereit. Eigene macOS-Workspaces zum interaktiven Arbeiten folgen.

macOS-Geräte in der Pipeline für iOS- und macOS-Builds
Direkt an die GitLab-CI-Pipeline angebunden
Signing-Zugangsdaten verwaltet, Releases bis in App Store und Mac App Store

Kostenlos registrieren Funktionen ansehen

Kostenlos starten. Keine Kreditkarte nötig.

Lokal oder in der Cloud arbeiten?

Ganz deine Entscheidung – wir geben dir für beide Wege das ideale Setup.

Lokal Setup-App

Git & Repos
Flutter SDK
Node.js
Docker

Die Setup-App erkennt Tools und startet alles mit einem Klick.

Cloud Remote-Workspace

Ubuntu VM
VS Code im Browser
Von überall

Fertige Entwicklungsumgebung – kein lokales Setup nötig.

macOS-Geräte der Pipeline für iOS- und macOS-Builds.

Kurz gesagt

Der Bedarf an macOS verschwindet nicht, aber die Hardware muss nicht bei dir stehen.

macOS in der Pipeline: iOS- und macOS-Builds laufen auf Geräten der Plattform. Eigene macOS-Workspaces zum interaktiven Arbeiten folgen.
An die Pipeline angebunden: Builds laufen über GitLab CI, lesbar im Repository konfiguriert.

Eigene Mac-Hardware und macOS-Geräte der Pipeline im Vergleich

Die Gegenüberstellung beschreibt den üblichen Alltag mit einem eigenen Mac für Builds im Vergleich zu macOS-Geräten aus der Plattform.

Aufgabe	Mit der Application Platform	Eigene Mac-Hardware
Verfügbarkeit für Builds	Vollständig abgedeckt: macOS-Geräte der Pipeline stehen für Builds bereit	Teilweise abgedeckt: Ein Gerät, das läuft, wenn es läuft
Ausfall eines Geräts	Vollständig abgedeckt: Ein anderes Build-Gerät der Pipeline übernimmt, der Ablauf bleibt derselbe	Nicht angeboten: Der Release-Prozess steht, bis jemand die Maschine repariert
Xcode und Systempflege	Vollständig abgedeckt: Umgebung wird bereitgestellt, du musst kein Gerät administrieren	Nicht angeboten: Updates, Speicherplatz und Neustarts übernimmt jemand nebenbei
Anbindung an CI/CD	Vollständig abgedeckt: Fester Bestandteil der GitLab-CI-Pipeline des Projekts	Teilweise abgedeckt: Runner selbst installieren, absichern und aktuell halten
Interaktiver Zugriff	Teilweise abgedeckt: Ubuntu-Workspaces per RDP und VNC. Interaktive macOS-Workspaces folgen	Teilweise abgedeckt: Physischer Zugang oder selbst eingerichtete Fernwartung
Signing-Zugangsdaten	Vollständig abgedeckt: Apple Credentials und weiteres Signing-Material zentral verwaltet	Nicht angeboten: Zertifikate im Schlüsselbund eines bestimmten Rechners
Parallele Builds	Vollständig abgedeckt: Mehrere Build-Geräte der Pipeline, wenn mehrere Projekte gleichzeitig bauen	Nicht angeboten: Builds stehen hintereinander in der Warteschlange
Veröffentlichung in den Stores	Vollständig abgedeckt: App Store und Mac App Store aus der Pipeline, mit Metadaten und Screenshots	Teilweise abgedeckt: Uploads von Hand oder eigene Fastlane-Einrichtung
Developer-ID und Notarisierung	Vollständig abgedeckt: Signierung und Notarisierung für macOS-Anwendungen gehören zum Ablauf	Teilweise abgedeckt: Manuell nachgebaut und bei jeder Änderung erneut geprüft
Zugriffsrechte	Vollständig abgedeckt: Rollen und Projektzugehörigkeit bestimmen, wer einen Pipeline-Build auslösen darf	Nicht angeboten: Faktisch jeder mit Zugang zum Gerät

Grün bedeutet abgedeckt, gelb teilweise, grau nicht vorhanden. Die rechte Spalte beschreibt keinen Anbieter, sondern den üblichen Zustand mit eigener Hardware.

Stand: 10. August 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen. Logos sind Marken der jeweiligen Rechteinhaber und dienen nur der Zuordnung.

Was macOS in der Cloud im Alltag bringt

Sechs Punkte, die sich ab dem ersten iOS-Release bemerkbar machen.

Keine Einzelabhängigkeit

Der Release-Prozess hängt nicht mehr an einem Gerät, das jemand im Büro angeschaltet lassen muss.

Pipeline-Macs statt Büro-Mac

iOS-Builds laufen auf macOS-Geräten der Pipeline. Ubuntu-Workspaces erreichst du per RDP, VNC oder VS Code im Browser; eigene macOS-Workspaces folgen.

In der Pipeline verankert

Builds laufen über GitLab CI. Die Konfiguration liegt lesbar im Repository und lässt sich anpassen.

Signing zentral verwaltet

Apple Credentials, Android Keystore und Azure Artifact Signing liegen in der Plattform statt im Schlüsselbund eines Laptops.

Store-Releases inklusive

Releases gehen über Fastlane in App Store und Mac App Store, für macOS mit Developer-ID-Signierung und Notarisierung.

Ubuntu-Workspaces für den Alltag

Für den Alltag startest du Ubuntu-Workspaces mit VS Code, JetBrains, RDP oder VNC. Interaktive macOS-Workspaces mit Xcode folgen.

So kommst du an einen macOS Build Server

Vier Schritte vom Projekt bis zum signierten Build.

Projekt anlegen

Wähle ein Flutter-, Expo- oder natives iOS-Template. Repository, Struktur und Pipeline entstehen mit.
Apple-Zugangsdaten hinterlegen

Apple Credentials und die zugehörigen Store-Zugänge werden in der Plattform gespeichert und über Rollen freigegeben.
Build in der Pipeline auslösen

Die Pipeline baut und signiert auf macOS-Geräten der Plattform. Eigene macOS-Workspaces zum interaktiven Arbeiten per RDP oder VNC folgen.
Build und Release auslösen

Die Pipeline baut, signiert und lädt hoch. Für macOS-Anwendungen gehören Developer-ID-Signierung und Notarisierung dazu.

Häufige Fragen

Brauche ich für iOS-Builds trotzdem einen eigenen Mac?

Für Builds in der Pipeline nicht. Die Plattform stellt macOS-Geräte bereit, auf denen gebaut und signiert wird. Eigene macOS-Workspaces, die du selbst startest und per RDP oder VNC nutzt, folgen. Ein eigener Mac bleibt sinnvoll für lokale Arbeit, ist aber keine Voraussetzung für den Store-Upload.

Kann ich schon einen macOS-Workspace anlegen?

Noch nicht. Unter Workspaces wählst du aktuell Ubuntu (Windows und macOS folgen). iOS-Builds laufen trotzdem über die Projekt-Pipeline auf macOS-Geräten der Plattform.

Werden macOS-Anwendungen auch veröffentlicht?

Ja. Neben dem Apple App Store lässt sich der Mac App Store aus demselben Projekt bespielen. Für Anwendungen außerhalb des Stores gehören Developer-ID-Signierung und Notarisierung dazu. Metadaten pflegst du im Editor, veröffentlicht wird über Fastlane.

iOS-Projekt anlegen

Registriere dich kostenlos, lege ein iOS-Projekt an und lass den ersten Build auf einem macOS-Gerät der Plattform laufen. Eigene macOS-Workspaces zum interaktiven Arbeiten folgen.

Kostenlos registrieren Mit uns sprechen