Schreibe deinen Code weiter unter Windows und überlasse Builds, für die macOS nötig ist, einem Cloud-Mac. Miete tageweise und starte noch am selben Tag nach der Zahlung – ohne für ein kurzes Projekt gleich einen Mac kaufen zu müssen.
Du kannst den Mac noch am selben Tag nutzen. Ob auch der Build klappt, hängt davon ab, ob Abhängigkeiten, Xcode-Version und Signaturmaterial bereitstehen. Prüfe zuerst diese sechs Punkte und folge dann dem Ablauf für dein Framework.
Mac Mini M4: $20.2 pro Tag. Exklusiver physischer Mac, keine VM. Nach Projektende endet der Dienst zum Laufzeitende, wenn du nicht verlängerst.
Jetzt mieten: Der Code ist verfügbar, das Signaturmaterial autorisiert und der Build steht kurz bevor. Noch nicht starten: Bundle-ID oder Zuständigkeit für die Signatur sind mit dem Kunden ungeklärt – dann wartet der Mac nur ungenutzt.
Unterscheide zwischen Build, Integrationstests und Vorbereitung der Veröffentlichung. Halte Zielversion, Bundle-ID, Build-Methode und Empfänger fest. Eine einmalige Archivierung stellt andere Anforderungen an die Mietdauer als mehrere Tage Integrationstests.
Zur Wahl stehen Singapur, Tokio, Seoul und Hongkong. Orientiere dich am Netzwerk des Teams, das sich regelmäßig mit dem Mac verbindet. Wenn häufig Dateien übertragen werden, berücksichtige auch den Übertragungsweg. Ein naher Standort garantiert nicht für jede Verbindung dieselbe Leistung – maßgeblich ist das verwendete Netzwerk.
Abrechnung pro Tag, Woche, Monat oder Quartal. Mac Mini M4: $20.2 pro Tag, $54.6 pro Woche, $101.1 pro Monat oder $275 pro Quartal. Bei drei oder mehr Tagen am Stück ist der Wochentarif günstiger als die Tagesabrechnung. Wenn der Zeitplan noch nicht feststeht, vergleiche zuerst die Laufzeiten und bezahle danach.
Akzeptiert werden ausschließlich USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe). Abgerechnet wird alles in US-Dollar (USD). Welche Zahlungswege tatsächlich verfügbar sind, hängt von der Rückmeldung des Backend-Gateways ab. Prüfe beim Bezahlen den Bestellbetrag und die angezeigten Hinweise – verwende keine Angaben aus einer früheren Bestellung.
Lass dir von der Projektleitung die Berechtigung für die Entwicklersignatur bestätigen und halte das passende Zertifikat, den privaten Schlüssel und das Provisioning-Profil bereit. Eine Zertifikatsdatei allein reicht nicht zum Signieren. Prüfe Gültigkeit, Teamzugehörigkeit, Bundle-ID und Exportzweck. Übertrage das Material über einen geschützten Kanal und lege es nicht in einem öffentlichen Repository ab.
Bestimme eine verantwortliche Person für das Ende der Mietdauer. Ohne Verlängerung endet der Dienst zum Laufzeitende; eine Kündigungsgebühr fällt nicht an. Das ist kein Ersatz für ein Backup. Plane Zeit für den Export, die Kundenabnahme und mögliche Änderungen am Build ein und verlängere erst, wenn der neue Zeitraum feststeht.
Beide Optionen bieten einen exklusiven physischen Mac mini. Wähle die Ausstattung passend zur Projektlast und entscheide dich anschließend für Standort und Laufzeit. Für einen gelegentlichen Build ist nicht automatisch das größere Modell nötig.
M4 / 16 GB RAM / 256 GB SSD
Geeignet für kleinere native Projekte, übliche Flutter-Builds und kurze Integrationsphasen. Prüfe den gesamten Speicherbedarf von Quellcode, Abhängigkeiten, Simulatoren und Archiven – nicht nur die Größe des Repositorys.
Weniger geeignet, wenn große Mediendateien, mehrere umfangreiche Projekte und sämtliche älteren Archive dauerhaft auf demselben Mac liegen sollen.
$20.2 pro Tag · $54.6 pro Woche
$101.1 pro Monat · $275 pro Quartal
M4 Pro / 64 GB RAM / 2 TB SSD
Geeignet für umfangreiche Unity-Exportprojekte, Builds mit mehreren Targets und anspruchsvollere Abhängigkeiten. Mehr Arbeitsspeicher und Speicherplatz schaffen Raum für komplexe Projekte, garantieren aber keinen festen Geschwindigkeitszuwachs für jedes Vorhaben.
Weniger geeignet, wenn du nur gelegentlich ein kleines Projekt kompilierst und die meiste Zeit auf die Freigabe durch den Kunden wartest.
$59.3 pro Tag · $160 pro Woche
$296.3 pro Monat · $805.9 pro Quartal
Wähle auf der Bestellseite Modell, Standort und Abrechnungszeitraum. Füge zusätzlichen Speicher nur bei Bedarf hinzu. Prüfe vor dem Absenden die gesamte Konfiguration und den Gesamtbetrag. Ob die Option verfügbar ist, zeigt die Konsole in Echtzeit an.
Bezahle nach den Anweisungen des gewählten Gateways und prüfe anschließend den Bearbeitungsstatus in der Bestellung. Zahlung und Bestellstatus müssen übereinstimmen. Bei Abweichungen sende ein Ticket mit Bestellnummer und Zahlungsbeleg.
Die Freischaltung erfolgt noch am selben Tag nach der Zahlung. Öffne in der Konsole die Details der betreffenden Instanz, um Verbindungsdaten und Ablaufzeit einzusehen. Übernimm keine Adresse und Zugangsdaten aus alten Einträgen eines anderen Macs.
Prüfe zuerst per Remote-Desktop die grafische Oberfläche, den Speicher und Xcode. Führe Build-Befehle anschließend per SSH aus. Beide Verbindungsarten führen zum selben physischen Mac, nicht zu zwei getrennten Umgebungen.
Melde dich in der Konsole an und öffne die Details der betreffenden Instanz. Verwende die dort angegebenen Verbindungsmethoden, Adressen und Zugangsdaten. Prüfe beim ersten Zugriff die Mac-Nummer und anschließend die grafische macOS-Oberfläche, den verfügbaren Speicher und das Projektverzeichnis.
Wenn du Signatureinstellungen in Xcode ändern, Simulatoren prüfen oder grafische Hinweise bearbeiten musst, ist der Remote-Desktop übersichtlicher. Teile Zugangsdaten nicht in Gruppenchats und bearbeite ein Build-Verzeichnis nicht gleichzeitig mit mehreren Personen.
Nutze in einem Windows-Terminal einen SSH-Client. Adresse, Port, Benutzername und Authentifizierungsmethode findest du in den Instanzdetails. Prüfe beim ersten Verbinden den Hostschlüssel. Wenn eine Änderung der Hostidentität gemeldet wird, kläre zuerst die Ursache und ignoriere die Meldung nicht einfach.
Eine erfolgreiche SSH-Anmeldung bedeutet nicht, dass die Signatur funktioniert. Prüfe außerdem den aktuellen Benutzer, den Schlüsselbundzugriff, den Pfad zu den Build-Tools und die Projektabhängigkeiten. Automatisierte Aufgaben müssen ebenfalls in der Umgebung des betreffenden Benutzers getestet werden.
Prüfe zuerst, welche Xcode- und SDK-Version das Projekt erfordert. Ist bereits eine passende Version installiert, musst du sie nicht erneut installieren. Fehlen Tools, richte zunächst Xcode und die Kommandozeilenwerkzeuge ein und erledige die erforderlichen Schritte beim ersten Start in der grafischen Oberfläche.
Mit den folgenden beiden Befehlen prüfst du den Pfad der Entwicklerwerkzeuge und die Xcode-Version. Stelle sicher, dass die Ausgabe den Projektanforderungen entspricht, bevor du Abhängigkeiten wiederherstellst. Beginne nicht mit der Fehlersuche im Code, nur weil sich Xcode im Programme-Ordner befindet.
Im Terminal des Cloud-Mac ausführen
xcode-select --print-path
xcodebuild -versionStimmen Version oder Pfad nicht, wechsle zuerst anhand des tatsächlichen Installationsorts das Tool und prüfe anschließend erneut. Übernimm nicht einfach den Installationspfad eines anderen Macs.
Erstelle zuerst einen Build aus einem eindeutig festgelegten Commit und integriere ihn erst danach in den täglichen Ablauf. Prüfe bei allen drei Vorgehensweisen Abhängigkeiten, Signaturmaterial und Exportzweck. Ein erfolgreicher Build allein bedeutet noch nicht, dass alles übergabefertig ist.
Wenn die Signierung fehlschlägt, prüfe zuerst, ob Zertifikat und Provisioning-Profil zusammenpassen. Lösche nicht wiederholt den gesamten Projekt-Cache.
Verwende die für das Projekt festgelegte Flutter-Version, wechsle in das Projektstammverzeichnis und prüfe die Toolchain, bevor du Abhängigkeiten wiederherstellst und den Build erstellst:
flutter doctor -v
flutter pub get
flutter build ipa --releaseWenn das Projekt Flavors, einen eigenen Einstiegspunkt oder Exportoptionen verwendet, ergänze die Parameter gemäß der vorhandenen Build-Anleitung. Betrachte den Standardbefehl nicht als endgültige Konfiguration für jedes Projekt.
Sobald die Toolchain-Prüfung erfolgreich ist, kümmere dich um Signierung und native Abhängigkeiten im iOS-Projekt. Prüfe den IPA-Pfad in der Build-Ausgabe und das Exportergebnis.
Verwalte Umgebungsvariablen und Kundenschlüssel getrennt. Schreibe keine Produktivkonfigurationen in Protokolle und übertrage sie nicht ins Repository.
Ein exklusiver Mac bedeutet, dass ein Mietkunde den physischen Mac allein nutzt. Mehrere Projekte derselben Agentur werden dadurch nicht automatisch voneinander getrennt. Bei wechselnder Nutzung müssen Konten, Schlüsselbunde und Build-Verzeichnisse ebenfalls getrennt bleiben.
Wenn mehrere kleine Projekte nicht gleichzeitig übergeben werden, kannst du für jeden Kunden ein eigenes macOS-Benutzerkonto anlegen und dort Projekt, Schlüsselbund und Build-Protokolle getrennt aufbewahren. Prüfe beim Aufgabenwechsel den aktuellen Benutzer und verwende keinen unübersichtlichen Download-Ordner gemeinsam.
Dafür musst du Aufgaben einplanen und den Wechsel manuell verwalten. Die Konten befinden sich weiterhin auf demselben Mac. Diese Lösung ersetzt nicht automatisch die vom jeweiligen Kunden verlangte Trennung.
Wenn mehrere Kunden in derselben Woche Builds benötigen oder der Vertrag eine klarere Trennung der Umgebungen verlangt, miete für jeden Kunden einen eigenen physischen Mac. Benenne die Macs nach Kunde und Projekt und bewahre Zertifikate, private Schlüssel, Code und Archive auf den jeweiligen Macs auf.
Der Nachteil: Jeder Mac wird separat abgerechnet. Auch bei getrennten Umgebungen musst du Zugriffsrechte kontrollieren, Backups aufbewahren und für jeden Mac eine verantwortliche Person für Verlängerung und Mietende festlegen.
Ohne Verlängerung endet der Dienst. Der Mac sollte nicht der einzige Speicherort für das Projekt sein: Exportiere und prüfe alle Dateien, bevor du entscheidest, ob du die Miete beendest oder verlängerst.
Lade IPA, Archive, Symbol-Dateien, Build-Protokolle und erforderliche Konfigurationen herunter. Exportiere Signaturmaterial, das aufbewahrt werden muss, nur mit Genehmigung des Kunden und über einen sicheren Weg. Prüfe die Dateien lokal oder im vom Kunden festgelegten Speicher. Bewahre privaten Schlüssel und Passwort getrennt auf.
Entferne nicht mehr benötigte Repository-Zugangsdaten, temporäre Schlüssel und Verknüpfungen zu Automatisierungsaufgaben. Stelle sicher, dass keine Builds mehr an diesen Mac gesendet werden. Vor der erneuten Bereitstellung wird das System bereinigt – Backups und der Entzug von Berechtigungen müssen trotzdem vorher erledigt sein.
Ist das Projekt abgeschlossen, prüfe das Ablaufdatum in der Konsole und verlängere nicht. Läuft das Projekt weiter, verlängere im passenden Abonnement oder Auftrag der Instanz für einen geeigneten Zeitraum. Prüfe nach der Zahlung das neue Ablaufdatum. Wenn du Hilfe beim Neuaufsetzen oder beim Status brauchst, nenne in einem Konsolen-Ticket die Mac-Nummer und dein Anliegen.
Gib im Ticket Mac-Nummer, Standort, Zeitpunkt, Arbeitsschritte und die vollständige Fehlermeldung an. Achte bei Screenshots darauf, dass Passwörter und private Schlüssel nicht sichtbar sind. Wenn du noch keinen Mac gemietet hast, schreibe eine E-Mail an support@vmssd.com und nenne Projektlaufzeit und Framework. Bei Problemen mit einer bestehenden Instanz reiche das Ticket vorzugsweise über die Konsole ein, damit es der richtigen Bestellung zugeordnet werden kann.
Wähle Modell, Standort und Laufzeit. Nach der Zahlung erfolgt die Freischaltung noch am selben Tag. Erstelle zuerst einen reproduzierbaren Build und entscheide dann anhand des Projektplans über die Verlängerung.