Chapitre 15.1 — 🍏 Ce qui change pour iOS

Où on en est : Drill est une app Android aboutie — écrite en cross-platform. Ce chapitre déroule, théoriquement mais complètement, le jour où vous décideriez de la porter sur iPhone. Spoiler : le code est le plus petit des sujets.

⏱️ TL;DR — Le code : ~95 % identique (nos Platform.select et le langage iOS des composants sont déjà là). Le reste change : compte Apple Developer 99 $/AN, builds iOS via EAS cloud (pas besoin de Mac pour BUILDER — mais sans Mac ni iPhone, impossible de TESTER sérieusement), TestFlight pour la bêta, review App Store plus stricte (guidelines design), et des équivalences à connaître (APK→IPA, AAB→App Store Connect, keystore→certificats gérés par EAS).

🎯 Objectifs

• Chiffrer le ticket d’entrée iOS (argent, matériel, temps).
• Connaître le pipeline EAS iOS depuis Windows (et sa limite de test).
• Mapper chaque concept Android du cours sur son équivalent Apple.
• Auditer Drill : qu’est-ce qui demanderait une retouche iOS réelle ?

Le ticket d’entrée

La ligne qui décide : le test. EAS builde l’IPA depuis Windows sans problème — mais développer pour une plateforme qu’on ne peut pas VOIR est une impasse (le simulateur exige un Mac ; un iPhone physique + build TestFlight est le minimum viable). Verdict pratique : le portage iOS devient raisonnable le jour où vous avez (a) un iPhone sous la main et (b) une app qui le mérite (demande réelle, monétisation — P17). Pas avant.

Le pipeline depuis Windows

eas build --profile production --platform ios    # oui, depuis Windows
eas submit --platform ios

Ce qu’EAS absout : la gestion des certificats — le pendant iOS du keystore, en pire (certificats de distribution, provisioning profiles, renouvellements ANNUELS). EAS génère, stocke, renouvelle : vous répondez à deux questions au premier build et n’y pensez plus. C’est, avec le build-sans-Mac, l’argument iOS le plus fort d’Expo.

Le circuit complet : eas build (IPA signé) → eas submit (App Store Connect — le « Play Console » d’Apple) → TestFlight (la bêta : installez sur VOTRE iPhone, invitez jusqu’à 10 000 testeurs par lien, review légère de 24 h pour la bêta elle-même) → soumission App Store → review complète → publication. Les OTA EAS Update : identiques (le channel sert les deux plateformes — un seul eas update met à jour Android ET iOS).

Les équivalences — le dictionnaire

Remarquez la symétrie des contraintes : Google fait payer en testeurs (test fermé), Apple en dollars et en review — chaque jardin a son péage.

L’audit iOS de Drill

Ce que NOTRE code demanderait réellement — la revue honnête :

• Rien à faire : Expo Router, Zustand, TanStack Query, SQLite, Reanimated, gestes, notifications locales, OTA — tout est cross-platform par construction.
• Déjà prêt (on l’a écrit en passant) : les ombres (Platform.select, ch. 3.6), le KeyboardAvoidingView behavior (ch. 3.5), le feedback pressed sans ripple (ch. 3.3 — android_ripple ignoré, l’opacité prend le relais).
• Retouches réelles : l’icône (version carrée sans transparence), le splash (formats), tester la safe area de la Dynamic Island (notre useSafeAreaInsets la gère — à VÉRIFIER visuellement), et les haptics (le Taptic Engine rend mieux — tant mieux).
• Le questionnaire d’Apple : Privacy Labels (copie du Data Safety), et la review design (Human Interface Guidelines — Drill, sobre et standard, passe sans frayeur).

Estimation totale pour Drill : 2-3 jours de travail + les délais administratifs. C’est la récompense du « code cross-platform, chaîne Android » décidé au premier jour : l’option iOS reste ouverte, à coût borné, sans avoir jamais ralenti le développement.

⚠️ Piège — Le piège du portage n’est pas technique : c’est l’engagement récurrent. 99 $/an + un target iOS à suivre + une review par mise à jour + tester sur un matériel qu’on n’utilise pas au quotidien : pour une app perso, c’est un LOYER permanent. La question n’est jamais « puis-je porter ? » (oui, facilement) mais « cette app justifie-t- elle un loyer annuel ? ». Pour un quiz perso : non. Pour l’app monétisée de la P17 : peut-être — les utilisateurs iOS paient statistiquement plus.

💡 Pour un dev Next.js — L’analogie qui remet les idées en place : ajouter iOS, c’est moins « supporter Firefox en plus de Chrome » que « déployer sur un second cloud avec son propre contrat commercial ». Le code est portable ; l’OPÉRATION est dupliquée. D’où la doctrine du cours : cross-platform dans le code (gratuit), mono-plateforme dans l’opération (jusqu’à preuve de besoin).

✏️ Exercices

1. Faites l’audit iOS de VOTRE version de Drill : grep les Platform., listez les endroits déjà bi-plateformes, et les 3 points qui demanderaient une vérification visuelle sur iPhone.

2. Établissez le budget an-1 d’un portage iOS de Drill (argent + heures), puis le seuil de rentabilité si Drill était monétisé (P17) à 2 € de LTV moyenne par utilisateur iOS.

3. Sans Mac ni iPhone : jusqu’où pouvez-vous PRÉPARER le portage aujourd’hui, à coût nul ? Listez les 5 gestes.

🧠 Quiz

1. Peut-on builder pour iOS sans Mac, et que manque-t-il alors ?

2. Quel est l’équivalent iOS du keystore, et qui le gère ?

3. TestFlight vs le test fermé Google : la différence clé ?

4. Un eas update touche-t-il les deux plateformes ?

5. Formulez la doctrine du cours sur iOS.

👉 Chapitre suivant : 15.2 — Expo pour le web — la même app en site : la promesse et le verdict.