Eine React-Native-App für iOS ohne Mac bauen

Was unter Windows und Linux funktioniert

Ihr JavaScript- und TypeScript-Code, Metro und Jest laufen auf jedem Desktop. In unserem Test hat eine frisch angelegte App ihren Jest-Test bestanden, auf GitHubs Runner ubuntu-24.04 und auf dem Runner windows-2025. Beide nutzten Node 22. Auch die Android-App können Sie auf beiden Systemen bauen und starten. Die Doku von React Native erklärt das Android-Setup für Windows und für Linux.

Für iOS ist dieselbe Doku deutlich. Auf den Setup-Seiten für Windows und Linux steht, dass ein Mac nötig ist, um Projekte mit nativem Code für iOS zu bauen. Sie empfiehlt Expo Go. Damit läuft Ihr JavaScript während der Entwicklung auf einem echten iPhone. Das deckt Screens und Logik ab. Eine App, die Sie veröffentlichen können, entsteht so nicht.

Was macOS braucht

• pod install. Das iOS-Projekt holt React Native und seine nativen Abhängigkeiten über CocoaPods. In diesem Schritt läuft auch Codegen.
• xcodebuild. Xcode und das iOS SDK gibt es nur für macOS. Apple nennt auf der Seite mit den Systemanforderungen für Xcode macOS Tahoe 26.2 oder neuer für Xcode 26.6.
• Der Simulator. Er steckt in Xcode, läuft also ebenfalls nur auf dem Mac.
• Signieren und hochladen. Dieser Teil steht in eine iOS-App ohne Mac veröffentlichen.

Der Workflow, den wir ausgeführt haben

Er legt mit dem Befehl von reactnative.dev eine neue App an. Er führt die Tests unter Linux und Windows aus. Dann baut er iOS auf einem Runner macos-26. Die Init-Flags stammen aus der Doku der React Native CLI. Sie wählen npm, überspringen die Pod-Abfrage und das Git-Setup. Legen Sie die Datei unter .github/workflows/rn-ios.yml ab und starten Sie sie im Tab Actions.

name: rn-ios
on: workflow_dispatch
jobs:
  test-linux:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v7
        with:
          node-version: 22
      - run: npx @react-native-community/cli@latest init RNDemo --pm npm --install-pods false --skip-git-init true
      - run: npm test
        working-directory: RNDemo
  test-windows:
    runs-on: windows-latest
    steps:
      - uses: actions/setup-node@v7
        with:
          node-version: 22
      - run: npx @react-native-community/cli@latest init RNDemo --pm npm --install-pods false --skip-git-init true
      - run: npm test
        working-directory: RNDemo
  build-ios:
    runs-on: macos-26
    steps:
      - uses: actions/setup-node@v7
        with:
          node-version: 22
      - run: sudo xcode-select -s /Applications/Xcode_26.6.app
      - run: xcodebuild -version && node -v && ruby -v
      - run: npx @react-native-community/cli@latest init RNDemo --pm npm --install-pods false --skip-git-init true
      - run: node -p "require('react-native/package.json').version"
        working-directory: RNDemo
      - run: bundle install
        working-directory: RNDemo/ios
      - run: bundle exec pod install
        working-directory: RNDemo/ios
      - name: Build for the iOS Simulator (Debug)
        run: |
          xcodebuild -workspace RNDemo.xcworkspace -scheme RNDemo \
            -configuration Debug -sdk iphonesimulator \
            -destination 'generic/platform=iOS Simulator' \
            -derivedDataPath build build
        working-directory: RNDemo/ios
      - name: Build for the iOS Simulator (Release, JS bundled)
        run: |
          xcodebuild -workspace RNDemo.xcworkspace -scheme RNDemo \
            -configuration Release -sdk iphonesimulator \
            -destination 'generic/platform=iOS Simulator' \
            -derivedDataPath build build
        working-directory: RNDemo/ios
      - run: ls -la build/Build/Products/Release-iphonesimulator/RNDemo.app/main.jsbundle && du -sh build/Build/Products/*-iphonesimulator/RNDemo.app
        working-directory: RNDemo/ios

In Ihrem eigenen Repo ersetzen Sie den Init-Schritt durch einen Checkout Ihres Codes und die Installation seiner Pakete. Der Rest bleibt gleich. Ändern Sie RNDemo in den Namen Ihres Workspaces und Schemes.

Was der Lauf ausgegeben hat

Diese Zeilen stammen aus dem Log des Jobs build-ios. Der ganze macOS-Job dauerte 2 Minuten 42 Sekunden.

Xcode 26.6
Build version 17F113
v22.23.2
0.87.1
Pod install took 43 [s] to run
Pod installation complete! There are 87 dependencies from the Podfile and 86 total pods installed.
** BUILD SUCCEEDED **
Welcome to Metro v0.87.1
** BUILD SUCCEEDED **
-rw-r--r--  1 runner  staff  1268567 Oct  2 04:02 build/Build/Products/Release-iphonesimulator/RNDemo.app/main.jsbundle
154M	build/Build/Products/Debug-iphonesimulator/RNDemo.app
 38M	build/Build/Products/Release-iphonesimulator/RNDemo.app

Der Debug-Build dauerte etwa 39 Sekunden, der Release-Build etwa 35. Das geht so schnell, weil React Native 0.87 einen vorgebauten Kern herunterlädt. Das Log von pod install sagt das ausdrücklich. Ältere Versionen kompilieren viel mehr nativen Code. Rechnen Sie dort mit längeren Builds.

Warum zweimal bauen? Eine Debug-App lädt ihr JavaScript zur Laufzeit von Metro. Der Release-Build packt das JavaScript als main.jsbundle in die App, hier 1,27 MB. Wenn der Release-Build durchläuft, kompilieren sowohl Ihr Bundle als auch Ihr nativer Code.

Bei jedem Pull Request ausführen

Der Workflow oben startet manuell. Um iOS-Fehler vor dem Merge zu finden, ändern Sie die Trigger-Zeile, damit er auch bei Pull Requests läuft:

on:
  pull_request:
  workflow_dispatch:

Wenn ein Build fehlschlägt, ist das Log lang. Unseres hatte bei zwei kleinen Builds über 18.000 Zeilen. Suchen Sie im Log nach "error:" und lesen Sie den ersten Treffer. Spätere Fehler sind oft Folgen des ersten. Wenn pod install fehlschlägt, schauen Sie zuerst ins Podfile und auf Ihre nativen Abhängigkeiten.

Was es kostet

GitHub rechnet jeden Job auf die volle Minute aufgerundet ab. Unser macOS-Job kam auf 3 Minuten. Bei $0.062 pro Minute, dem Satz in GitHubs Preisreferenz für Runner im Oktober 2026, sind das etwa 19 Cent. Öffentliche Repositories zahlen für Standard-Runner nichts. Für ein paar Builds pro Woche ist das der günstigste Weg zu einem iOS-Build.

Mit Expo gibt es noch einen Weg. EAS Build kompiliert iOS in der Cloud von Expo. Der Free-Tarif enthält 15 iOS-Builds pro Monat in einer Warteschlange mit niedriger Priorität. Danach kostet ein mittlerer iOS-Build $2, laut expo.dev/pricing im Oktober 2026.

Wo CI nicht mehr reicht

Ein CI-Job beweist, dass die App kompiliert. Zeigen kann er Ihnen die App nicht. Ein Simulator-Build läuft nur im iOS-Simulator, und der braucht einen Mac-Bildschirm. Wenn ein natives Modul nur unter iOS kaputtgeht, wollen Sie Xcode offen haben. Sie wollen Breakpoints und einen Simulator, den Sie anklicken können. Dafür lesen Sie Xcode unter Windows mit einem Remote-Mac nutzen.

Der gehostete Runner startet außerdem jedes Mal leer. Jeder Lauf lädt Node-Pakete, Gems und Pods neu herunter. In unserem Lauf trug der macOS-Job außerdem einen Hinweis von GitHub. Darin stand, dass macOS-arm64-Jobs wegen Kapazitätsengpässen länger in der Warteschlange stehen können.

Wer dafür keinen Mac mieten sollte

Wenn Sie ein paar Mal pro Woche bauen, bleiben Sie bei gehosteten Runnern oder EAS. Ein dedizierter Mac lohnt sich ab etwa 2,242 macOS-Minuten pro Monat zu GitHubs Basissatz. Er lohnt sich auch, wenn Sie den Bildschirm brauchen. Trifft beides nicht zu, ist ein gemieteter Mac Geld, das Sie nicht ausgeben müssen.

Wenn Sie diese Grenze überschreiten, läuft derselbe Workflow auf einem selbst gehosteten macOS-Runner. Ändern Sie runs-on und richten Sie xcode-select auf Ihr Xcode aus. Pods und Derived Data bleiben zwischen den Läufen warm. Die M6-Tarife finden Sie auf der Preisseite.