Apple serre la vis sur les apps de « Vibe Coding » : Replit et Vibecode dans le viseur
Apple serre la vis sur une nouvelle génération d’applications dopées à l’IA : les outils de « vibe coding ». Des services comme Replit ou Vibecode n’ont plus le droit de publier des mises à jour tant qu’ils n’ajustent pas certaines fonctionnalités jugées incompatibles avec les règles de l’App Store, a fait savoir Apple à The Information. La décision, discrète, intervient alors que ces apps gagnent en popularité auprès d’utilisateurs capables de créer sites et des mini-applications à partir de simples instructions en langage naturel.
Ce qui coince : l’exécution de code et les prévisualisations intégrées
Une règle de longue date pose ici problème : une application iOS ne doit pas exécuter du code téléchargé qui modifierait sa propre logique ou celle d’autres apps. Or, les plateformes de vibe coding génèrent souvent une application puis l’affichent directement dans leur interface, via une vue web intégrée. C’est précisément ce comportement qu’Apple demanderait d’adapter.

Malgré cette restriction assez sévère, un compromis se dessine malgré tout : au lieu de prévisualiser le contenu généré en interne, Apple serait plus enclin à valider les mises à jour si les apps ouvrent les projets dans un navigateur externe. Dans le cas de Vibecode, Apple exige en outre de retirer la capacité de générer des logiciels spécifiquement destinés aux plateformes Apple.
Des pression sur les validations… pour mieux protéger Xcode ?
Ces outils peuvent aussi produire des applications qui fonctionnent en dehors de l’écosystème App Store, tout en brouillant la frontière avec les outils maison comme Xcode. En toile de fond de cette polémique, des développeurs pointent une hausse des soumissions et des délais de validation plus irréguliers depuis quelques temps. Replit, par exemple, aurait reculé dans les classements des outils développeurs depuis l’absence de mises à jour récentes. Apple s’appuierait-il sur une conception extensive des règles de l’App Store pour mieux protéger son SDK Xcode ? On est en droit de se poser la question…
