La recette d'une grande app iOS 🍳

Tu connais cette sensation. Une app que tu ouvres et qui marche — pas au sens « elle compile », mais au sens « elle te comprend ». Tout est à sa place, rien ne grince, et tu ressors en te disant « tiens, c'était agréable ». Et tu connais l'inverse : le bouton qui rame, le scroll qui saccade, la pop-up de permission qui te saute à la gorge avant même que tu aies compris à quoi sert le truc. Entre les deux, il y a un monde. Et ce monde-là, ce n'est presque jamais une ~feature~ fonctionnalité magique qui le sépare. C'est une recette.

Je publie des apps depuis les tout premiers jours de l'App Store, en 2008. Une quarantaine au compteur, des centaines de millions de téléchargements cumulés, une quinzaine de WWDC dans les pattes. Et la question qu'on me pose le plus souvent n'a pas changé d'un iota : qu'est-ce qui fait qu'une app est géniale, et pas juste fonctionnelle ? J'écris ces lignes à chaud, encore un peu sonné, depuis l'autre bout de l'année — j'étais à Apple Park pour la WWDC26, à son retour, j'ai donné un talk à deux voix avec Claire. Le talk s'appelait The Recipe to Build a Great iOS App. Voici la version longue, la recette complète, celle qu'on n'a jamais le temps de dérouler en entier sur scène.

Pourquoi une recette ?

Deux personnes avec les mêmes œufs ne font pas le même plat. C'est aussi bête que ça. En dev iOS, tout le monde a les mêmes œufs : Swift, SwiftUI, Xcode, gratuits ; des centaines de sessions WWDC en accès libre ; des tutoriels pas-à-pas ; et les Human Interface Guidelines, la bible du design Apple, dispo en un clic. Personne n'a d'ingrédient secret planqué dans son frigo. Ce qui distingue une grande app, c'est la manière d'assembler tout ça. Et ça, bonne nouvelle, ça s'apprend.

Apple le prouve chaque année. En 2026, sur plus de deux millions d'apps, seulement 12 ont décroché un Apple Design Award — choisies parmi 36 finalistes, dans six catégories. La barre est haute. Mais regarde qui la franchit : un studio de deux personnes aux Pays-Bas à côté d'une équipe qui itère depuis dix ans, un développeur solo en Inde à côté de CD Projekt Red. Le message d'Apple est limpide : le design n'est ni une affaire de budget, ni de taille d'équipe, ni d'audience. C'est une affaire de soin.

Et le plus drôle, c'est que ces apps-là, tu les utilises déjà. Tu ne sais juste pas encore pourquoi elles marchent. On va en croiser une poignée au fil de la recette — pas pour faire du name-dropping, mais parce que chacune incarne un point précis mieux qu'un long discours.

Concevoir avec intention — le but avant le code

À la WWDC26, Apple a publié une nouvelle session fondatrice, Principles of great design (session 250, dix-sept minutes, regarde-la deux fois). Elle pose huit principes : Purpose, Agency, Responsibility, Familiarity, Flexibility, Simplicity, Craft, Delight. Et Apple insiste sur un truc que les juniors détestent entendre : il n'y a pas de formule. « C'est à toi d'utiliser tes connaissances et ton intuition. » Pousser un principe peut en compromettre un autre. Arbitrer, c'est ça, le métier. Ces huit principes ne sont pas une recette à suivre à la lettre — ce sont tes ingrédients. La cuisine, c'est toi qui la fais.

Sur scène, Claire a pris quatre de ces principes et moi quatre autres. Ici je te livre les huit, dans l'ordre de la recette plutôt que dans l'ordre de la slide. Et tout commence par le plus ingrat, celui qu'on saute toujours : Purpose. La mise en place. En cuisine, c'est tout préparer avant d'allumer le feu. En design, c'est te poser la seule question qui compte avant la moindre ligne de code : est-ce que ce que je fais a un vrai but ? Si ce n'est pas net, ce n'est pas prêt.

Mon premier témoin, c'est grug — Apple Design Award 2026 (Delight & Fun), signé du studio néerlandais Ocho, deux personnes, Jip van der Velde et Michel Elings, qui bossent ensemble depuis 2012. grug, c'est une idée : une affirmation par jour, en grognements néolithiques. « only walking grug find breakthrough… sitting grug find nothing. » Zéro login, zéro cloud, zéro social. Sa force, ce n'est pas ce que les deux gars ont eu le talent d'ajouter — c'est tout ce qu'ils ont eu le courage de ne pas ajouter. (Ils ont même bricolé un moteur de police dessinée à la main et une status bar custom : leur Q&A sur le site Apple vaut le détour.) L'omission compte autant que l'ajout. Choisir ce qu'on crée, c'est décider ce qu'on n'inclut pas.

Concrètement, comment tu trouves ce but ? Tu l'écris en une phrase : [ce que ça fait] pour [qui], dans [quel moment de leur vie]. Si ta phrase a besoin d'un « et », tu tiens peut-être deux apps, pas une. Ensuite tu listes tout ce que tu pourrais construire, et tu coupes tout ce qui ne sert pas la phrase. Chaque feature qui reste doit « payer son loyer » : mérite-t-elle le temps, l'attention et la confiance qu'elle réclame ? Parce que c'est ça, le coût réel d'une fonctionnalité — pas des heures de dev, mais trois ressources rares que tu prends à l'utilisateur. Le piège junior, c'est d'ajouter parce qu'on peut (« bah, ça me prend deux heures »). Chaque ajout dilue le but. Défendre le but, c'est dire non — souvent. Test ultime : montre ta phrase à trois personnes. Si elles ne devinent pas ce que fait l'app, ton but n'est pas assez tranchant. « Planificateur visuel pour cerveaux neurodivergents. » « Sagesse quotidienne en grognements préhistoriques, sans compte. » Si tu n'y arrives pas, retourne en cuisine.

Aux commandes — et pardonné

Le deuxième principe, Agency, c'est laisser les gens agir à leur façon. Une interface ne doit jamais entraver ce que quelqu'un essaie de faire. On le laisse plonger, explorer à son rythme, sauter l'onboarding s'il en a envie, ranger l'interface comme il le sent. On guide, on ne met pas sur des rails. Plus de contrôle, plus d'engagement — ce n'est pas un slogan, c'est mécanique.

Mon témoin ici, c'est Tiimo, élu iPhone App of the Year aux App Store Awards 2025 (et déjà finaliste d'un Apple Design Award en 2024). Un planificateur visuel qui rend aux cerveaux neurodivergents le contrôle de leur temps. L'équipe est à Copenhague, l'app est utilisée par plus d'un million de personnes, et — détail qui n'en est pas un — elle est 100 % sans pub, pour toujours. Tiimo a été conçue avec des personnes concernées, pas seulement pour elles. C'est ça, donner de l'agency : ne pas décider à la place des gens.

Le corollaire d'Agency, c'est le pardon. Les gens envoient, modifient, suppriment par accident en permanence. Ta job, c'est de rendre tout ça réversible. Apple propose une hiérarchie nette pour gérer les actions risquées, de la meilleure à la pire. Undo d'abord, par défaut : tout est annulable, l'utilisateur ose puis se rétracte. Confirm ensuite, uniquement quand l'annulation est impossible (une suppression définitive, un envoi irréversible). Interrupt en tout dernier recours, pour éviter la vraie catastrophe. L'erreur classique du débutant, c'est de tout confirmer : à force de « êtes-vous sûr ? », l'utilisateur clique « oui » sans lire, et l'avertissement ne protège plus rien. Côté code, ça se traduit en trois objets que tu dois connaître par cœur : un UndoManager, un confirmationDialog, et le rôle .destructive sur tes boutons sensibles. Ce filet de sécurité ne ralentit pas l'utilisateur — il lui donne la confiance d'explorer ton app. Donc de l'adopter.

Dans l'intérêt des gens — et l'IA responsable

Le troisième principe, Responsibility, commence par la vie privée. Apple a une métaphore que j'adore : imagine un inconnu qui t'aborde dans la rue avec « donne-moi ton numéro », sans dire pourquoi. Tu ne lui ferais pas confiance une seconde. Et pourtant, des milliers d'apps font exactement ça — la pop-up de permission balancée dès le lancement, avant que tu aies compris à quoi sert le bidule. Une interface responsable attend le bon moment, ne demande que le strict nécessaire, et explique à quoi ça sert.

Le témoin parfait, c'est Be My Eyes, récompensée aux App Store Awards 2025 dans la catégorie Cultural Impact. L'app, lancée en 2015 par Hans Jørgen Wiberg — qui a lui-même commencé à perdre la vue à 25 ans —, connecte les personnes aveugles ou malvoyantes à des volontaires voyants, et plus récemment à une IA, Be My AI. Et voilà le détail qui change tout : l'accès caméra ne se déclenche que quand l'utilisateur demande de l'aide visuelle, jamais à l'ouverture. Be My AI a été co-construite avec des milliers de testeurs aveugles et malvoyants. L'IA complète l'humain, elle ne le remplace pas. C'est le modèle.

Et il faut en parler, de l'IA, parce qu'en 2026 elle est partout. iOS 27 — annoncé à cette WWDC, le dernier keynote de Tim Cook en tant que CEO — pousse Siri, Apple Intelligence et les Foundation Models on-device dans chaque recoin du système. Ces modèles tournent sur l'appareil, gratuitement, sans envoyer tes données ailleurs. C'est une opportunité énorme pour nous, devs. Mais plus tu ajoutes d'intelligence, plus la responsabilité pèse. L'exemple d'Apple est volontairement banal, et c'est pour ça qu'il frappe : une app de recettes. L'utilisateur a déclaré une allergie. Le modèle, livré à lui-même, lui suggère un plat avec l'ingrédient allergène. Ce n'est pas un bug cosmétique — c'est un danger réel. La leçon : un modèle peut produire de l'inattendu, du faux, du dangereux. Anticipe le pire, puis ajoute des garde-fous (aperçus, confirmations, disclaimers) — ou retire carrément la feature si le risque dépasse la valeur. Les garde-fous se posent dès le design, pas en patch après le rejet.

Parler la langue de la plateforme — familiarité & flexibilité

Quatrième principe, Familiarity. Ton public arrive avec une vie entière d'expérience : le monde réel, plus les conventions de toutes les autres apps qu'il utilise. Appuie-toi dessus. La corbeille = supprimer (et récupérer) ; détourne cette icône pour autre chose et tu casses la reconnaissance instantanément. Ce qui se ressemble doit se comporter pareil. Sur Mac, on ferme une fenêtre toujours en haut à gauche — l'utilisateur n'a pas à réfléchir. Pour les actions courantes, ne réinvente pas la roue : composants système d'abord. La version 2026 de cette familiarité, c'est Liquid Glass, le matériau introduit à la WWDC25 et désormais partout dans iOS 26. En code, ça se résume à .glassEffect(), GlassEffectContainer, .buttonStyle(.glass). Petit piège qui te fera perdre une soirée : un ancêtre avec .clipped() ou .mask() casse l'effet sans aucun warning. Préfère les composants système avant de saupoudrer du glass custom partout. (Les vitrines officielles d'Apple cette année, ce sont Moonlitt et Tide Guide, si tu veux voir le truc bien fait.)

Et puis il y a Flexibility : les gens utilisent ton design de façons aussi uniques qu'eux. Apple prend l'exemple de la musique — à la maison sur des enceintes, en courant avec AirPods et Watch, en voiture en mains libres : même app, trois expériences. La manière la plus concrète d'incarner la flexibilité en 2026, c'est de sortir de ton écran. Tu exposes les actions de ton app au système via les App Intents, et d'un coup elle vit dans Siri, Spotlight, les Raccourcis, les widgets, le Control Center et Apple Intelligence — sans que personne n'ouvre l'app. C'est de la découverte et de la rétention en même temps. Pour une app neuve, choisis une ou deux actions clés (« ajouter une tâche », « démarrer un timer »), donne-leur un App Intent, puis branche-les sur Apple Intelligence via les Assistant Schemas. Un vieux de la vieille, John Geleynse, appelait déjà ça « Connected » à l'ère iOS 5 : ton app doit dépasser sa propre fenêtre. La version 2026 de cette idée, ce sont les App Intents.

Les bons outils — Swift, SwiftUI, Xcode

On a l'intention, le but, les principes en tête. Place aux ustensiles. Et là, je vais te rassurer : trois suffisent pour démarrer, tous gratuits. Pas besoin de React Native, pas besoin de Flutter, pas besoin d'un backend au jour 1. Swift d'abord — un langage sûr (les optionals et le typage strict éliminent des classes entières de bugs avant même que l'app se lance), accessible et rapide. Tu n'as pas à tout maîtriser ; les generics, les actors, la concurrency viendront plus tard. Juste assez pour avancer.

SwiftUI ensuite : un framework déclaratif où tu décris ce que l'UI doit faire, pas comment la dessiner. Moins de code, et le même socle pour iPhone, iPad, Mac, Watch et Vision Pro. La preuve vivante, c'est Moonlitt — Apple Design Award 2026 (Interaction), construite par le studio italien Flipping Hues (trois développeurs rencontrés à l'Apple Developer Academy de Naples), entièrement en SwiftUI. Phases lunaires, planification photo, onboarding en quelques taps, et une intégration Liquid Glass que les juges ont saluée comme « best-in-class ». Détail magique de 2025-26 : en recompilant avec le SDK iOS 26, une app adopte automatiquement Liquid Glass. Pas besoin de tout recoder — mais fais quand même un audit visuel, parce que « automatique » ne veut pas dire « parfait ».

Le troisième outil, c'est Xcode, l'atelier complet : éditeur, simulateur, débogueur, tests, distribution. Le combo SwiftUI + Previews change la vie quand tu débutes : tu vois l'effet de chaque ligne immédiatement, sans rebuild complet. Mets un #Preview sur chaque vue non triviale, ça deviendra un réflexe. Et surtout : on n'apprend pas à cuisiner en lisant des recettes. Apple propose des parcours guidés gratuits — fais Scrumdinger en entier, l'app exemple qui couvre listes, navigation, persistance et accessibilité. Tu apprendras plus en une app finie qu'en cent vidéos regardées en accéléré.

La base — architecture & données

Un plat sans structure s'effondre. Avant de penser au craft, pose des fondations solides. Une app, c'est trois choses qui dialoguent : les vues, les données (la vérité), la navigation. Bien les poser tôt t'évite de tout réécrire dans trois mois. Le piège du débutant, c'est la donnée qui se contredit d'un écran à l'autre. La règle SwiftUI : une seule source de vérité (@State, @Observable, @Bindable), et des liaisons qui synchronisent tout le reste. Pour sauvegarder entre deux lancements, SwiftData suffit largement pour un v1 — même esprit que SwiftUI, plus de puissance et moins de code que Core Data.

Et puis il y a la maladie que je vois partout : tu lis dix acronymes d'architecture (MVVM, TCA, VIPER… ~~et autres incantations anxiogènes~~), et tu te paralyses avant d'avoir écrit une vue. Stop. Reste simple, suis le grain de la plateforme, et ne refactore que quand la douleur apparaît. Rappelle-toi : grug, c'est deux gars sans blog d'architecture. Tiimo, c'est dix ans d'itération avant le titre d'App of the Year. Une app imparfaite qui existe battra toujours une architecture parfaite jamais finie.

L'assaisonnement — ce qui sépare le correct du génial

Le plat est cuit. Place aux détails — invisibles séparément, mais qu'on sent tous ensemble. C'est le principe Craft : « l'attention au détail qui dit aux gens que tu tiens vraiment à leur expérience ». On le ressent, un produit bâclé : une porte branlante, une chemise qui se découd. Un bouton qui rame, un scroll qui saccade, des icônes mal alignées, un layout cassé à la rotation — ça paraît fragile, et du coup on doute de la qualité de tout le reste. Le craft, à l'inverse, inspire confiance. Les « matériaux » du craft, ce sont une typo nette sur tous les écrans, des couleurs qui s'adaptent clair/sombre, des animations réactives qui répondent au doigt, le tout sur des SDK fiables. Mon témoin ici, c'est (Not Boring) Camera, finaliste ADA 2026 (Visuals & Graphics) : la signature du studio, c'est l'obsession des matériaux — interface 3D, lumière dynamique, haptique et son si réalistes que tu crois tenir un appareil argentique.

Cousin du craft, Simplicity — et attention au contresens : simple ≠ minimal. Tout enfouir dans un seul endroit, c'est minimal, pas simple. Simple = sans friction, intuitif, tu trouves ce que tu cherches sans effort. Ça passe par la concision (langage clair, moins d'étapes) et par la clarté (une hiérarchie forte : ordre, espacement, contraste, pour que l'élément le plus important soit le plus évident). Parfois, simplifier, c'est même ajouter du contexte au bon endroit — le temps restant affiché sur un bouton lecture/pause. Le témoin parfait, c'est Tide Guide, Apple Design Award 2026 (Visuals & Graphics), du studio américain Condor Digital. Le sujet est d'un banal absolu — les marées — mais l'exécution est exceptionnelle : des données horaires complexes distillées en un seul graphique lisible d'un coup d'œil, avec une palette qui s'aligne sur la couleur du ciel au fil de la journée. Sujet banal, soin maniaque. C'est tout le propos.

L'assaisonnement, c'est aussi l'accessibilité — et là je vais être direct : ce n'est pas du luxe, c'est plus d'utilisateurs et une meilleure app pour tout le monde. VoiceOver, Dynamic Type, contraste suffisant, cibles tactiles d'au moins 44×44 points. Be My Eyes et Tiimo en ont fait un pilier dès la conception ; côté télé, HBO Max a même décroché un titre App of the Year 2025 sur Apple TV après avoir ajouté la langue des signes américaine. Et depuis iOS 26, il y a les Accessibility Nutrition Labels sur la fiche App Store : neuf features déclarables (VoiceOver, Voice Control, Larger Text, Dark Interface, Differentiate Without Color, Sufficient Contrast, Reduced Motion, Captions, Audio Descriptions). C'est volontaire aujourd'hui, mais ça deviendra obligatoire — alors prends de l'avance. Une seule règle d'or : audit honnête. Toutes les tâches courantes de l'app doivent être faisables avec chaque feature que tu déclares. Sinon, ne la déclare pas. (La session WWDC25 « Evaluate your app for Accessibility Nutrition Labels » te déroule la méthode.)

Et puisqu'on parle de craft, parlons performance, parce qu'en juin 2026 le signal d'Apple est sans ambiguïté. iOS 27, c'est ce que la presse a aussitôt baptisé un cru « Snow Leopard » — clin d'œil au fameux Zero New Features de 2009. Pas de feu d'artifice, mais Apple a publié une liste de plus de quarante optimisations bien réelles : lancements d'apps jusqu'à 30 % plus rapides, photos qui apparaissent 70 % plus vite après capture, AirDrop 80 % plus rapide, et un scheduler CPU réécrit qui profite à tout le parc, jusqu'à l'iPhone 11. La traduction pour toi est brutale : une app qui paraît lente sera encore plus pénalisée, par contraste. Animations fluides, lancement rapide, zéro freeze au scroll — et teste sur de vrais appareils, idéalement un iPhone 11 ou 12, pas seulement le simulateur du dernier modèle. Le craft, enfin, c'est la durée : quand de nouvelles features ou du nouveau matériel débarquent, évolue avec, et les gens se sentent soutenus. « Design is never really finished » — ce n'est pas une citation ~~Pinterest~~, c'est la réalité de toutes les App of the Year.

Le dressage et le service — tester & publier

On ne sert pas un grand plat dans une assiette sale. Avant l'App Store, il y a TestFlight : jusqu'à 100 testeurs internes (les membres de ton équipe App Store Connect) et 10 000 testeurs externes via un lien public ou par email. Le premier build externe passe une Beta App Review — une file d'attente distincte de celle de l'App Store, souvent quelques heures, parfois plus. Les retours, captures et crashs remontent directement dans App Store Connect. Et je le répète parce que personne ne le fait : teste sur de vrais appareils. Le simulateur ne reproduit ni la perf, ni la batterie, ni les vraies permissions.

Deuxième chose que les gens sous-estiment : la fiche App Store fait partie de l'app. Icône, captures, description, Privacy Nutrition Label, Accessibility Nutrition Label — tout doit refléter honnêtement ce que fait l'app. Apple est explicite là-dessus : des métadonnées trompeuses, c'est un rejet assuré (Guideline 2.3). Les captures doivent montrer l'app réelle, pas une fausse UI ni un « coming soon ». Et tant qu'on y est, lis les App Review Guidelines tôt, pas comme un mur à la fin : cinq sections (Safety, Performance, Business, Design, Legal). Si un jour tu ajoutes des achats intégrés, lis la section Business avant de coder, pas après. En 2026, Apple annonce environ 90 % des soumissions examinées sous 24 h — mais c'est surtout vrai pour les mises à jour d'apps établies. Une première soumission prend souvent 2 à 5 jours (plus en septembre et décembre, plus dans les catégories régulées : santé, finance, kids). Et traite chaque rejet comme une exigence technique précise, jamais comme un jugement : copie-colle le texte du rejet dans tes notes et corrige point par point.

Le passage à l'acte, c'est l'Apple Developer Program, 99 $/an : TestFlight, App Store Connect, certificats, push notifications, Sign in with Apple — tout est inclus. (Et pour coder sur ton propre iPhone, même pas besoin de payer : le compte développeur gratuit suffit, avec un certificat de 7 jours renouvelable. Le programme payant n'est nécessaire que pour le TestFlight externe et la publication.) Tu archives dans Xcode, tu uploades, tu soumets dans App Store Connect, tu peux même activer une phased release qui déploie progressivement sur sept jours. Et d'un coup, ton plat arrive sur 175 storefronts dans le monde. Pense la localisation tôt — au minimum la description et les captures pour tes marchés cibles.

Faire venir les clients — et garder le plat vivant

On a servi un grand plat. Mais un restaurant que personne ne trouve n'est pas un grand restaurant. L'App Store, ce sont des centaines de millions de visiteurs chaque semaine — et la visibilité, ça se mérite. La découverte, c'est de l'ASO plus du marketing, et chaque élément de ta fiche pèse sur les téléchargements. Côté indexé pour la recherche, tu as 30 caractères de titre, 30 de sous-titre, et un champ mots-clés de 100 : 160 caractères de surface SEO, à choisir au scalpel. Le nom et l'icône font la première impression ; la première ligne de la description est la plus lue (mais elle, elle n'est pas indexée — ce sont les mots-clés du champ dédié qui le sont). Choisis bien ta catégorie, et n'empile pas de mots-clés dans le titre, sous peine de rejet (toujours 2.3).

Trois leviers que beaucoup ignorent. Les Custom Product Pages : jusqu'à 70 versions de ta fiche, chacune avec ses propres captures, son texte promo et une URL unique (?ppid=…) à coller dans tes campagnes — une page « parents », une page « pro », une page saisonnière, chacune mesurée séparément, et depuis iOS 18 elles peuvent deep-linker vers le bon écran. Le Product Page Optimization : un A/B test natif dans App Store Connect qui montre des variantes d'icône, de captures ou d'app preview à un échantillon aléatoire, et te désigne une gagnante à 90 % de confiance (mesure sur au moins deux semaines). Et la triade campaign links (pour attribuer tes canaux dans App Analytics), Apple Ads (placement Today et résultats de recherche, un budget modeste suffit pour tester des mots-clés) et Featuring Nominations (un formulaire dans App Store Connect pour pitcher l'équipe éditoriale d'Apple — raconte l'histoire humaine : Be My Eyes et Tiimo en sont les modèles). Commence par une ou deux Custom Product Pages alignées sur tes plus gros canaux ; le plafond de 70, ce n'est pas un objectif.

Et une fois en ligne, le vrai travail commence. Une app n'est jamais « finie ». Tu écoutes les retours (TestFlight, avis App Store, support email), tu lis les crashs dans l'Xcode Organizer, tu livres des mises à jour régulières. Tu mesures tout dans App Analytics : conversion fiche → téléchargement, rétention J1/J7/J30, sessions, et la performance de chaque Custom Product Page. Tu réponds aux avis — surtout les négatifs, surtout les premiers : le reviewer est notifié et peut remonter sa note. Tiimo a mis dix ans avant son titre. Be My Eyes itère depuis 2015. grug, c'est deux gars qui itèrent depuis 2012. Aucune de ces apps n'est sortie parfaite. Elles ont itéré.

L'ingrédient secret

Tu attendais bien un ingrédient secret ? Il y en a toujours un. Et celui-là n'est pas un framework, pas une API, pas une session WWDC. C'est le soin. Care. L'intention à chaque étape, du premier écran jusqu'au moment où tu oses demander un paiement. C'est, au fond, Craft et Delight réunis — et le Delight, ce huitième principe difficile à définir mais qu'on reconnaît instantanément, n'est jamais des confettis collés à la fin. C'est la somme de toute la considération mise dans le produit : le résultat naturel de bien faire tous les autres principes. Identifie l'émotion que tu veux faire ressentir (détendu, confiant, enthousiaste), puis renforce-la partout. C'est ça qui transforme « ça marche » en « j'adore ».

Mes quatre témoins — grug, Be My Eyes, Tiimo, Moonlitt — n'ont pas une seule fonction en commun. Une affirmation préhistorique, une aide visuelle, un planning, une appli de phases lunaires. Mais toutes ont des gens qui s'en sont vraiment souciés. La seule chose qui compte, au bout du compte, c'est à quel point ton app répond aux besoins des humains pour qui tu la fais. Le reste, c'est de la technique. Et la technique, ça s'apprend.

Alors le meilleur conseil que je puisse te donner tient en deux mots : viens cuisiner. Ouvre Xcode aujourd'hui, prends un tutoriel Apple, fais une petite app — même bête, même moche. Une app décrite en une phrase, une beta TestFlight envoyée à trois amis, une fiche App Store honnête. Boucle le cycle entier une fois ; vise ça, pas la perfection. C'est ce qu'on se répète à chaque meetup de la communauté ⌘+F, et c'est ce qui fait la différence entre ceux qui « vont s'y mettre » et ceux qui shippent.

Et si t'as un projet exceptionnel, contacte-moi. Innover, c'est ce qui me fait vibrer.

Pour aller plus loin

Côté design, garde sous le coude les Human Interface Guidelines (gratuites, vivantes, enrichies d'une nouvelle page Design principles à la WWDC26) et la session Principles of great design. Côté code, Swift, SwiftUI, les App Intents et les tutoriels Apple. Côté distribution, TestFlight, les App Review Guidelines et les Custom Product Pages. Et pour l'inspiration, rien ne vaut les pages Apple Design Awards et App Store Awards 2025 — plus les fiches des apps citées, là où les juniors voient le travail de près. Merci à Claire pour la moitié de cette recette. À toi de cuisiner. 🍳