Compiler une app React Native pour iOS sans Mac

Ce qui fonctionne sous Windows et Linux

Votre code JavaScript et TypeScript, Metro et Jest tournent sur n’importe quel poste. Dans notre test, une app toute neuve a passé son test Jest sur le runner ubuntu-24.04 de GitHub et sur son runner windows-2025. Les deux utilisaient Node 22. Vous pouvez aussi compiler et lancer l’app Android sur l’un ou l’autre système. La documentation React Native détaille l’installation Android pour Windows et pour Linux.

Pour iOS, la même documentation est sans détour. Sur les pages d’installation Windows et Linux, elle indique qu’un Mac est nécessaire pour compiler des projets iOS avec du code natif. Elle propose Expo Go, qui exécute votre JavaScript sur un vrai iPhone pendant le développement. Cela couvre les écrans et la logique. Cela ne produit pas une app que vous pouvez publier.

Ce qui demande macOS

• pod install. Le projet iOS récupère React Native et ses dépendances natives via CocoaPods. Codegen tourne aussi pendant cette étape.
• xcodebuild. Xcode et le SDK iOS n’existent que pour macOS. Apple indique macOS Tahoe 26.2 ou plus récent pour Xcode 26.6, sur sa page de configuration requise pour Xcode.
• Le simulateur. Il est livré avec Xcode, donc il ne tourne lui aussi que sur Mac.
• Signature et envoi. Cette partie est traitée dans publier une app iOS sans Mac.

Le workflow que nous avons lancé

Il crée une nouvelle app avec la commande de reactnative.dev. Il lance les tests sous Linux et Windows. Puis il compile pour iOS sur un runner macos-26. Les options d’init viennent de la documentation du CLI React Native. Elles choisissent npm, sautent la question sur les pods et sautent la configuration git. Placez-le dans .github/workflows/rn-ios.yml et lancez-le depuis l’onglet 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

Dans votre propre dépôt, remplacez l’étape d’init par un checkout de votre code et l’installation de ses paquets. Le reste ne change pas. Remplacez RNDemo par le nom de votre workspace et de votre scheme.

Ce que le run a affiché

Ces lignes sont copiées du log du job build-ios. Le job macOS complet a duré 2 minutes 42 secondes.

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

Le build Debug a pris environ 39 secondes et le build Release environ 35. C’est rapide parce que React Native 0.87 télécharge un cœur précompilé. Le log de pod install le dit clairement. Les versions plus anciennes compilent bien plus de code natif, attendez-vous donc à des builds plus longs.

Pourquoi compiler deux fois ? Une app Debug charge son JavaScript depuis Metro pendant qu’elle tourne. Le build Release intègre le JavaScript dans l’app sous forme de main.jsbundle, ici 1,27 Mo. Si le build Release passe, votre bundle et votre code natif compilent tous les deux.

Le lancer à chaque pull request

Le workflow ci-dessus se lance à la main. Pour repérer une casse iOS avant le merge, modifiez la ligne de déclenchement pour qu’il tourne aussi sur les pull requests :

on:
  pull_request:
  workflow_dispatch:

Quand un build échoue, le log est long. Le nôtre dépassait 18 000 lignes pour deux petits builds. Cherchez "error:" dans le log et lisez la première occurrence. Les erreurs suivantes découlent souvent de la première. Si pod install échoue, regardez d’abord le Podfile et vos dépendances natives.

Ce que ça coûte

GitHub facture chaque job arrondi à la minute supérieure. Notre job macOS a compté 3 minutes. À $0.062 la minute, le tarif de la grille des runners GitHub en octobre 2026, cela fait environ 19 cents. Les dépôts publics ne paient rien pour les runners standard. Pour quelques builds par semaine, c’est le moyen le moins cher d’obtenir un build iOS.

Avec Expo, il existe une autre voie. EAS Build compile pour iOS dans le cloud d’Expo. L’offre Free inclut 15 builds iOS par mois, dans une file à basse priorité. Au-delà, un build iOS medium coûte $2, selon expo.dev/pricing en octobre 2026.

Quand la CI ne suffit plus

Un job CI prouve que l’app compile. Il ne peut pas vous montrer l’app. Un build pour le simulateur ne tourne que dans le simulateur iOS, qui a besoin d’un écran de Mac. Quand un module natif casse seulement sur iOS, vous voulez Xcode ouvert. Vous voulez des breakpoints et un simulateur où cliquer. Pour cela, lisez utiliser Xcode depuis Windows avec un Mac distant.

Le runner hébergé repart aussi de zéro à chaque fois. Chaque run retélécharge les paquets Node, les gems et les pods. Dans notre run, le job macOS affichait aussi un avertissement de GitHub. Il disait que les jobs macOS arm64 pouvaient attendre plus longtemps en file, faute de capacité.

Qui ne devrait pas louer un Mac pour cela

Si vous compilez quelques fois par semaine, restez sur les runners hébergés ou sur EAS. Un Mac dédié devient rentable vers 2,242 minutes macOS par mois au tarif de base de GitHub. Il devient aussi rentable quand vous avez besoin de l’écran. Si aucun des deux cas ne vous concerne, un Mac loué est une dépense inutile.

Si vous dépassez ce seuil, le même workflow tourne sur un runner macOS self-hosted. Changez runs-on et pointez xcode-select vers votre Xcode. Les pods et les données dérivées restent chauds entre les runs. Consultez les tarifs pour les offres M6.