Créer sa première application iPhone avec Codex, même sans savoir coder

Des gens qui n'ont jamais écrit une ligne de code arrivent maintenant à créer une vraie app iPhone.

Pas une landing page déguisée.

Une app que tu peux ouvrir sur ton téléphone, tester, casser, corriger, puis envoyer sur TestFlight.

Et oui, c'est un peu violent.

Mais il faut être clair : Codex ne rend pas ton idée bonne. Codex ne remplace pas ton goût produit. Codex ne va pas magiquement comprendre les règles de l'App Store à ta place.

Par contre, pour passer de "j'ai une idée" à "j'ai un prototype dans ma main", la barrière est devenue ridicule.

Le workflow simple : idée, Expo, Codex, test iPhone, polish, puis seulement après TestFlight

Le vrai changement

Avant, créer une app iPhone voulait souvent dire : Xcode, certificats, Swift, simulateur, erreurs Apple incompréhensibles, et une envie raisonnable de jeter ton Mac par la fenêtre.

Aujourd'hui, tu peux commencer beaucoup plus simple.

Tu prends Expo.

Tu prends Codex.

Tu prends une idée volontairement petite.

Et tu fais tourner le truc sur ton iPhone avec Expo Go avant même de parler de production.

Ne choisis pas une idée de génie

Mauvaise idée : "je veux créer Uber, mais pour les coachs sportifs, avec IA vocale, marketplace, abonnement et notifications intelligentes".

Non.

Pas pour une première app.

Prends un truc presque bête :

• un habit tracker ;
• une app de citations ;
• un minuteur de sport ;
• une liste de recettes ;
• un journal de gratitude ;
• un suivi de lecture.

Dans la vidéo, je pars sur un habit tracker.

C'est parfait parce que la boucle est claire : créer une habitude, la cocher, voir ce qui est fait, archiver ce qui ne sert plus.

Pas besoin de 48 features.

Tu veux une boucle.

Le prompt qui évite l'app floue

Le piège classique, c'est de dire :

Crée-moi une app habit tracker.

Et après tu t'étonnes que Codex te sorte un truc générique.

Bah oui.

Tu as donné une demande générique. Tu récupères une app générique. Business model de la flemme.

Le premier prompt doit forcer Codex à poser les bonnes questions :

Je veux créer une première application iPhone très simple avec Expo et React Native.

L'idée : un habit tracker minimaliste.

L'utilisateur doit pouvoir créer une habitude, définir une durée indicative, la cocher chaque jour, voir les habitudes terminées et archiver celles qu'il ne veut plus suivre.

Avant de coder, pose-moi toutes les questions nécessaires pour clarifier le produit, l'interface, les données et les comportements importants.

Réponds en français.

Tu ne demandes pas du code.

Tu demandes de la clarté.

Et c'est souvent ça qui manque le plus.

Le setup minimum

Pour faire simple, tu as besoin de trois outils :

• Codex Desktop pour piloter le projet ;
• Bun pour créer et lancer l'app ;
• Expo Go sur ton iPhone pour tester vite.

Installe Bun :

curl -fsSL https://bun.sh/install | bash

Puis crée un dossier propre :

mkdir -p ~/developer/app
cd ~/developer/app

Pas Desktop/test-final-final-v7.

Respecte-toi deux minutes.

Crée une app Expo

Pour une première app mobile, Expo est le chemin court.

Tu lances :

bun create expo --template default

Donne un nom simple :

habit-tracker-codex

Puis ouvre ce dossier dans Codex.

L'objectif n'est pas encore d'avoir ton produit.

L'objectif est de vérifier que ton pipeline marche : projet créé, serveur lancé, QR code scanné, app ouverte sur iPhone.

bun run dev

Tu scans avec Expo Go.

Si l'app par défaut s'ouvre, tu as déjà gagné une étape énorme.

Le téléphone est dans la boucle.

Ajoute des skills, mais pas un sapin de Noël

Les agents IA deviennent meilleurs quand tu leur donnes de bonnes instructions.

Pas quand tu empiles 72 skills au hasard pour te sentir productif.

Pour ce workflow, je garderais surtout :

• un skill React Native / mobile ;
• un skill de clarification produit ;
• un skill de polish UI ;
• éventuellement un skill pour l'icône ;
• plus tard, un skill App Store Connect.

Le skill de clarification est probablement le plus important.

Il force l'agent à demander :

• les données sont locales ou synchronisées ?
• une habitude peut être archivée ?
• il y a un historique ?
• l'app est en français ?
• quel style iOS ?
• quels états vides ?

C'est chiant cinq minutes.

Ça évite deux heures de correction derrière.

Demande le prototype, mais impose le goût

Une fois le besoin clair, tu peux demander à Codex de construire.

Mais tu ne dis pas juste "go code".

Tu cadres.

Maintenant, implémente le prototype complet de l'application.

Contraintes :
- React Native avec Expo.
- Interface en français.
- Style iOS moderne, sobre, natif, pas de design cartoon.
- Utilise des composants simples et maintenables.
- Les habitudes sont booléennes : soit faites, soit non faites.
- L'utilisateur peut créer, cocher, voir et archiver une habitude.
- Ajoute des états vides propres.
- Garde le code lisible pour un débutant.

Quand tu as terminé, explique-moi comment lancer et tester l'application sur iPhone avec Expo Go.

Le mot important ici, c'est contraintes.

Avec l'IA, tu ne tapes plus chaque ligne.

Tu pilotes.

Et piloter, ce n'est pas être vague avec assurance.

Teste sur iPhone, pas dans ta tête

Une app mobile ne se juge pas dans un fichier.

Elle se juge dans la main.

Teste vraiment :

• créer une habitude ;
• cocher une habitude ;
• archiver ;
• revenir en arrière ;
• fermer et relancer ;
• ouvrir le clavier ;
• tester un texte trop long ;
• cliquer partout.

Si tu as une erreur, tant mieux.

Tu viens de trouver un truc réel.

Envoie à Codex :

Voici l'erreur que j'obtiens sur iPhone avec Expo Go :
[COLLE L'ERREUR]

Corrige le problème, explique la cause probable, puis relance les checks nécessaires.

Et pour le design :

L'interface fonctionne, mais elle ne ressemble pas assez à une vraie app iOS.

Améliore les radius, les espacements, les couleurs, les ombres, la hiérarchie typographique et les états pressés.

Je veux un rendu moderne, sobre, natif, pas un style coloriage.

Voilà le vrai workflow : générer, tester, corriger, tester, polish, retester.

Pas prier devant le premier résultat.

Le polish n'est pas optionnel

Un prototype peut être simple.

Il ne doit pas faire cheap.

Sur mobile, les détails qui trahissent une app IA sont toujours les mêmes :

• boutons trop petits ;
• espacements bizarres ;
• texte trop long ;
• clavier qui casse l'écran ;
• états vides inexistants ;
• couleurs random ;
• animations molles ;
• style pas du tout natif.

Demande une passe dédiée :

Fais une passe de polish iOS uniquement.

Ne change pas les fonctionnalités.

Améliore l'interface pour qu'elle ressemble à une app iPhone moderne : espacements, typographie, boutons, cards, tabs, feedback utilisateur, états vides et cohérence visuelle.

À la fin, liste exactement ce que tu as changé.

Cette passe fait souvent la différence entre :

"marrant, l'IA a fait un truc"

et :

"ok, je peux montrer ça à quelqu'un".

TestFlight, c'est l'étape d'après

Quand ton prototype tourne, tu peux commencer à parler d'icône, de screenshots, de TestFlight et d'App Store Connect.

Mais pas avant.

Sinon tu fais la pire erreur : optimiser la publication d'une app qui n'a pas encore de boucle solide.

Pour l'icône, tu peux demander :

Génère une icône d'application simple pour ce habit tracker.

Style : minimaliste, premium, lisible en petit, cohérent avec une app iOS.

Évite les détails trop fins.

Installe les assets au bon endroit dans le projet Expo.

Ensuite seulement, tu gères la vraie plomberie Apple :

• compte Apple Developer ;
• bundle identifier ;
• certificats ;
• screenshots ;
• privacy policy ;
• description ;
• permissions ;
• review ;
• TestFlight.

L'IA peut aider énormément.

Mais Apple reste Apple.

Malheureusement.

Les erreurs à éviter

La première erreur : croire que sans coder veut dire sans réfléchir.

Non.

Tu réfléchis encore plus au produit, tu délègues juste une grosse partie de l'exécution.

La deuxième : choisir une app trop grosse.

Tu n'as pas besoin de dix features.

Tu as besoin d'une boucle qui marche.

La troisième : accepter le premier design.

L'IA sort souvent un truc fonctionnel, mais plat. Ton job, c'est de dire : plus natif, plus sobre, moins coloriage.

La quatrième : ne pas tester sur téléphone.

Une app mobile se juge dans la main.

La cinquième : parler d'App Store alors que ton prototype est encore fragile.

C'est romantique.

Mais c'est idiot.

Checklist avant de dire que c'est prêt

Avant de montrer ton prototype, vérifie :

• l'app se lance avec bun run dev ;
• Expo Go ouvre bien le projet ;
• l'action principale marche ;
• les états vides sont clairs ;
• le clavier ne casse rien ;
• les boutons sont touchables ;
• les textes sont cohérents ;
• le design ne fait pas démo cheap ;
• Codex a corrigé les erreurs visibles ;
• tu as noté les limites.

Si tu coches ça, tu n'as plus juste une idée.

Tu as un prototype testable.

Et c'est déjà énorme.

La suite

Si tu veux aller plus loin, apprendre React Native, Expo, les bases de TypeScript et le workflow de publication devient beaucoup plus concret une fois que tu as déjà une app devant toi.

C'est pour ça que j'aime ce workflow.

Tu ne passes pas six mois à apprendre une syntaxe avant de toucher quelque chose.

Tu construis, tu touches, tu comprends, tu corriges.

Si tu veux le guide complet, les ressources, les skills et le workflow mobile plus avancé pour passer d'un prototype à une vraie app publiable, j'ai préparé une formation mobile complète ici : https://mlv.sh/rqkFR8v.

La vidéo complète

Je te mets la vidéo ici si tu veux voir le workflow en action, avec les étapes et les erreurs réelles.