Eine iOS-App zu entwickeln bedeutet traditionell eines: Man braucht Xcode, und Xcode setzt macOS voraus. Diese Einschränkung ist nervig, wenn das gesamte Team auf Windows oder Linux arbeitet oder man einfach keine Mac-Build-Maschine betreiben möchte.
Die Kombination aus Capacitor (um das native iOS-Projekt zu generieren) und Capgo Build (um es in der Cloud zu kompilieren und zu signieren) ermöglicht iOS-Builds und TestFlight-Einreichungen direkt von einem Windows-Rechner aus.
Dieser Guide zeigt einen pragmatischen Workflow, der in Teams gut funktioniert:
- Entwickle unter Windows wie bei einem normalen Web-Projekt.
- Behalten
ios/in deinem Repo (damit der native Zustand reproduzierbar ist). - Ausführen
cap synclokal (damit dein Web-Build in das iOS-Projekt kopiert wird). - Löse einen iOS-Cloud-Build mit Capgo Build aus.
Was du wo tatsächlich baust
Es gibt zwei separate „Builds“ in einer Capacitor App:
- Web-Build (deine JS/HTML/CSS): Das machst du lokal unter Windows.
- Native Build (Xcode-Archiv, Signing, Upload): Capgo Build erledigt das in der Cloud auf Mac-Hardware.
Diese Trennung ist entscheidend: Capgo Build kompiliert das native Projekt, setzt aber voraus, dass deine Web-Assets bereits synchronisiert wurden in ios/.
Voraussetzungen
- Eine funktionierende Capacitor-App (jedes Framework ist okay).
- Ein Apple-Developer-Account.
- Zugriff auf App Store Connect für die App, die du hochladen willst (für TestFlight-/App-Store-Einreichung).
- Dein Capgo-Account und API-Token (
CAPGO_TOKEN).
1) Erstelle oder bereite deine Capacitor-App vor (Windows)
Wenn du bereits eine Web-App hast, überspringe die Capacitor-Schritte.
Beispiel mit Vite:
bun create vite@latest my-app
cd my-app
bun install
Der Build muss statische Assets erzeugen (bei Vite ist das dist/ standardmäßig):
bun run build
2) Capacitor und die iOS-Plattform hinzufügen
Installiere Capacitor:
bun add @capacitor/core @capacitor/ios
bun add -d @capacitor/cli
Initialisiere und erstelle den iOS-Platform-Ordner:
bunx cap init
bunx cap add ios
An diesem Punkt hast du ein ios/ Verzeichnis. Committe es in Git. Capgo Build kompiliert den Inhalt ios/, damit es versioniert und reproduzierbar ist.
3) Web-Assets vor dem Build immer in iOS synchronisieren
Führe bei jeder Änderung deiner Web-App diese Abfolge auf Windows aus:
bun run build
bunx cap sync ios
cap sync kopiert die gebauten Web-Assets in das native iOS-Projekt (die Dateien, die Capgo Build tatsächlich kompiliert).
4) Capgo CLI installieren und authentifizieren
Der Capgo Build wird über die Capgo CLI ausgelöst. Mit bun nutzt du bunx:
bunx @capgo/cli@latest login
Oder setze dein Token via Umgebungsvariable in deiner Shell/CI:
export CAPGO_TOKEN="your_api_key_here"
5) iOS Signing für Cloud Builds konfigurieren
Für iOS Builds benötigst du Signing-Material:
- Apple Distribution Certificate (
.p12) und das zugehörige Passwort - Provisioning Profile (
.mobileprovision) - App Store Connect API Key (
AuthKey_XXXXXX.p8) und Metadaten (Key ID, Issuer ID, Team ID)
Falls du diese Dateien noch generieren musst, folge der Capgo-Dokumentation:
- Credentials verwalten (was gespeichert werden muss und wie)
- So bekommst du iOS-Zertifikate und Provisioning-Profile
Der einfachste Weg: Erstelle/exportiere diese einmal (oft mit einem verfügbaren Mac, einem Teammitglied oder einem einmalig gemieteten Mac) und verwende sie dann von Windows aus für alle weiteren Builds wieder.
Sobald du die Dateien lokal hast, speichere sie für Capgo Build:
bunx @capgo/cli@latest build credentials save \
--platform ios \
--certificate ./cert.p12 \
--p12-password "password" \
--provisioning-profile ./profile.mobileprovision \
--apple-key ./AuthKey.p8 \
--apple-key-id "KEY123" \
--apple-issuer-id "issuer-uuid" \
--apple-team-id "team-id"
Tipp: Speichere die Credential-Dateien in CI base64-kodiert als Secrets, dekodiere sie zur Laufzeit und führe dann denselben build credentials save Befehl.
6) iOS-Build von Windows aus auslösen
Aus deinem App-Ordner:
bun run build
bunx cap sync ios
bunx @capgo/cli@latest build com.example.app --platform ios --build-mode release
In deinem Terminal siehst du die Logs in Echtzeit. Wenn dein App Store Connect Key konfiguriert ist, kann Capgo Build das Ergebnis automatisch an TestFlight übermitteln.
7) Schnell iterieren: Live Updates für reine Web-Änderungen
Capgo Build ist für native Änderungen gedacht:
- Hinzufügen/Entfernen von Capacitor Plugins
- Ändern nativer Berechtigungen
- Ändern von Icons/Splash
- Aktualisieren von Capacitor
- irgendwelche Swift-/Objective-C-Änderungen
Für alltägliche UI-Anpassungen und JavaScript-Fixes willst du in der Regel Capgo Live Updates (OTA), damit du das native Binary nicht jedes Mal neu bauen musst.
Ein guter Team-Workflow ist:
- Nutze Live Updates für häufige Web-Änderungen.
- Nutze Capgo Build gelegentlich, wenn native Änderungen nötig sind.
Häufige Windows-Stolperfallen (und Lösungen)
- Vergessen
cap sync: Wenn UI-Änderungen im iOS-Build fehlen, wurde die Web-App wahrscheinlich gebaut, aber nicht synchronisiertios/. - Nicht committen
ios/: Capgo Build kompiliert das native Projekt. Wenn der Ordner nicht in Git ist (oder nicht in deinem Build-Kontext), kann der Build deine App nicht reproduzieren. - Plugin-Änderungen ohne nativen Rebuild: Das Hinzufügen eines Plugins ist eine native Änderung; plane danach einen Capgo Build (und eine Store-Einreichung) ein.
Zusammenfassung
Du kannst Xcode nicht unter Windows ausführen, aber du kannst iOS-Apps von Windows aus ausliefern:
- Verpacke deine Web-App mit Capacitor (
ios/in deinem Repo). - Baue Web-Assets lokal, dann
cap sync. - Nutze Capgo Build zum Kompilieren, Signieren und Einreichen deiner iOS-Binary über CLI.
Weiter mit: iOS-App unter Windows mit Capacitor und Capgo Build erstellen
Wenn du es nutzt iOS-App unter Windows bauen mit Capacitor und Capgo Build um CI/CD-Automatisierung zu planen, verbinde es mit Capgo CI/CD für den Produkt-Workflow in Capgo CI/CD, Capgo Native Builds optimieren für den Produkt-Workflow in Capgo Native Builds, Capgo Integrationen für den Produkt-Workflow in Capgo Integrations, CI/CD-Integration für die Implementierungsdetails in der CI/CD-Integration und GitHub Actions-Integration für die Implementierungsdetails in der GitHub Actions-Integration.