Documentation

Appearance

État de préparation iOS ​

Archive du 4 août 2026. Pour la procédure actuelle Apple, Expo, OAuth et TestFlight, consulter le guide opérationnel du 31 octobre 2026. Pour le lancement habituel des builds, voir aussi le guide TestFlight. Les blocages décrits ci-dessous ne représentent plus l'état actuel.

Ce qui existe, ce qui n'existe pas, et ce qui bloque réellement une sortie iOS de Snag.

Instantané daté du 2026-08-04, pris sur poc-tcg-collector@main.

L'essentiel ​

  • Il n'y a pas de projet iOS. Pas un projet incomplet : ios/ n'existe pas du tout dans le dépôt.
  • Le bloqueur auquel tout le monde pense, « il nous faut un Mac », est déjà résolu et ne coûte rien : Codemagic compile sur macOS dans le cloud. EAS Build, chez Expo, résout le même problème de la même façon.
  • Les bloqueurs réels sont la licence Apple Developer (99 €/an, sans contournement possible) et le fait que le simulateur iOS n'a pas de caméra — donc le scan, le différenciateur classé premier de ce produit, ne peut être testé nulle part ailleurs que sur un iPhone physique.
  • Rien de tout cela ne peut être validé depuis Windows ni depuis le VPS. Le premier build Codemagic est le premier signal honnête.

Où en est réellement le projet ​

Le CLAUDE.md du dépôt mobile affirme que « nothing under ios/ has ever been compiled here ». Le fait est plus fort encore : il n'y a rien à compiler.

git ls-files | grep "^ios/"          →  0 fichier
Podfile, .xcodeproj, .xcworkspace    →  aucun, nulle part dans l'arbre
npm run ios                          →  « react-native run-ios » … vers rien

Le script npm est un vestige du template React Native. Il n'a jamais eu de cible.

À noter aussi, et c'est délibéré : l'application ne comporte presque aucun embranchement par plateforme — un seul Platform.OS dans tout src (src/scan/backendConfig.ts). Le JavaScript n'est pas le problème. C'est la coque native qui manque.

Ce qu'Android possède et qu'iOS n'a pas ​

ÉlémentAndroid aujourd'huiCe qu'exige iOS
Projet natifandroid/, AGP 7.4.2, compileSdk 34générer depuis le template React Native 0.73.6
Dépendances nativesrésolues par Gradlesix pods à intégrer via CocoaPods
Polices5 .ttf sous android/app/src/main/assets/fontscopier dans le projet Xcode et déclarer UIAppFonts dans Info.plist
PermissionsINTERNET, CAMERA dans le manifesteNSCameraUsageDescription, NSPhotoLibraryUsageDescription — du texte français destiné à l'utilisateur, pas des marque-places
Identitécom.poctcgcollectoridentifiant de bundle, icônes, écran de lancement
Nom affiché« TCG Collector »une décision : le produit s'appelle Snag, le nom du dépôt est historique

Les six dépendances natives à intégrer :

react-native-vision-camera
@react-native-ml-kit/text-recognition
react-native-image-picker
react-native-svg
react-native-safe-area-context
@react-native-async-storage/async-storage

Cinq d'entre elles sont sans histoire sur iOS. @react-native-ml-kit/text-recognition est celle à vérifier avant de s'engager sur un plan : ML Kit sur iOS traîne ses propres contraintes de taille de binaire et de configuration de pod, et son support Expo n'est pas confirmé. À vérifier, pas à supposer.

Un écart déjà présent dans le code ​

src/scan/resolveBackendHost.ts décide quel hôte le scanner appelle :

ts
if (input.platformOS !== 'android') return false;

Le raccourci émulateur — http://10.0.2.2, la boucle locale de l'hôte — est réservé à Android. Un simulateur iOS retombe donc sur SHARED_BACKEND_HOST, l'adresse du Funnel Tailscale.

Deux conséquences. D'abord, le tout premier lancement iOS échouerait sur le réseau et non sur le build, ce qui est une façon déroutante de commencer. Ensuite, un simulateur iOS s'exécute sur la machine de développement : http://localhost y est la cible locale correcte. Le raccourci équivalent existe donc, il n'a simplement jamais été écrit.

C'est un petit changement, et il appartient au même ticket que la génération de ios/ — un build vert incapable de joindre le backend ne prouve pas grand-chose.

Les trois bloqueurs, par ordre de dureté ​

1. iOS ne se compile pas sans macOS — déjà résolu ​

Ni le poste Windows ni le VPS Linux ne peuvent produire un build iOS, quel que soit le code écrit. Ce n'est pas une question d'effort.

C'est aussi déjà traité : le pipeline V2 du playbook CTO place les builds iOS sur Codemagic, qui exécute des machines macOS. C'est la raison d'être de Codemagic dans le plan — c'est la seule voie, pas un confort.

2. Licence Apple Developer — 99 €/an, incontournable ​

Pas de signature, pas de profil de provisionnement, pas de TestFlight, pas d'App Store. Cela vaut quel que soit l'outil de build, car c'est une exigence d'Apple et non de la chaîne d'outils. Impossible à contourner, et la validation du compte n'est pas instantanée : à lancer avant que ce ne soit sur le chemin critique.

3. Le simulateur n'a pas de caméra — cela change le plan de test ​

Sur Android, le scan se valide gratuitement sur un émulateur. Sur iOS, il ne peut pas être validé sur simulateur, tout simplement parce qu'il n'y a aucun périphérique caméra à ouvrir.

Comme le premier différenciateur affiché du produit est un scan plus rapide que celui de la concurrence, ce n'est pas un détail. Valider le comportement du scan sur iOS demande un iPhone physique et un canal de distribution — TestFlight ou Firebase App Distribution. À budgéter : l'appareil et la mise en place de la distribution, pas seulement les minutes de build.

Expo supprime-t-il le besoin d'un Mac ? ​

Oui — et c'est une mauvaise raison de l'adopter.

Ce qu'Expo résout. EAS Build compile sur les machines macOS d'Expo : on déclenche depuis Windows, on récupère un .ipa. Mais Codemagic fait déjà exactement cela, et Codemagic est déjà le plan. « Pas de Mac » n'est pas un avantage d'Expo ici, c'est une propriété partagée par les deux outils.

Ce qu'Expo ne résout pas. La licence Apple Developer reste obligatoire. Le simulateur reste sans caméra. Aucun des deux bloqueurs ne bouge.

Ce qu'Expo apporte vraiment. expo prebuild génère ios/ et android/ à partir d'app.json et de config plugins, au lieu d'en faire des répertoires versionnés maintenus à la main. Cela supprime précisément le travail listé dans le tableau plus haut : Podfile, Info.plist, polices et permissions deviennent de la configuration déclarative. Et les versions tombent juste : le SDK Expo 50 embarque React Native 0.73, soit la version que fait tourner cette application. Une migration ne s'y doublerait donc pas d'une montée de framework.

Ce que cela coûte.

  • Expo Go ne fera jamais tourner cette application. vision-camera et ML Kit sont du code natif : il faut des development builds, donc repasser par EAS à chaque changement natif. L'argument « test instantané sur téléphone » ne s'applique pas à ce produit.
  • vision-camera fournit un config plugin officiel ; image-picker et les autres ne posent pas de question. ML Kit text recognition est l'inconnue. S'il n'existe pas de plugin maintenu et qu'il faut l'écrire, l'économie de la migration s'évapore.

Recommandation : ne pas migrer vers Expo pour atteindre iOS. Le problème du Mac est déjà résolu, le projet Android fonctionne et est maîtrisé, et la migration coûterait des jours pour un bénéfice qui se réduit à « ios/ est généré au lieu d'être écrit ». Adopter Expo est une décision d'architecture défendable, à prendre délibérément — ce n'est pas un raccourci pour éviter d'acheter un matériel qu'il n'y a pas lieu d'acheter.

Ordre recommandé ​

Ordonné pour dépenser le moins d'argent possible avant le premier signal réel.

  1. Ouvrir le compte Apple Developer. Il conditionne tout le reste et sa validation prend plusieurs jours. À lancer même dans une semaine où aucun code iOS n'est écrit.
  2. Générer ios/ et le commiter. Gratuit, faisable depuis Windows, et Codemagic a besoin que le répertoire existe pour avoir quelque chose à construire. Câbler le Podfile, les polices, les permissions, l'identifiant de bundle — et corriger l'écart de resolveBackendHost dans le même changement.
  3. Pointer Codemagic sur un workflow iOS. Le premier build dira ce qui manque réellement. Cette liste ne peut pas être produite en lisant du code depuis une machine non-Mac : ne pas essayer de la devancer.
  4. Un iPhone physique et Firebase App Distribution, pour le chemin de scan.

Limites assumées de ce document ​

L'étape 2 produit un projet iOS plausible que personne n'a compilé. C'est de la préparation, pas de la validation. Il faut s'attendre à ce que le premier build Codemagic en invalide une partie : c'est son travail.

Tout ce qui concerne ML Kit sur iOS est signalé comme non vérifié, volontairement. C'est la dépendance la plus susceptible de réserver une surprise, et une surprise nommée à l'avance coûte moins cher qu'une surprise découverte en pleine migration.

Voir aussi ​