Comment créer une application iOS sans Mac

Vous pouvez écrire, compiler, signer et publier une application iOS sans posséder de Mac, mais toutes les solutions viables empruntent macOS à quelqu’un d’autre : les serveurs de build d’Expo, un Mac loué ou un runner de CI.

Si vous travaillez sous Windows ou Linux, vous avez probablement une application React Native ou Capacitor fonctionnelle, un iPhone sur votre bureau et un guide « Getting Started » qui vous demande d’ouvrir Xcode. Or, Xcode ne s’installe pas sur votre machine.

Cet article présente les solutions légitimes pour contourner ce problème, ce que coûte chacune d’elles et comment tester votre application une fois compilée. Compiler dans le cloud est la partie facile. Tester sans Mac est plus difficile.

Pourquoi la chaîne de compilation d’Apple nécessite-t-elle macOS ?

Xcode, xcodebuild, l’outil codesign et le simulateur iOS ne fonctionnent que sous macOS. La vraie question est donc de savoir à qui appartient le Mac qui fait le travail, car vous ne pouvez pas vous en passer. La compilation du code iOS natif, la signature du binaire avec votre certificat de distribution et son empaquetage pour App Store Connect se déroulent tous au sein de la chaîne d’outils d’Apple. Chacune des solutions ci-dessous contourne cette limite. Aucune ne la supprime.

Compiler une application iOS sans Mac avec Expo EAS

Pour un projet React Native ou Expo, eas build --platform ios compile et signe l’application sur les serveurs d’Expo. Une fois connecté avec votre compte Apple Developer Program, EAS CLI peut également générer pour vous le certificat de distribution et le profil de provisionnement. Pour la plupart des lecteurs de cet article, c’est la solution à privilégier.

Si vous découvrez Expo, commencez par Getting Started with Expo. La séquence complète tirée du guide de configuration des builds d’Expo se présente ainsi :

# Create a project if you don't have one
npx create-expo-app@latest my-app
cd my-app

# Install the EAS CLI and sign in to your Expo account
npm install --global eas-cli
eas login
eas whoami            # confirms which account you're signed in as

# Generate the build configuration for the project
eas build:configure

# Build a signed iOS binary on Expo's servers
eas build --platform ios --message "First App Store build"

# Check build status and logs later
eas build:list

Si vous préférez éviter l’installation globale, exécutez npx eas-cli@latest partout où la documentation indique eas. Au lancement du build, la CLI vous demande si elle doit gérer vos identifiants iOS. Si vous acceptez et vous connectez à votre compte Apple, vous n’aurez jamais besoin d’ouvrir le Trousseau d’accès ni un portail de certificats.

EAS Build fonctionne immédiatement avec les applications Expo et React Native, y compris celles créées avec react-native ou ignite-cli. Selon Expo, il fonctionne aussi avec d’autres projets natifs. Capacitor ne dispose d’aucun guide EAS officiel : les équipes Capacitor utilisent donc généralement l’une des solutions présentées plus bas.

La publication ne demande qu’une commande supplémentaire :

eas submit --platform ios

EAS Submit fonctionne sous Windows, Linux ou macOS. Il envoie votre build vers App Store Connect et, une fois l’envoi traité par Apple, vous retrouvez le build dans TestFlight. Cette étape nécessite un compte Apple Developer payant. Vous vous authentifiez soit avec une clé d’API App Store Connect, soit avec votre identifiant Apple accompagné d’un mot de passe pour application.

Louer un Mac dans le cloud lorsque vous avez besoin de Xcode

Un Mac loué dans le cloud vous donne accès à un bureau macOS complet via une connexion à distance. Optez pour cette solution lorsque vous avez besoin de Xcode lui-même : pour développer des modules natifs, déboguer au niveau de Xcode ou gérer un projet Capacitor dépourvu de solution de build managée. Des fournisseurs comme MacStadium et MacinCloud proposent ce type de machine à la location. Vous gagnez en contrôle, mais vous prenez aussi en charge l’administration : installer et mettre à jour Xcode, gérer les certificats et les profils, et écrire vos propres scripts de build.

Utiliser une CI avec des runners macOS

Une CI hébergée avec des runners macOS convient aux équipes qui scriptent déjà leurs builds. GitHub Actions propose des runners macOS hébergés en plus de ses runners Linux et Windows, et d’autres fournisseurs de CI offrent des machines macOS similaires. Le runner se charge du build, mais la signature reste votre responsabilité : vous stockez les certificats et les profils sous forme de secrets et les intégrez vous-même au pipeline. Si vous utilisez Expo, vous pouvez aussi déclencher des builds EAS depuis la CI tout en conservant la signature managée d’Expo.

Solutions à éviter : Hackintosh et VM macOS

Faire tourner macOS sur du matériel non Apple, que ce soit sous forme de Hackintosh ou dans une machine virtuelle sur un PC Windows ou Linux, enfreint les conditions de licence d’Apple. La licence logicielle de macOS Tahoe interdit d’installer ou d’exécuter macOS sur tout ordinateur qui n’est pas de marque Apple. Elle n’autorise les machines virtuelles macOS que sur un Mac fonctionnant déjà sous macOS. Écartez ces deux solutions.

Comment tester une application iOS sans Mac ?

Sans Mac personnel, vous testez une application iOS sur un iPhone physique, soit via un build de développement ou interne EAS, soit via TestFlight, car le simulateur iOS est une application macOS. La compilation peut être entièrement déportée dans le cloud. C’est au moment des tests que l’absence de Mac se fait réellement sentir.

Pour le travail au quotidien, ajoutez le client de développement et compilez pour une distribution interne :

npx expo install expo-dev-client

Avec la distribution interne, EAS utilise un provisionnement ad hoc. Le profil répertorie les UDID (identifiants uniques des appareils) autorisés, et un appareil ne peut installer le build que s’il figurait dans cette liste au moment de sa création. Enregistrez votre iPhone avec cette commande :

eas device:create

Après avoir enregistré un appareil, lancez un nouveau build : les builds créés avant l’enregistrement ne pourront pas s’y installer. Ces builds pour appareils sont signés avec un certificat de distribution et un profil ad hoc, qui nécessitent tous deux un compte Apple Developer Program payant.

Pour des tests à plus grande échelle, TestFlight peut accueillir jusqu’à 10 000 testeurs externes par application. Vous les invitez par e-mail ou partagez un lien public, et le build doit d’abord passer la vérification de TestFlight (TestFlight App Review).

Une limite demeure : le débogage natif avec Xcode et le simulateur iOS nécessitent toujours macOS. Lorsque vous en arrivez là, louez un Mac dans le cloud le temps de la session.

Combien cela coûte-t-il, et quelle solution choisir ?

L’Apple Developer Program coûte 99 $ par an, et Apple le facture dans votre devise locale dans de nombreuses régions. Ces frais s’appliquent à toutes les solutions sans Mac, car la signature pour l’App Store et la distribution via TestFlight exigent toutes deux une adhésion, quel que soit l’endroit où s’exécute le build.

L’offre gratuite d’EAS vous accorde un petit quota mensuel de builds iOS dans une file d’attente plus lente. Les offres payantes vous font passer dans la file prioritaire, autorisent des builds plus longs et vous permettent de payer pour exécuter davantage de builds simultanément.

Dans le cas courant d’une application React Native ou Expo développée sous Windows ou Linux, utilisez Expo et un iPhone physique. Payez l’adhésion de 99 $, compilez et signez avec EAS, testez avec des builds internes et TestFlight, et ne louez un Mac que lorsque vous avez besoin de Xcode lui-même.

Ne pas posséder de Mac signifie que vous louez la chaîne d’outils d’Apple au lieu d’acheter le matériel. La compilation et la publication fonctionnent très bien à distance. Ce à quoi vous renoncez, c’est au simulateur et au débogage natif. Prochaine étape : inscrivez-vous à l’Apple Developer Program, exécutez eas build:configure dans votre projet et enregistrez votre iPhone avec eas device:create avant votre premier build interne.

FAQ

Puis-je exécuter mon application sur un iPhone sans Mac ni compte Apple payant ?

Oui, pour du prototypage, grâce à Expo Go. Installez Expo Go depuis l'App Store, lancez votre projet Expo sous Windows ou Linux, puis scannez le QR code avec l'appareil photo de l'iPhone. La version du SDK Expo de votre projet doit correspondre à la version d'Expo Go disponible sur l'App Store. Expo Go embarque un ensemble fixe de bibliothèques natives : les bibliothèques contenant d'autres codes natifs échouent donc dans cet environnement. Les notifications push distantes, les liens universels ainsi que le nom et l'icône propres à votre application nécessitent un build de développement, et l'installation d'un tel build sur un iPhone sans Mac requiert le programme payant.

Combien d'iPhone peuvent installer un build interne EAS ?

Jusqu'à 100 iPhone par année d'adhésion. Les builds ad hoc ne s'installent que sur les appareils enregistrés dans votre compte Apple Developer, et Apple comptabilise chaque famille de produits séparément : 100 iPhone et 100 iPad sont donc autorisés. Désactiver un appareil ne libère pas son emplacement. Vous ne pouvez supprimer des appareils et rétablir le quota à 100 qu'au début d'une nouvelle année d'adhésion. Pour des groupes plus importants, utilisez TestFlight, qui ne nécessite aucun enregistrement d'appareil.

Dois-je créer un nouveau build iOS à chaque modification du code ?

Non. EAS Update déploie à distance (OTA) les modifications de JavaScript, de styles et d'images sur les builds qui intègrent la bibliothèque expo-updates, et les utilisateurs obtiennent la nouvelle version au prochain lancement de l'application. Les modifications natives, comme l'ajout d'une bibliothèque contenant du code Swift ou Objective-C, nécessitent toujours un nouveau build EAS et, pour les applications publiées sur le store, une nouvelle soumission à l'App Store. Le build qui ajoute expo-updates pour la première fois doit lui-même être un nouveau build.