Erste Schritte

Vom Auftrag zum ersten iOS-Build – Schritt für Schritt

Wählen Sie den CDNMac M4 und einen passenden Standort aus. Nach dem Bezahlen rufen Sie die Zugangsdaten ab, sichern die Verbindung, prüfen die Xcode-Umgebung, führen ein Archive aus und übertragen die Build-Artefakte an einen kontrollierten Speicherort.

CDNMac M4 auswählen und bestellen Tarife und Preise prüfen

1 Konfiguration CDNMac M4, M4 / 16 GB / 256 GB

6 Standorte Asien-Pazifik und USA

6 Schritte Bestellen, bezahlen, verbinden, prüfen, bauen, automatisieren

BUILD-ÜBERGABE

Übergabe-Checkliste für den ersten Build

Ablauf bereit

Ressourcen wählen Mietdauer, Standort und Extras

Bestellung abschließen USD-Betrag und Zahlungsanbieter prüfen

Zugangsdaten abrufen Gerätestatus und Systemzugangsdaten

Zugriff absichern SSH-Schlüssel und VNC-Zugangsdaten getrennt verwalten

Umgebung prüfen macOS, Xcode, Git und Signierungsdaten

Build-Artefakte übergeben Archive, Logs und Exportdateien

Signatur prüfen Vor dem Build erledigen

Zugriffsprinzip Minimale Berechtigungen

Speicherort der Artefakte Kontrollierter Speicher

Gesamten Ablauf ansehen

In sechs Schritten startklar

Jeder Schritt hat klar definierte Ein- und Ausgaben. Importieren Sie keine Projektschlüssel, bevor die Zugangsdaten abgesichert sind, und starten Sie keine Produktions-Releases, bevor die Entwicklungsumgebung geprüft ist.

01
Mietdauer und Standort wählen

Richten Sie die Auswahl nach Auftragsdauer, Standort der Entwickler, Speicherort des Repositorys und Downloadpfad für Abhängigkeiten aus. Ein einzelner Latenztest ist nur ein Anhaltspunkt und ersetzt keinen echten Build-Test.
Ergebnis: Bestellentwurf
02
Bestellung abschließen und bezahlen

Prüfen Sie CDNMac M4, Abrechnungszeitraum, Standort, SSD-Erweiterung und Anzahl der Thunderbolt-5-Verbindungen noch einmal. Maßgeblich ist der Betrag, der im Checkout angezeigt wird.
Ergebnis: Bestell-ID
03
Verbindungsdaten abrufen

Prüfen Sie im Kontrollpanel den Gerätestatus, die Systemzugangsdaten und den Administrationszugang. Verfügbarkeit und Übergabeinformationen richten sich nach den aktuellen Angaben im Kontrollpanel.
Ergebnis: überprüfbare Zugangsdaten
04
Remotezugriff absichern

Verwenden Sie bevorzugt SSH-Schlüsselauthentifizierung und beschränken Sie zulässige Quelladressen. Verwalten Sie Zugangsdaten für die Kommandozeile und grafische Sitzungen getrennt nach Einsatzzweck und dokumentieren Sie, wer für den Wechsel der Zugangsdaten zuständig ist.
Ergebnis: kontrollierter Zugriffsweg
05
Entwicklungsumgebung prüfen

Stellen Sie sicher, dass macOS, Xcode, Command Line Tools, Git, Zertifikate und Provisioning-Profile den Projektanforderungen entsprechen. Stellen Sie erst danach die Abhängigkeiten wieder her.
Ergebnis: dokumentierte Umgebungsprüfung
06
Build ausführen und übergeben

Führen Sie ein Archive des Test-Repositorys aus, prüfen Sie Signierung, Logs und Exportdateien und kopieren Sie die erforderlichen Artefakte an einen vom Team kontrollierten Speicherort.
Ergebnis: erster nachvollziehbarer Build

Vor der Bestellung prüfen

Diese sieben Punkte sollten geklärt sein

Diese Checkliste hilft, nach der Bestellung Konfigurationsänderungen und Rückfragen zu vermeiden. Für jeden Punkt sollte die Projektverantwortung eine eindeutige Antwort geben.

01 Einsatzzweck festgelegt

Klären Sie, ob es um automatisierte iOS-Builds, macOS-Entwicklung und -Tests, plattformübergreifende Mobile-Builds oder Kompatibilitätstests für Apple-Silicon-Modelle geht.

02 Standort ausgewählt

Wählen Sie Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong, die US-Ostküste oder die US-Westküste und dokumentieren Sie Ihre Gründe.

03 Mietdauer geprüft

Tagesmiete für kurzfristige Tests, Wochenmiete für kurze Sprints und Monats- oder Quartalsmiete für fortlaufende Builds. Vergleichen Sie nicht nur einzelne Preisangaben.

04 Speicherbedarf geklärt

Die Basiskonfiguration umfasst eine 256-GB-SSD. Schätzen Sie den Spitzenbedarf für Quellcode, Abhängigkeits-Caches, DerivedData, Archive und Logs ab, bevor Sie die SSD erweitern.

05 Parallelbetrieb erforderlich

Prüfen Sie Thunderbolt 5 für den Parallelbetrieb nur, wenn Ihr Geräte-Workflow dies erfordert. Klären Sie auch Anzahl und Zuständigkeiten für jedes Gerät.

06 Codezugriff vorbereitet

Richten Sie einen Repository-Zugriff mit minimalen Berechtigungen ein. Verwenden Sie keine persönlichen, langfristig gültigen Tokens wieder und speichern Sie weder private Schlüssel noch Tokens oder Zertifikatspasswörter im Repository.

07 Export der Artefakte geplant

Legen Sie vorab fest, wo Archive, Exportpakete, Symboldateien und Build-Logs abgelegt werden. Planen Sie den Datenexport vor Ende der Mietdauer ein.

Bestellung erstellen

Eine Konfiguration, flexibel bei Mietdauer, Standort und Extras

Aktuell ist eine Konfiguration mit exklusivem physischem Rechner verfügbar. Jede Bestellung umfasst einen eigenen Cloud-Mac, dessen Ressourcen nicht mit anderen Bestellungen geteilt werden. Es handelt sich nicht um eine virtuelle Maschine.

6 Standorte zur Auswahl

CDNMac M4

Mac mini M4 für iOS-Builds, macOS-Entwicklung und -Tests sowie CI-Aufgaben.

Einstiegspreis pro Tag $19.9

M4 16 GB RAM 256 GB SSD

Pro Tag $19.9

Pro Woche $53.6

Pro Monat $99.3

Pro Quartal $270.1

Sechs Standorte zur Auswahl

Singapur Japan (Tokio) Südkorea (Seoul) Hongkong US-Ostküste US-Westküste

Verfügbarkeit, Bereitstellungszeit und Auswahl zusätzlicher Optionen richten sich nach den aktuellen Angaben im Kontrollpanel.

CDNMac M4 konfigurieren Sechs Standorte vergleichen

+1 TB SSD

Für länger laufende Entwicklungsaufgaben mit größeren Abhängigkeits-Caches, Archives und Build-Logs.

Pro Tag: $2.6
Pro Woche: $7.1
Pro Monat: $13.2
Pro Quartal: $35.9

+2 TB SSD

Für umfangreiche Abhängigkeiten, Datensätze und Modelldateien oder wenn Artefakte länger gespeichert werden müssen.

Pro Tag: $5.2
Pro Woche: $14.2
Pro Monat: $26.4
Pro Quartal: $71.8

Thunderbolt 5 für Parallelbetrieb

Abrechnung pro Gerät. Für geprüfte parallele Geräte-Workflows; die Basiskonfiguration bleibt unverändert.

Pro Tag: $1.8
Pro Woche: $4.8
Pro Monat: $8.8
Pro Quartal: $23.9

Bezahlen

Vor dem Checkout: zwei Zahlungsarten

Alle Preise und Bestellungen werden in US-Dollar (USD) abgerechnet. Welche Zahlungsanbieter verfügbar sind, geht aus der Backend-Schnittstelle hervor.

USDT-TRC20

Prüfen Sie vor der Zahlung Bestellbetrag, Netzwerk und Empfängerdaten. Bewahren Sie nach der Überweisung die nötige Transaktions-ID auf, damit sie der Bestellung zugeordnet und bei der Abrechnung geprüft werden kann.

Abrechnungswährung: USD

Visa / Mastercard / Amex

Kartenzahlungen werden über Stripe abgewickelt. Prüfen Sie Rechnungsdaten und Bestellbetrag, bevor Sie die Zahlung autorisieren. Geben Sie vollständige Zahlungsdaten nicht in Supportanfragen an.

Zahlungsanbieter: Stripe

Letzte Prüfung vor der Zahlung

Modell, Mietdauer, Standort, SSD-Erweiterung, Anzahl der Parallelverbindungen und Gesamtbetrag in USD müssen dem vom Projektteam bestätigten Bestellentwurf entsprechen.

Gerätedaten abrufen

Erst das Gerät prüfen, dann Projektdaten importieren

Nach Abschluss der Bestellung finden Sie im Kontrollpanel den Gerätestatus, die Systemzugangsdaten und den Administrationszugang. Prüfen Sie bei der ersten Verbindung zunächst die Identität und die Umgebung. Importieren Sie noch keine produktiven Schlüssel.

GERÄTEÜBERGABE

Checkliste für Verbindungsdaten

Punkt für Punkt prüfen

Bestell-ID Mit den Projektdaten abgleichen

Standort Mit der Bestellung abgleichen

Gerätestatus Aktuelle Angaben im Kontrollpanel sind maßgeblich

Systemzugangsdaten Nur an autorisierte Teammitglieder weitergeben

Administrationszugang Erst nach erfolgreicher Prüfung fortfahren

Erste Änderungen Änderbare Zugangsdaten ersetzen

Vier Schritte nach der ersten Anmeldung

Änderbare Zugangsdaten ersetzen.
Autorisierte Teammitglieder und Verantwortliche für Zugangsdaten dokumentieren.
Zulässige Quelladressen für den Fernzugriff einschränken.
Vor Mietende eine Checkliste zur Rücknahme der Projektdaten erstellen.

Anleitung zur Fehlerbehebung bei Verbindungen

Verbindung absichern

SSH für Automatisierung, VNC für grafische Bedienung

Beide Verbindungsarten können parallel genutzt werden. Zugangsdaten, Berechtigungsumfang und Einsatzzweck müssen jedoch getrennt verwaltet werden. Betten Sie langfristig gültige Schlüssel nicht in Skripte oder Build-Logs ein.

Kommandozeile

Zugriff per SSH-Schlüssel

Geeignet für Git, Abhängigkeitsauflösung, Skriptausführung, Logsammlung, Archive und self-hosted Runner. Verwenden Sie bevorzugt separate Schlüssel und gewähren Sie jeder Automatisierungsaufgabe nur die nötigen Berechtigungen.

Prüfen Sie die Host-Informationen, bevor Sie die Verbindungsdaten speichern.
Beschränken Sie zulässige Quelladressen oder Netzbereiche.
Trennen Sie Schlüssel für interaktive Anmeldungen von Automatisierungsschlüsseln.
Tauschen Sie Zugangsdaten regelmäßig aus und entziehen Sie nicht mehr benötigte Berechtigungen.

Grafische Sitzung

Grafische Sitzung per VNC

Geeignet für die erste Xcode-Prüfung, grafische Einstellungen, Entwicklungstools mit Oberfläche und die Kontrolle von Archives. Eine grafische Sitzung ist kein Grund, Zugangsdaten gemeinsam zu nutzen.

Zugriff nur Teammitgliedern gewähren, die eine grafische Oberfläche benötigen.
Beenden Sie nach der Sitzung sensible Tools und schließen Sie nicht benötigte Fenster.
Achten Sie darauf, dass Schlüssel und Zertifikatspasswörter nicht in Screenshots oder Bildschirmaufnahmen erscheinen.
Für die Automatisierung über die Kommandozeile weiterhin separate SSH-Zugangsdaten verwenden.

Entwicklungsumgebung prüfen

Umgebungsunterschiede nachvollziehbar dokumentieren

Es reicht nicht, nur zu prüfen, ob sich Xcode öffnen lässt. Dokumentieren Sie Version, Pfade, Status der Signierungsdaten und freien Speicherplatz, damit sich spätere Fehler auf konkrete Änderungen zurückführen lassen.

Checkliste für die Umgebung vor dem ersten iOS-Build
Prüfpunkt	Empfohlene Prüfung	Kriterien für bestanden	Erste Schritte bei Problemen
macOS	Systemversion und freien Speicherplatz dokumentieren	Erfüllt die Anforderungen der Projekt-Toolchain; genug Platz für Abhängigkeiten, Caches und Archive	Nicht benötigte Caches entfernen und SSD-Kapazität neu bewerten
Xcode	Erforderliche Hauptversion und aktuell ausgewählten Pfad prüfen	Projekt lässt sich öffnen; Ziel-SDK und Build-Einstellungen sind verfügbar	Richtige Version auswählen und Projekt erneut auflösen
Command Line Tools	`xcode-select -p`	Der Pfad verweist auf die vorgesehene Xcode-Toolchain	Ausgewählten Pfad korrigieren und anschließend die Befehlsversion prüfen
Git	`git --version` und Zugriff auf ein Repository mit minimalen Berechtigungen testen	Test-Repository ist lesbar, ohne langfristig gültige Zugangsdaten offenzulegen	Schlüsselberechtigungen, Quellbeschränkungen und Repository-Zugriff prüfen
Zertifikate und Provisioning-Profile	Namen, Zweck, Gültigkeit und Projektkennung prüfen	Passend zum Testziel; keine unnötigen Daten importiert	Projektverantwortliche um die korrekten Daten bitten
Abhängigkeitssperrdatei	Sicherstellen, dass die Sperrdatei eingecheckt ist und zum Ziel-Branch passt	Abhängigkeiten lassen sich reproduzierbar wiederherstellen; keine unbemerkten Upgrades	Zum Commit mit passender Sperrdatei zurückkehren und Abhängigkeiten erneut wiederherstellen

Befehle für die erste Bestandsaufnahme Liest die Umgebung aus, ohne das Projekt zu ändern

sw_vers
xcodebuild -version
xcode-select -p
git --version
df -h

Ersten Build ausführen

Zuerst den gesamten Ablauf mit einem Test-Repository prüfen

Ziel des ersten Durchlaufs ist noch kein Release. Prüfen Sie, ob Codezugriff, Wiederherstellung der Abhängigkeiten, Archive, Signaturprüfung, Logaufbewahrung und Artefaktexport einen vollständigen Ablauf bilden.

01 Test-Repository klonen

Klonen Sie mit Zugangsdaten mit minimalen Berechtigungen einen bekanntermaßen baubaren Commit. Dokumentieren Sie Commit-Hash und Ziel-Branch.
git clone <Repository-URL>
02 Abhängigkeiten wiederherstellen

Stellen Sie Abhängigkeiten anhand der Sperrdatei des Projekts wieder her. Wenn CocoaPods, Flutter oder andere Tools benötigt werden, dokumentieren Sie zunächst deren Version und führen Sie sie dann aus.
Sperrdatei und Ziel-Commit müssen übereinstimmen
03 Archive ausführen

Geben Sie workspace, scheme, configuration und archivePath ausdrücklich an, statt sich auf implizite Standardwerte der grafischen Oberfläche zu verlassen.
xcodebuild archive -workspace App.xcworkspace -scheme App -archivePath build/App.xcarchive
04 Signierung prüfen

Prüfen Sie, ob Bundle-ID, Zertifikate, Provisioning-Profile und Exportoptionen zum Testauftrag passen. Ignorieren Sie keine Signierungswarnungen.
Ergebnis der Signierungsprüfung und Fehlerphase dokumentieren
05 Logs sichern

Bewahren Sie Start- und Endzeit, Commit-Hash, Tool-Versionen und fehlgeschlagene Schritte auf. Entfernen Sie vor dem Teilen der Logs Tokens, sensible Namen in Pfaden und Zertifikatspasswörter.
Logs müssen Bestellung, Standort und Commit zugeordnet werden können
06 Artefakte exportieren

Kopieren Sie Archive, Exportdateien und erforderliche Symboldateien an einen vom Team kontrollierten Speicherort. Prüfen Sie Dateiintegrität und Zugriffsrechte.
Arbeitsbereich erst nach dem Export bereinigen

Automatisierung einrichten

Aus einem erfolgreichen Build einen wartbaren Runner machen

Registrieren Sie den exklusiven physischen Rechner erst nach erfolgreicher manueller Prüfung als self-hosted Runner. Automatisierungszugangsdaten, Arbeitsverzeichnisse und Bereinigungsregeln sollten je Repository getrennt verwaltet werden.

Runner registrieren

Wählen Sie einen eindeutigen Namen für den Runner und dokumentieren Sie Standort, Projektumfang und verantwortliche Person. Führen Sie zuerst einen schreibgeschützten Testauftrag aus und geben Sie Build-Berechtigungen erst danach frei.

Dokumentieren: Name, Standort, Repository, Verantwortliche

Token-Berechtigungen einschränken

Gewähren Sie einem Token nur die Repository- und Aktionsberechtigungen, die für den aktuellen Auftrag nötig sind. Speichern Sie es weder im Quellcode noch in Cache-Verzeichnissen, Build-Logs oder herunterladbaren Artefakten.

Grundsatz: ein Auftrag, ein Satz minimaler Berechtigungen

Arbeitsbereich isolieren und bereinigen

Verwenden Sie für jedes Repository ein eigenes Verzeichnis. Legen Sie fest, welche Caches wiederverwendet werden dürfen, welche Artefakte exportiert werden müssen und wie nach erfolgreichen, fehlgeschlagenen oder abgebrochenen Aufträgen bereinigt wird.

Vorgehen: Repositorys isolieren, Caches klassifizieren, Fehlerdaten bereinigen

Aufbewahren

Commit-Hash, Tool-Versionen, Start- und Endzeit des Auftrags, Ergebnis der Abhängigkeitsauflösung, Archive-Pfad und Prüfinformationen der Artefakte.

Nicht in Logs speichern

Private Schlüssel, Zugriffstokens, Zertifikatspasswörter, vollständige Zahlungsdaten und sensible Projektinhalte, die für die Fehlerbehebung nicht erforderlich sind.

Vor Mietende

Erforderliche Artefakte exportieren, Automatisierungstokens widerrufen, Repository-Zugangsdaten entfernen und sicherstellen, dass in Arbeitsverzeichnissen und Caches keine Projektdaten zurückbleiben.

Jetzt starten

CDNMac M4 auswählen und die Übergabe-Checkliste Schritt für Schritt abarbeiten

Legen Sie vor der Bestellung Mietdauer, einen der sechs Standorte und benötigte Extras fest. Sichern Sie nach der Bestellung zuerst den Zugriff ab und prüfen Sie dann Xcode und das erste Archive.

CDNMac M4 jetzt mieten Nutzungssupport anfordern