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-Workspaces in der Cloud bereit.

macOS-Workspaces in der Cloud, erreichbar per RDP und VNC
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 Platform App

Git & Repos
Flutter SDK
Node.js
Docker

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 in der Cloud, erreichbar per RDP und VNC.

Kurz gesagt

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

macOS in der Cloud: Workspaces für iOS- und macOS-Builds, erreichbar per RDP und VNC.
An die Pipeline angebunden: Builds laufen über GitLab CI, lesbar im Repository konfiguriert.

Eigene Mac-Hardware und macOS-Workspaces 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-Workspaces werden bei Bedarf gestartet	Teilweise abgedeckt: Ein Gerät, das läuft, wenn es läuft
Ausfall eines Geräts	Vollständig abgedeckt: Ein anderer Workspace übernimmt, der Ablauf bleibt derselbe	Nicht vorgesehen: 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 vorgesehen: 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	Vollständig abgedeckt: RDP und VNC über stabile Gateway-URLs, auch aus dem Homeoffice	Teilweise abgedeckt: Physischer Zugang oder selbst eingerichtete Fernwartung
Signing-Zugangsdaten	Vollständig abgedeckt: Apple Credentials und weiteres Signing-Material zentral verwaltet	Nicht vorgesehen: Zertifikate im Schlüsselbund eines bestimmten Rechners
Parallele Builds	Vollständig abgedeckt: Mehrere Workspaces möglich, wenn mehrere Projekte gleichzeitig bauen	Nicht vorgesehen: 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 eine Umgebung öffnen darf	Nicht vorgesehen: 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.

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.

Zugriff per RDP und VNC

macOS-Workspaces sind über stabile Gateway-URLs erreichbar, auch wenn du nicht im selben Netz sitzt.

In der Pipeline verankert

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

Signing zentral verwaltet

Der Workspace ist nicht nur Build-Ziel: Du kannst darin arbeiten, wenn eine Aufgabe Xcode oder Simulatoren braucht.

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.
macOS-Workspace starten

Starte eine macOS-Umgebung und verbinde dich per RDP oder VNC, wenn du interaktiv arbeiten willst.
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 nicht. Die Plattform stellt macOS-Geräte in der Cloud bereit, die die Pipeline baut und signiert. Du nutzt sie auch interaktiv per RDP oder VNC. Ein eigener Mac bleibt sinnvoll für lokale Arbeit, ist aber keine Voraussetzung mehr.

Wie greife ich auf einen macOS-Workspace zu?

Über stabile Gateway-URLs, die nach einem Neustart gleich bleiben. Von dort startest du eine grafische Sitzung per RDP oder VNC. Wer zugreifen darf, regeln Rollen und Projektzugehörigkeit. Der Zugriff aus dem Homeoffice ist damit derselbe wie aus dem Büro.

Werden macOS-Anwendungen auch veröffentlicht?

Ja, weil die Umgebungen nicht an ein Gerät gebunden sind. Bei eigener Hardware stehen Builds in der Warteschlange, was in Agenturen mit mehreren Kundenprojekten spürbar wird. Wie viele Umgebungen und CI-Minuten enthalten sind, hängt vom Plan ab.

Starte einen macOS-Workspace

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

Kostenlos registrieren Mit uns sprechen