Apple rejette les apps inutiles : la réponse n'est pas d'y passer des semaines

Le 9 juin 2026, Apple a durci ses règles de validation pour écarter les apps « sans valeur ». Beaucoup y ont lu un message simple : il faudrait désormais passer des semaines sur une application pour qu'elle soit acceptée. C'est faux. Apple ne mesure pas le temps que vous y passez. Elle regarde si l'app mérite d'exister.

Ce qu'Apple a changé le 9 juin 2026

La modification principale touche la guideline 4.3(b). Apple y ajoute une phrase sans ambiguïté :

Apple nomme même les catégories qui ne seront plus acceptées sans une expérience réellement différente : rencontre, lampe torche, effets sonores, fonds d'écran, minuteur basique, voyance. Elle range les apps de bruits de flatulence, de rots, de Kama Sutra ou de jeux à boire dans la catégorie « médiocres, de faible qualité ou sans effort ».

Le critère n'est pas le temps passé

C'est le point que la plupart des commentaires ratent. Apple ne rejette pas une app parce qu'elle a été faite vite. Elle la rejette parce qu'elle n'apporte rien. Un clone de plus, même s'il vous a coûté trois semaines, se fait recaler. Une app ciblée, avec une vraie raison d'exister, construite en quatre jours, passe.

La valeur n'est donc pas une question d'heures. Vous pouvez passer un mois à peaufiner une idée qui n'intéresse personne, ou livrer en quelques jours quelque chose qui résout un vrai problème. Apple veut voir la seconde.

La clause qui change vraiment la donne

Le durcissement le plus important n'est pas le rejet à l'entrée, c'est ce qui se passe après. Apple s'autorise désormais à retirer des apps déjà publiées :

Une app peut donc être acceptée, rester en ligne, puis disparaître faute d'utilisateurs. Et un développeur qui enchaîne les apps sans intérêt risque son compte. Passer six semaines à polir une app dans le vide, sans jamais la confronter à de vrais utilisateurs, devient le pire des paris.

Une app de liste de courses, dans une catégorie saturée

J'en ai publié une cette année, et sur le papier c'est exactement le genre d'app que ces règles visent. Les listes de courses, c'est saturé. Les exemples cités par Apple parlent de lampes torches, de fonds d'écran et de minuteurs basiques, et une liste de courses habite un quartier assez proche pour qu'on hésite avant d'en faire une de plus.

Elle est passée à la première revue, sans rejet et sans un seul échange avec un examinateur.

Elle est passée parce qu'elle fait une chose que rien d'autre sur l'App Store ne fait de la même façon. TapTap Courses, c'est un écran et un tap. Vous touchez une grosse icône colorée, l'article est dans la liste. Pas de champ de recherche, pas de bibliothèque de recettes, pas d'inventaire de placards, pas de scanner de codes-barres, pas de planificateur de repas. Un enfant qui ne sait pas encore lire peut ajouter des pommes, parce que le dessin est une pomme. Elle tourne sur Apple Watch, qui est l'endroit où une liste doit être quand on a les deux mains prises.

Ce que j'ai laissé de côté, c'est tout l'argument. Les apps de courses finissent par ajouter des recettes et des menus de la semaine, parce que c'est ce vers quoi on se tourne quand il faut justifier un prix plus élevé. Chaque ajout coûte un tap, un écran ou une décision, au moment précis où quelqu'un est debout dans sa cuisine avec un enfant qui lui tire la manche. Les avoir écartées n'est pas de la paresse. C'est le produit.

C'est ça, une expérience réellement différente. Il ne s'agit pas d'inventer une catégorie, ni d'avoir plus de fonctionnalités que les autres. Il s'agit d'avoir une réponse défendable à la seule question que pose vraiment la validation : pourquoi celle-ci existe-t-elle alors que les autres sont déjà là ? Ici, la réponse est que les autres ne sont pas un tap et un écran, et ne peuvent pas le devenir, à cause de tout ce qu'elles ont choisi d'ajouter.

Pourquoi un MVP en quelques jours est la bonne réponse

Si Apple récompense l'utilité et l'usage réel, la logique est de livrer vite une version qui fait bien une chose, de la mettre entre les mains de vrais utilisateurs, puis d'itérer. Pas de la peaufiner pendant des semaines avant même de savoir si quelqu'un en veut.

Un bon MVP tient sur un noyau clair :

• Une fonction principale qui marche vraiment, pas une maquette
• De vraies fonctionnalités natives, celles qu'un simple site web emballé dans un webview ne peut pas offrir
• Un écran de réglages propre, avec confidentialité et gestion des notifications
• De quoi mesurer si les gens reviennent, pour décider quoi construire ensuite

Ce noyau se construit en quelques jours quand on sait où on va. Le reste, les fonctionnalités secondaires et les cas limites, vient après, une fois que l'app a prouvé qu'elle intéresse quelqu'un.

Rapide parce qu’expérimenté, pas rapide parce que bâclé

Il y a une nuance à ne pas manquer. « Livrer en quelques jours » n'est pas la même chose que « bâcler ». Les apps qu'Apple purge en ce moment sont justement celles qui ont été produites vite et sans savoir-faire, souvent générées par des outils de vibe coding. La vitesse ne les sauve pas, leur absence de valeur les condamne.

La différence tient à l'expérience. Après dix-huit ans à développer des applications, on sait ce qui passe la validation et ce qui se fait recaler. On sait quelles fonctionnalités natives un reviewer attend, où la guideline 4.2 coince, pourquoi une web app déguisée ne tient jamais dans la durée. On ne perd pas de temps à redécouvrir ces règles en se prenant des rejets. On construit l'app juste du premier coup.

C'est ça, livrer vite sans livrer mal. On coupe le gaspillage, pas les fonctionnalités essentielles. Le noyau n'est jamais négociable. Ce qu'on enlève, ce sont les semaines passées à peaufiner ce dont personne n'a besoin.