Apple a bloqué les mises à jour de Replit et Vibecode sur l’App Store à cause de fonctions de vibe coding

Apple a temporairement arrêté la publication des mises à jour pour plusieurs applications liées au vibe coding, notamment Replit et Vibecode. D'après la description de la situation, les réclamations de l'entreprise concernent des fonctionnalités spécifiques qu'elle a jugées incompatibles avec les règles de l'App Store.

Ce qui s'est passé

Ce sont précisément les nouvelles versions des applications qui ont été bloquées, pas l'idée du développement mobile avec l'IA. C'est une distinction importante : Apple n'a pas déclaré la guerre à tout le segment, mais a montré qu'elle surveille attentivement comment ces produits sont structurés en interne. Pour les services qui promettent de générer, exécuter et affiner du code avec une participation minimale de l'utilisateur, iOS a longtemps été une plateforme difficile en raison de règles strictes concernant l'exécution du code et les modifications du comportement de l'application après la modération.

Replit et Vibecode sont devenus des exemples notables car les deux services vendent l'idée du développement « depuis votre téléphone et par description ». Un utilisateur formule une tâche en langage naturel, reçoit un modèle de projet et peut ensuite modifier l'interface, la logique et la structure des fichiers. Pour un public de masse, c'est ce que signifie le vibe coding : moins d'ingénierie manuelle, plus de dialogue avec le modèle et des itérations plus rapides.

L'histoire est importante aussi parce que les clients mobiles sont devenus pour ces plateformes non seulement un complément du web, mais une partie de l'entonnoir principal. Via l'iPhone, il est plus facile de montrer la magie du produit : ouvrir l'application, décrire son idée, obtenir un prototype. Si ce scénario exact commence à entrer en conflit avec les règles de l'app store, les entreprises doivent repenser non seulement l'interface, mais toute la logique d'intégration, de monétisation et de rétention des utilisateurs.

Où surgit le conflit

La formulation exacte des réclamations d'Apple n'est pas révélée dans la publication, mais la logique du conflit est claire. L'App Store a historiquement méfié des scénarios où une application devient une couche pour un environnement d'exécution externe ou gagne la capacité de changer radicalement les fonctionnalités après l'approbation de l'équipe d'examen. Quand un outil d'IA non seulement écrit du texte, mais assemble des interfaces, exécute du code, connecte des services tiers et affiche les résultats dans un client mobile, il commence à entrer sur un territoire où les règles d'Apple sont particulièrement strictes.

Le problème ici, probablement, n'est pas le fait de la génération de code en soi, mais le degré d'autonomie. Une chose est un assistant de chat qui propose un fragment de composant React. Une autre est un produit qui construit une application fonctionnelle à partir d'une seule instruction, permet de l'exécuter et change le comportement du service presque en temps réel. Pour l'App Store, ce n'est plus seulement un éditeur, mais potentiellement une nouvelle plateforme au sein d'une plateforme, et Apple tente traditionnellement de garder de tels scénarios sous contrôle total.

Pour de tels produits, la zone de risque élevé ressemble généralement à ceci :

• génération et exécution de code utilisateur directement à partir d'un client mobile
• modifications à distance du comportement de l'application sans examen séparé de chaque nouvelle fonctionnalité
• accès à des interpréteurs, compilateurs ou conteneurs externes cachés à la modération
• scénarios où l'IA crée des mini-applications complètes dans une enveloppe déjà publiée

Ce qui se passera ensuite

Le scénario le plus probable est que les développeurs suppriment ou déplacent les fonctionnalités controverses en dehors de l'application iOS. Par exemple, ils peuvent conserver un client de chat, la visualisation des projets et l'édition de base dans l'App Store, mais déplacer la génération complète de code, le déploiement ou l'exécution vers la version web. C'est un compromis typique pour les plateformes Apple : une application mobile devient une vitrine et une télécommande, tandis que les fonctions les plus sensibles vivent dans un navigateur où les restrictions de l'App Store ne s'appliquent pas.

Pour les utilisateurs, cela signifie moins une perte de service qu'un ralentissement du rythme. Les nouvelles fonctionnalités peuvent être lancées d'abord dans le navigateur, le bureau ou via TestFlight, et atteindre l'App Store plus tard et sous une forme réduite. Pour les entreprises elles-mêmes, le risque est plus élevé : le marché du vibe coding croît actuellement précisément grâce à la promesse de « construire une application en quelques minutes », et toute restriction de plateforme brise cet effet de simplicité sur lequel l'entonnoir de croissance est construit.

Un coup supplémentaire frappe les startups qui construisent des produits autour de l'UX mobile et de l'effet wow rapide. Si les scénarios critiques ne peuvent pas être légalement empaquetés dans une application iOS, elles devront expliquer aux utilisateurs pourquoi la « vraie magie » ne commence qu'après avoir basculé vers le navigateur. Cela augmente la friction, réduit la conversion et élargit l'écart entre l'apparence du produit dans une publicité et son fonctionnement sur un appareil réel.

Ce que cela signifie

Apple a montré qu'elle était prête à freiner même les produits d'IA populaires s'ils s'approchaient trop des scénarios interdits pour iOS. Pour le marché, c'est un signal : l'avenir du vibe coding dépend non seulement de la qualité des modèles, mais aussi de la façon dont les services emballent soigneusement la génération de code, l'exécution et la publication conformément aux règles des principales plateformes mobiles.