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.

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.