Strom, Netzwerk und Kühlung übernimmt das RechenzentrumIhr Build-Server ist 365 Tage im Jahr online

Dedizierter physischer Mac mini statt VM – rund um die Uhr verfügbar. Unsere iOS-Build-Server stehen in fünf Rechenzentrumsregionen: Singapur, Tokio, Seoul, Hongkong und im Westen der USA. Das gesamte Gerät ist Ihrem Team vorbehalten.

Build-Server mieten Drei Tarife vergleichen
Port M4 Base ab $19.7/TagPro Tag · Woche · Monat · QuartalAbrechnung in USD

Build-Planung

tokyo-node-07 · Apple Silicon M4 Pro · 64 GB Unified Memory · 2 TB SSD

Ganzjähriger Betrieb365 Tage onlineBeispielhafte Serviceplanung · jedes Feld steht für 1 Tag
Pipeline · Beispielplanung
00:0006:0012:0018:00
main7 Läufe · durchschnittlich 6m12s (Beispiel)
release/2.43 Läufe · durchschnittlich 9m40s (Beispiel)
nightlyAb 02:00 · inklusive UI-Tests

nightly-Beispiel: UI-Tests, 2h05m. Verschiedene Branches teilen sich CPU, Arbeitsspeicher und Speicherplatz Ihres Teams. Die Parallelität sollte anhand Ihrer Projekte getestet werden.

CPU-Auslastung (Beispiel)Nur Aufgaben Ihres Teams

Planung, Laufzeiten und Online-Anzeigen sind Produktbeispiele, keine Messwerte. Den tatsächlichen Status sehen Sie in Echtzeit in der Konsole.

Gängige Build-Tools unverändert auf einem dedizierten Server nutzen

Xcode fastlane GitHub Actions GitLab CI Jenkins Flutter React Native

Diese Tools werden wie üblich auf dem Server installiert und funktionieren wie auf Ihrem eigenen Mac. Die Nennung beschreibt lediglich die Einsatzmöglichkeiten und stellt keine Partnerschaft oder Empfehlung dar. Ihr Team verwaltet weiterhin Tool-Versionen, Abhängigkeiten und Runner-Updates.

Vor- und Nachteile

Eigenbetrieb, Shared Runner oder dediziertes Hosting: Was passt zu Ihrem Team?

Alle drei Ansätze sind verbreitet. Wir zeigen, für wen sie geeignet sind – und für wen nicht. Vergleichen Sie die Optionen, bevor Sie einen iOS-Build-Server mieten.

Eigenbetrieb

Mac mini im eigenen Büro

Günstiger bei wenigen Builds und vorhandener Hardware

Geeignet

  • Sie erstellen nur gelegentlich Builds und haben bereits einen ungenutzten Mac.
  • Jemand kann Stromversorgung, Netzwerk und Systemupdates betreuen.
  • Code oder Abhängigkeiten müssen im Firmennetz bleiben.

Weniger geeignet

  • Mehrere Merges täglich; nächtliche Builds dürfen nicht von der Stromversorgung im Büro abhängen.
  • Häufige Netzwerkausfälle, und für jeden Neustart muss jemand vor Ort sein.
  • Sie möchten die Hardwarebetreuung aus dem Aufgabenbereich des Release Engineering herauslösen.
Shared Runner

Gemeinsam genutzter Runner

Praktisch bei geringem Build-Aufkommen, wenn Warteschlangen akzeptabel sind

Geeignet

  • Wenige, unregelmäßige Builds; Wartezeiten beeinträchtigen den täglichen Merge nicht.
  • Sie müssen kurzfristig viele parallele Aufgaben starten können.
  • Sie möchten den Aufwand für die Maschinenverwaltung gering halten.

Weniger geeignet

  • Builds stehen häufig in der Warteschlange und Releases hängen von gemeinsam genutzten Kapazitäten ab.
  • Sie sind für schnellere Builds dauerhaft auf DerivedData- und Dependency-Caches angewiesen.
  • Sie benötigen langfristig eine kontrollierbare macOS-Umgebung.
Dediziertes Hosting

Dedizierter Server im Rechenzentrum

Passend bei häufigen Builds und ohne eigene Hardwarebetreuung

Geeignet

  • Mehrere Merges täglich, ohne sich um Strom, Netzwerk und Kühlung kümmern zu wollen.
  • Sie möchten Caches behalten und die Reihenfolge der Branch-Builds selbst festlegen.
  • Ihr Team entwickelt unter Windows und benötigt macOS für Remote-Builds.

Weniger geeignet

  • Nur ein oder zwei Builds pro Monat, bei langfristig ungenutzter eigener Hardware.
  • Sie benötigen eine sofortige Skalierung auf Dutzende Maschinen; ein einzelner dedizierter Server bietet nur begrenzte Flexibilität.
  • Sie möchten auch Projektabhängigkeiten, Zertifikate und Pipelines vollständig verwalten lassen.
Tarife vergleichen
365 Tage online

Server im Rechenzentrum, 365 Tage im Jahr online

Das Rechenzentrum übernimmt Stromversorgung, Netzwerk und Kühlung. Nächtliche nightly-Builds fallen nicht mehr wegen eines abgeschalteten Büros aus.

365Tage

Ganzjährig online

Der Server wird nicht mit den Bürozeiten ein- und ausgeschaltet.

0Mal

Geplante Ausfallzeiten

Sie müssen Ihre Build-Planung nicht an regelmäßige Abschaltungen durch den Anbieter anpassen.

5Standorte

Rechenzentrumsregionen

Singapur, Tokio, Seoul, Hongkong und Westen der USA.

1 Server / 1 Team

Dedizierter physischer Server

Das Gerät wird nicht mit anderen Kunden geteilt.

Wichtiger Hinweis:Ganzjähriger Betrieb schließt Hardwareausfälle nicht aus. Melden Sie Störungen zuerst per Ticket mit Server und Fehlermeldung; wir unterstützen Sie bei der Fehlersuche, einem Serverwechsel und der Wiederherstellung der Umgebung. Sichern Sie Code, Signiermaterial, Build-Artefakte und benötigte Caches separat. Nach einem Gerätewechsel muss Ihr Team den Runner erneut verbinden und die Umgebung wiederherstellen.

Ablauf bei einem Gerätewechsel
Dedizierter physischer Mac

Der gesamte Mac mini ist Ihrem Team vorbehalten

Keine VM und keine Aufteilung mit anderen Kunden. Diese vier Punkte zeigen die wichtigsten Unterschiede zwischen einem dedizierten physischen Mac und einem Shared-Angebot.

Dediziert

Das gesamte Gerät für ein Team

Der Server ist Ihrem Konto zugeordnet und wird während der Mietdauer keinem zweiten Team zugewiesen. Mehrere Entwickler und Pipelines können ihn innerhalb Ihres Teams nutzen.

Physischer Server

Keine VM

Builds laufen direkt auf einem physischen Apple-Silicon-Server. Die macOS-Oberfläche und die Kommandozeile stehen vollständig zur Verfügung; Tools und Abhängigkeiten verwalten Sie passend zu Ihrem Projekt.

OSXPort-RingstationslogoOSXPort1 Server · 1 Team
Caches

Caches bleiben erhalten

DerivedData-, CocoaPods- und SPM-Caches werden nicht durch Aufgaben anderer Kunden gelöscht. Richten Sie dennoch eine Bereinigungsstrategie ein, damit Archive und Caches die SSD nicht füllen.

Parallelität

Keine CPU-Konkurrenz mit anderen Kunden

Wenn main und release gleichzeitig bauen, teilen sie Ressourcen nur mit Aufgaben Ihres Teams. Dediziert bedeutet nicht unbegrenzte Parallelität: Simulatoren und Compiler-Aufgaben nutzen weiterhin die Kapazität desselben Geräts.

Anleitung zur Anbindung eines dedizierten Servers
Apple Silicon M4 / M4 Pro

M4 oder M4 Pro: passend zur Projektgröße wählen

Zwei Chips in drei Serverkonfigurationen. Für einzelne Apps zunächst den M4 testen; bei großen Projekten mit mehreren Targets, mehr parallelen Tests oder lokaler Modellinferenz den M4 Pro mit 64 GB prüfen.

Apple Silicon M4

Für Port M4 Base und Port M4 Plus

Chip
Apple Silicon M4
Unified Memory
16 GB / 24 GB
Speicher
256 GB / 512 GB SSD

M4 passt für

  • Einzelne Apps oder wenige Targets.
  • Alltägliche Builds, Archivierung und automatische Verteilung.
  • Begrenzte Simulatoranzahl und vorhandene inkrementelle Caches.

Nicht empfohlen für

  • Mehrere gleichzeitig laufende Simulatoren mit 16 GB.
  • Große Projekte mit dauerhaft hoher Parallelität und ohne Begrenzung der Aufgabenzahl.

Apple Silicon M4 Pro

Für Port M4 Pro

Chip
Apple Silicon M4 Pro
Unified Memory
64 GB
Speicher
2 TB SSD

Mehr Spielraum für

  • Große Projekte mit mehreren Targets und Schemes.
  • Parallele UI-Tests auf mehreren Simulatoren.
  • Lokale Modellinferenz und Quantisierungstests, passend zur verfügbaren Speicherkapazität.

Nicht nötig bei

  • Wenigen täglichen Builds einer einzelnen App.
  • Bedarf an mehreren GPUs oder spezieller Beschleunigerhardware.
Preise im Überblick

Drei Serverkonfigurationen ab $19.7/Tag

Jede Konfiguration bietet einen dedizierten physischen Mac mini in fünf Regionen. Die Tagesmiete eignet sich zum Testen Ihrer Pipeline, Monats- oder Quartalstarife für dauerhaft eingeplante nightly-Builds. Den aktuellen Status sehen Sie in Echtzeit in der Konsole.

Port M4 Base

Für gelegentliche Builds

Apple Silicon M4 · 16 GB Unified Memory · 256 GB SSD

$19.7/Tag

Für einzelne Apps und wenige Builds. Prüfen Sie zuerst Spitzenwerte für Speicherplatz und Arbeitsspeicher bei vollständigen Archiven.

Port M4 Base mieten

Port M4 Plus

Für regelmäßige parallele Builds

Apple Silicon M4 · 24 GB Unified Memory · 512 GB SSD

$40.3/Tag

Für die tägliche Entwicklung, Builds mehrerer Branches und Simulator-Tests. Richten Sie die Parallelität nach den Ergebnissen Ihrer Tests aus.

Port M4 Plus mieten

Abrechnung in USD · Unterstützte Zahlungsmittel: USDT-TRC20 und Visa / Mastercard / Amex (über Stripe). Welche Zahlungswege tatsächlich verfügbar sind, zeigt die Antwort des Backends.

Tarife vergleichen
5 Rechenzentrumsregionen

Wählen Sie den Server nahe bei Repository und Team

Berücksichtigen Sie den Standort Ihres Code-Repositories, der Paketquellen und des Ziels für Build-Artefakte – nicht nur den Ihres Teams. Die Preise sind in allen Regionen innerhalb einer Konfiguration gleich. Die Latenzangaben sind Richtwerte, keine Messung Ihrer Verbindung und keine Zusicherung.

SG

Singapur

SüdostasienRichtwert: 20–50 ms

Geeignet für Teams in Südostasien sowie Projekte, deren Code, Abhängigkeiten und Release-Prozesse überwiegend dort liegen.

Server in Singapur mieten → JP

Japan (Tokio)

OstasienRichtwert: 30–60 ms

Geeignet für Teams in Japan sowie Projekte mit Repository und Paketquellen in Ostasien, die Builds möglichst nah am Standort ausführen möchten.

Server in Tokio mieten → KR

Südkorea (Seoul)

NordostasienRichtwert: 30–50 ms

Geeignet für Teams in Südkorea und Workflows, bei denen Code und Artefakte überwiegend innerhalb des Landes übertragen werden.

Server in Seoul mieten → HK

Hongkong

Südchina und SüdostasienRichtwert: 20–40 ms

Geeignet für Teams in Südchina. Testen Sie vor der Auswahl gemeinsam den Repository-Zugriff, Paketdownloads und die Übertragung von Build-Artefakten.

Server in Hongkong mieten → US-W

Westen der USA

Westküste NordamerikasRichtwert: 25–35 ms

Geeignet für Teams an der nordamerikanischen Westküste sowie Projekte mit Repository, Paketquellen oder Artefakt-Ziel überwiegend im Westen der USA.

Server im Westen der USA mieten →
iOS-Builds ohne eigenen Mac

Windows- und Flutter-Teams: ipa-Dateien auf dem Server erstellen

Wie erstelle ich iOS-Builds unter Windows?

Schreiben Sie wie gewohnt Code unter Windows, committen Sie Ihre Änderungen und pushen Sie sie. Ein Runner auf dem dedizierten Server übernimmt den Build: Er lädt den Code herunter und erstellt mit xcodebuild oder fastlane gym eine ipa-Datei. Anschließend wird das Artefakt an Ihre Pipeline zurückgegeben. Sie benötigen keinen Mac als Entwicklungsrechner.

Brauche ich für Flutter-iOS-Builds einen Mac?

Sie benötigen eine macOS-Build-Umgebung, aber keinen Mac im Büro. Installieren Sie Flutter, Xcode und die Projektabhängigkeiten auf dem Server. Dann führen Sie flutter build ipa remote aus und signieren den Build mit Ihren importierten Zertifikaten und Provisioning-Profilen.

Voraussetzung für die Signierung:Sie benötigen weiterhin eine gültige Mitgliedschaft im Apple Developer Program und müssen Zertifikate, Provisioning-Profile und einen App Store Connect API Key selbst bereitstellen. Der gemietete Server stellt die Build-Umgebung bereit, ersetzt aber nicht diese Voraussetzungen für die Veröffentlichung.

Anleitung: Windows- und Flutter-Teams anbinden
  1. 1

    Code unter Windows pushen

    Behalten Sie Ihre vorhandene Entwicklungsumgebung bei und pushen Sie Änderungen in das Team-Repository.

    git push origin main
  2. 2

    Runner auf dem Server übernimmt den Auftrag

    Registrieren Sie einen selbst gehosteten Runner und leiten Sie macOS-Aufgaben per Label an den passenden Server weiter. Legen Sie für Aufgaben Ihres Teams eine angemessene Parallelität fest.

    runs-on: [self-hosted, macOS, osxport]
  3. 3

    ipa erstellen und signieren

    Importieren Sie Zertifikate und Provisioning-Profile und konfigurieren Sie die Signierung. Speichern Sie Geheimnisse in sicheren CI-Variablen, nicht im Code-Repository.

    flutter build ipa --release
  4. 4

    Auf TestFlight hochladen

    Richten Sie den automatischen Upload mit einem App Store Connect API Key ein und geben Sie Fehlermeldungen sowie den Speicherort der Artefakte an die Pipeline zurück.

    fastlane pilot upload
Beispielszenarien

Drei Teams, drei Pipelines

Die folgenden fiktiven Erfahrungsberichte veranschaulichen typische Einsatzfälle. Es handelt sich weder um Bewertungen namentlich genannter Kunden noch um Ergebnisse von Leistungstests.

Beispielszenario

Nächtliche Builds für ein fünfköpfiges Agenturteam

2 Uhr morgensZeitplan für nightly-Builds

„Früher stand unser Build-Mac im Büro. Wenn am Wochenende der Strom abgeschaltet wurde, mussten wir die Aufgaben neu planen. Jetzt laufen die nightly-Builds auf einem Server in Singapur; Code und Berichte gehen zurück in unsere bestehende Pipeline. Niemand im Team muss mehr abwechselnd auf das Gerät aufpassen.“

Muss Ihr Projekt auf Geräte im Firmennetz zugreifen, prüfen Sie zuerst, ob die Remote-Verbindung dafür geeignet ist.

Port M4 Base · $98.5/Monat

Beispielszenario

Flutter-Builds ohne eigenen Mac

0eigene Macs

„Unser ganzes Team entwickelt Flutter unter Windows. Nach dem Push erstellt der Server in Tokio die ipa-Datei und lädt sie auf TestFlight hoch. Wir verwalten die Signiermaterialien selbst und prüfen bei Fehlern zuerst die CI-Protokolle – statt spontan einen Mac auszuleihen.“

Remote-Builds ersetzen kein lokales Debugging auf echten Geräten. Tests mit Geräteinteraktionen müssen separat geplant werden.

Port M4 Base · ab $19.7/Tag

Beispielszenario

Parallele Builds in der Release-Woche

3Branches in der Warteschlange

„Für main, release und hotfix müssen Builds erstellt werden. Leichte Aufgaben führen wir parallel aus, speicherintensive Tests nacheinander. Auf dem dedizierten Server laufen nur unsere eigenen Aufgaben; wir müssen nicht warten, bis andere Kunden Ressourcen freigeben.“

Messen Sie zuerst den maximalen Arbeitsspeicherbedarf und die Archivierungsdauer, bevor Sie die Parallelität festlegen. Drei Branches bedeuten nicht, dass drei vollständige Builds gleichzeitig laufen müssen.

Port M4 Plus · $201.6/Monat

Weitere Workflow-Beispiele ansehen
Häufige Fragen

Fragen vor dem Start

Noch unsicher, ob sich die Miete lohnt? Fragen Sie mit Angaben zu Teamgröße, Builds pro Tag, Dauer der Archivierung und wichtigsten Release-Regionen an. Wenn Sie ungenutzte Hardware haben und selten Builds erstellen, empfehlen wir Ihnen ehrlich, zunächst beim Eigenbetrieb zu bleiben.

Beratung zur Pipeline-Auswahl
Gibt es wirklich keine geplanten Ausfallzeiten?

Der Server läuft ganzjährig 365 Tage im Rechenzentrum. Hardwareausfälle können Aufgaben dennoch beeinträchtigen. Melden Sie sich in der Konsole an und erstellen Sie ein Support-Ticket mit Server, Fehlerbeschreibung und den letzten Änderungen. Wir unterstützen Sie bei der Fehlersuche und einem Gerätewechsel. Die Betriebsplanung ist kein Nachweis für eine störungsfreie Vergangenheit.

Kann ich Homebrew selbst installieren und die Xcode-Version auswählen?

Sie können Homebrew, Xcode und Projektabhängigkeiten passend zu Ihrer Pipeline verwalten. Prüfen Sie vor einem Xcode-Wechsel die Anforderungen von SDK und Projekt und halten Sie Tool-Versionen in Ihren Build-Protokollen fest. Lassen Sie nicht mehrere Aufgaben gleichzeitig dieselbe globale Umgebung ändern.

Ab wann lohnt sich der Monatstarif statt der Tagesmiete?

Teilen Sie den Monatspreis durch den Tagespreis, um die Kosten zu vergleichen. Port M4 Base kostet $19.7 pro Tag und $98.5 pro Monat. Laut Preisliste entsprechen fünf Tageszeiträume dem Preis eines Monatszeitraums. Wenn Sie den Server voraussichtlich länger nutzen, ist der Monatstarif die bessere Wahl. Prüfen Sie Laufzeit und Verlängerungsbedingungen beim Bestellen.

Welche Zahlungsmittel werden akzeptiert?

Die Abrechnung erfolgt ausschließlich in US-Dollar (USD). Unterstützt werden nur USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe). Maßgeblich sind die beim Bezahlvorgang vom Backend angezeigten verfügbaren Zahlungswege. Prüfen Sie vor der Zahlung Bestellung, Betrag und Zahlungsnetzwerk.

Kann ein Server von mehreren Personen genutzt werden?

Ja. Mehrere Entwickler und Pipelines Ihres Teams können denselben Server nutzen; anderen Kunden wird er nicht zugewiesen. Trennen Sie Build-Verzeichnisse, Signiermaterialien und Runner-Berechtigungen und begrenzen Sie gleichzeitig laufende Compiler- und Simulator-Aufgaben.

Build-Notizen

Auswahl und Einrichtung als wiederverwendbare Dokumentation festhalten

Von der Kostenabwägung bis zur Build-Umgebung: In unseren Artikeln finden Sie die Punkte, die regelmäßig geprüft werden müssen – damit Ihr Team sie vor der Einrichtung gemeinsam durchgehen kann.

DevOps & CI/CD

Swift Union-Find auf einem Cloud-Mac testen

Eine ausführbare Swift-Implementierung mit unabhängiger Graphsuche zur Prüfung von Konnektivität, mehrfachen Vereinigungen und Komponentenzahlen.

 DevOps & CI/CD

iOS-Abhängigkeitsgraphen auf dem Cloud-Mac prüfen

Ein kleiner Swift-Test fixiert die Reihenfolge bereiter Aufgaben und prüft unbekannte Abhängigkeiten sowie durch Zyklen blockierte Knoten.

 DevOps & CI/CD

iOS-Bloom-Filter prüfen: Fehlalarme und Snapshot-Grenzen

Ein ausführbares Swift-Beispiel trennt garantierte Invarianten von Fehlalarmrate und Snapshot-Kompatibilität.
Nächster Schritt

Testen Sie Ihre Pipeline erst einmal einen Tag lang

Abrechnung pro Tag; Port M4 Base kostet $19.7/Tag. Verbinden Sie Ihren bestehenden Runner und testen Sie einen sauberen Build, einen inkrementellen Build und ein vollständiges signiertes Archiv. Entscheiden Sie anschließend, ob ein Monats- oder Quartalstarif besser passt.

Server einen Tag lang testenDrei Tarife vergleichen

Beispielrechnung · monatlich

Serverstandort
Tokio
Port M4 Plus
$201.6
+1 TB SSD
$12.9
Gesamt · USD
$214.5

Beispielrechnung für einen Monat: $201.6 + $12.9, ohne weitere Zusatzoptionen.

Zahlung: USDT-TRC20 oder Visa / Mastercard / Amex (über Stripe).