Développer iOS sur Windows — en finir avec l'achat d'un Mac ? Dans les équipes .NET, jeux vidéo et DSI Windows-first en France, cette question revient sans cesse en 2026. Souvent avec l'affirmation provocante : plus besoin d'acheter un Mac. Si votre bureau tourne sous Windows 11 et que vous ne touchez à iOS que de temps en temps, ce qui compte n'est pas si macOS est agréable, mais si Windows peut rester votre machine principale de bout en bout.
Nous avons enchaîné clone → TestFlight sur un Windows 11 + Ryzen 7 / 32 Go avec trois dépôts réels (SwiftUI natif, React Native 0.76, Flutter 3.24). La chaîne Apple tournait sur un M4 Mac mini dédié (nœud US West) ; bureau à Paris, RTT SSH ~130 ms, Xcode 16.2. En bref : le code quotidien reste à 100 % sur Windows ; signature et mise en store exigent macOS — mais ce Mac n'a pas à être sur votre bureau. Timings, tableau de répartition, commandes et contre-exemples ci-dessous. Cadre de répartition : poste Windows/Linux + îlot Mac distant.
Ce que signifie « indépendant »
« iOS sous Windows » mélange trois propositions distinctes. Sans les séparer, on aboutit à « Mac obligatoire » ou « jamais de Mac » — deux extrêmes faux.
- Proposition A : écrire du code, Git, revues sur Windows — oui, quotidien des équipes cross-platform.
- Proposition B : compiler des
.ipaiOS en local, Simulator, Archive sur Windows — non ; Apple ne fournit pas cette voie. WSL2, Docker, VM ne sont pas des chemins de prod supportés. - Proposition C : pas de Mac sur le bureau tout en livrant iOS — oui, en déplaçant B vers Mac distant, EAS Build ou runner auto-hébergé.
Cet article vise A + C. Aligné avec le mythe « Xcode pour Windows » — les installateurs en résultats de recherche sont presque toujours du SEO trompeur.
Environnement de test et trois stacks
Poste local et nœud distant
Windows : Windows 11 23H2, VS Code 1.92 + Remote-SSH, Git 2.45, Node 20 LTS (RN), Flutter 3.24. Mac distant : M4 Mac mini dédié 16 Go / 256 Go, macOS 15.4, Xcode 16.2, nœud US West (bureau Paris, RTT SSH ~130 ms).
Route 1 : SwiftUI natif
Édition Swift sur Windows ; xcodebuild, prévisualisation SwiftUI et Simulator via SSH sur le Mac distant. Une session VNC pour confiance certificat et trousseau — ensuite builds headless.
Route 2 : React Native 0.76
npx react-native start sur Windows pour le hot reload Metro. Débogage iOS sur appareil via USB vers le distant est pénible ; pratique : émulateur Android + passage Simulator distant avant release. Livraison avec pod install && xcodebuild archive sur le Mac distant — voir guide îlot de build.
Route 3 : Flutter 3.24
flutter run -d chrome et émulateur Android sur Windows pour l'essentiel de l'UI ; flutter build ipa uniquement sur macOS. Build complet sur Mac distant : ~6–9 min cache chaud.
Qui fait quoi : Windows vs Mac
| Étape | Windows seul (sans macOS) | Windows principal + Mac distant | MacBook local complet |
|---|---|---|---|
| Code / Git | ✅ | ✅ Windows | ✅ macOS |
| Hot reload JS / cross-platform | ✅ Android / Web | ✅ Windows + Simulator distant | ✅ |
| Compilation Swift locale | ❌ | ❌ → SSH distant | ✅ |
| Archive / signature | ❌ | ✅ Mac distant | ✅ |
| Upload TestFlight | ❌ | ✅ fastlane distant | ✅ |
| Courbe d'apprentissage bureau | Faible | Faible (Mac en appliance) | Élevée si macOS inconnu |
| Coût matériel initial | Pas d'achat Mac | Pas de Mac + location | MacBook / Mac mini plein tarif |
Si moins de ~20 % de votre semaine est du build Apple et Windows est votre habitude, la colonne Mac distant bat souvent l'achat. Si vous vivez dans Simulator et préviews SwiftUI, un Mac local compense — section six.
Workflow reproductible : push → TestFlight
Chemin release minimal déclenché depuis Windows, exécuté sur le M4 Mac mini distant (natif/RN ; Flutter : flutter build ipa à la place de l'archive).
Étape 1 : commit sous Windows
git add . && git commit -m "release: 1.4.0" && git push origin mainÉtape 2 : SSH vers le Mac distant, pull
ssh macbuild@your-remote-mac.example
cd ~/repos/MyApp && git pull origin main
pod install --repo-update # RN / projets CocoaPodsÉtape 3 : Archive et export
xcodebuild -workspace MyApp.xcworkspace -scheme MyApp \
-configuration Release -archivePath build/MyApp.xcarchive archive
xcodebuild -exportArchive -archivePath build/MyApp.xcarchive \
-exportPath build/export -exportOptionsPlist ExportOptions.plistÉtape 4 : upload TestFlight (fastlane optionnel)
xcrun altool --upload-app -f build/export/MyApp.ipa \
-t ios -u "$APPLE_ID" -p "@keychain:AC_PASSWORD"Sous Windows : VS Code et un terminal SSH pour les logs. Flux engineering complet : soumission App Store Xcode CI/CD. CI permanente : étapes 2–4 sur runner GitHub Actions auto-hébergé — l'équipe Windows merge seulement.
Benchmarks (juin 2026)
Taille des dépôts : SwiftUI ~42 k lignes / 38 cibles ; RN ~120 k lignes JS + 6 modules natifs ; Flutter ~28 k lignes Dart. Mac distant M4 16 Go, caches DerivedData et Pods préchauffés. Mesure unique — ordre de grandeur.
| Étape | SwiftUI natif | React Native | Flutter |
|---|---|---|---|
| git pull (nœud US West) | 3s | 4s | 3s |
| Dépendances (cache chaud) | — | pod 2m 40s | — |
| Dépendances (à froid) | — | pod 11m 20s | pub get 45s |
| Archive Release / ipa | 4m 55s | 6m 10s | 7m 30s |
| Upload TestFlight | 2m 15s | 2m 20s | 2m 10s |
| Total (cache chaud) | ~7 min | ~11 min | ~10 min |
Temps d'attente humain sous Windows : surtout les logs SSH — allez chercher un café. Goulot : compilation distante, pas le Ryzen. Les runners macOS hébergés GitHub passent souvent plus de temps en file d'attente qu'en build — d'où la nouvelle approche pipeline iOS 2026.
Limites : quand acheter un Mac
« Ne plus acheter de Mac » ne tient pas ici :
- Préviews SwiftUI / UIKit intensives : dizaines de retouches layout par jour, Canvas Xcode, Simulator multi-appareils — la latence VNC use ; Mac local rentable.
- Instruments / perfs : fuites, saccades, debug Metal — attach basse latence ; distant possible mais un cran en dessous.
- Hors ligne / air-gap : le code ne peut quitter le réseau — ferme Mac on-prem ou achat seulement.
- CI massif 7×24 : centaines de builds complets par jour — TCO location longue peut dépasser un parc de Mac mini ; tableur, pas seulement tarif journalier.
Milieu courant : garder Windows sur le portable, louer un M4 distant en semaine de release, ou Mac mini d'entreprise en salle serveur. Tarifs : page tarifs ; essai à la journée pour mesurer la RTT depuis Paris.
FAQ
Peut-on développer iOS entièrement sous Windows sans aucun Mac ?
Non. La chaîne Apple — xcodebuild, codesign, notarytool, upload TestFlight — doit tourner sur macOS. « Indépendant » signifie : bureau Windows au quotidien, macOS sur nœud distant dédié ou CI, sans MacBook sur le bureau.
Puis-je installer Xcode dans WSL2 ou Docker ?
Non. Xcode et le SDK iOS sont réservés à macOS. WSL2 et conteneurs Linux ne sont pas des chemins de production supportés. VM Hackintosh viole la licence et échoue à la revue sécurité entreprise.
Quelle est la voie légale la moins chère pour publier iOS sans acheter de Mac ?
Coder sous Windows, louer un M4 Mac mini distant dédié les semaines de release (SSH + xcodebuild / fastlane), ou EAS Build pour RN/Expo. Builds occasionnels via runners macOS GitHub — certificats et persistance cache faibles.
Puis-je écrire du Swift dans VS Code sous Windows ?
Oui pour l'édition et Git — pas de compilation locale des cibles iOS. Remote-SSH vers un Mac pour swift build / xcodebuild, ou déclenchement CI distant.
Comment les équipes React Native / Flutter publient iOS depuis Windows ?
RN : eas build --platform ios ou workflow auto-hébergé avec pod install + xcodebuild sur Mac distant. Flutter : Codemagic / jobs macOS GitHub Actions, ou SSH pour flutter build ipa.
Le Simulator iOS tourne-t-il sous Windows ?
Pas nativement. VNC vers Mac distant pour Simulator, ou appareil + hot reload Metro/React Native sur Windows pour la couche JS ; préviews SwiftUI natives exigent macOS.
Mac distant ou achat Mac mini — comment choisir ?
Acheter si charge fixe 7×24 et ops matériel en interne. Louer un M4 distant dédié pour sprints release, CI élastique, équipes qui gardent Windows au bureau — essayer la facturation journalière d'abord.
Les installateurs « Xcode pour Windows » sont-ils fiables ?
Non. Apple n'a jamais publié Xcode pour Windows. Ces résultats désignent en général Mac distant, signature cloud cross-platform ou runner macOS CI — pas Xcode natif sous Windows.
Conclusion
Retour au titre : Windows peut-il être votre machine iOS principale ? Oui — si « indépendant » est bien défini. Code, revue et hot reload cross-platform restent sur Windows ; archive, signature et store exigent macOS, et ce Mac peut être un M4 distant, pas un nouveau MacBook.
- « Xcode pour Windows » n'existe pas ; WSL / Hackintosh ne sont pas des chemins de prod.
- Swift, RN et Flutter livrent via Windows + Mac distant ; cache chaud ~7–11 min.
- Simulator 2 h+/jour ou power user Instruments : Mac local.
- Release hebdo : location Mac mini distant à la journée souvent plus rationnelle qu'acheter pour 20 % d'usage.
Étape suivante : louer un M4 une journée, SSH depuis Paris, pod install + xcodebuild archive sur votre dépôt — RTT et temps de build plutôt que les articles.
