Apple blokkeert updates van vibecodingapps voor schenden van App Store-beleid

Apple laat vibecodingapps als Replit en Vibecode geen updates meer uitbrengen in de App Store. Deze apps zouden de voorwaarden van de App Store schenden. Apple zou niet willen dat het mogelijk is om gevibecodede software binnen deze apps te testen en om iOS-apps te genereren.

Bepaalde functies van vibecodingapps zijn in strijd met de algemene voorwaarden van de App Store, laat Apple weten aan The Information (via 9to5Mac). Het gaat onder meer om onderdeel 2.5.2 van deze voorwaarden, die voorschrijft dat apps geen uitvoerbare code mogen installeren of starten die de functionaliteit van de app kan aanpassen.

Veel vibecodingapps, waaronder Replit, laten gebruikers hun gevibecodede software ter plekke uitproberen, maar deze functie gaat dus in tegen het App Store-beleid. Daarnaast meldt The Information dat de app Vibecode een specifieke functie heeft waarmee gebruikers apps voor Apple-apparaten kunnen genereren. Ook dat zou Apple tegen de haren instrijken. Het bedrijf biedt deze mogelijkheid zelf aan in zijn ontwikkeltool Xcode.

Apple keurt geen updates meer goed van Replit en Vibecode, totdat ze hun apps aanpassen. Dat zou in het geval van Replit kunnen door de previews van gevibecode software in een externe browser te laten plaatsvinden, in plaats van in de app zelf. Vibecode moet naar verluidt de functie verwijderen waarmee gebruikers apps kunnen maken voor Apple-apparaten. Ingewijden laten aan The Information weten dat beide apps al updates ter goedkeuring naar Apple hebben gestuurd en dat laatstgenoemde op het punt staat om de blokkades op te heffen.

Replit

Reacties (30)

[kozue]

Nou ben ik geen fan van vibecode brolwerk, maar dit is wel weer een typisch gevalletje Apple. Ze willen geen concurrentie op hun eigen ontwikkelomgeving dus gaan ze de rest maar blokkeren. Blijkbaar is er nog niet genoeg regelgeving om de macht van dit soort bedrijven over de apparaten van gebruikers in te perken.

[RefriedNoodle]

Nou ben ik geen fan van vibecode brolwerk, maar dit is wel weer een typisch gevalletje Apple. Ze willen geen concurrentie op hun eigen ontwikkelomgeving dus gaan ze de rest maar blokkeren. Blijkbaar is er nog niet genoeg regelgeving om de macht van dit soort bedrijven over de apparaten van gebruikers in te perken.

De regel dat iOS apps geen custom code mogen laden of runnen, bestaat anders langer dan de term 'vibecoding'. Ik weet niet beter dan dat deze regel er al sinds het begin van de App Store is.

Enigzins logisch, aangezien dergelijke functionaliteit het hele verdienmodel van de appstore potentieel onderuit kan halen.

[Lord Anubis]

Heeft meer met veiligheid te maken dan het verdienmodel lijkt me.

[frusty]

Deze beperkingen is er altijd al geweest en is bedoeld om te kunnen garanderen dat apps zich aan de regels blijven houden na release. Als apps dynamisch zouden zijn, is de kans veel groter op security issues.

Dit heeft dus niet ineens iets met concurrentie voor xcode te maken.

[Ablaze]

Als je er langer over nadenkt snijdt het alsnog geen hout.


Een app kan niet zomaar zelf nieuwe code genereren met grove security issues voor een iPhone, want alles dat draait in die app zit in een sandbox en is gebonden aan de restricties van de app zelf, die zijn gereviewed door apple.

Daarnaast genereert deze app voornamelijk js code. Je zou dan kunnen beargumenteren dat browsers ook uit de app store verwijderd moeten worden.

[b12e]

Een app kan niet zomaar zelf nieuwe code genereren met grove security issues voor een iPhone, want alles dat draait in die app zit in een sandbox en is gebonden aan de restricties van de app zelf, die zijn gereviewed door apple.

Het gaat niet noodzakelijk om enkel security. Als die app achteraf ineens een Gameboy emulator kan zijn, of porno app, om maar iets te noemen, dan is het ook tegen de regels van de App Store.

Verder is een sandbox niet waterdicht, in het verleden zijn er al zero days geweest om uit die sandbox uit te geraken.

[Ablaze]

Het is natuurlijk niet zo dat je Vibecode start en het ineens een gameboy emulator is. En ook al verzoek je Vibecode om dat te maken, dan nog kan de app je code alleen maar genereren, previewen en exporteren. Niet zelf als een native applicatie uitvoeren.

Deze dingen kun je ook gewoon in een mobiele browser. Waarom zou het ene gevaarlijk en ongewenst zijn en het andere niet?

[telenut]

En dat eerste is volgens mij exact de reden waarom men het niet wil...

[Lord Anubis]

Er zijn dus verschillende vormen van beveiliging. In een sandbox kunnen er toch ook dingen gebeuren.

[Finraziel]

Dat gaat misschien op voor Replitt, maar niet voor Vibecode waar volgens het artikel het probleem is dat Apple niet wil dat je apps voor Apple apparaten kunt genereren.

[adje123]

Ik snap het wel. Apple snapt dat iedereen tegenwoordig met Vibecode een app kan maken en het in de playstore kan zetten. Dat is pas een risico

[kozue]

In het artikel staat dat ze dat met Xcode wel kunnen. En volgens mij kunnen deze apps geen gegenereerde apps in de store zetten?

[LOTG]

Ik begrijp waar je op doelt, en ben zelf geen fan van het concept maar deel je mening niet.

Waarom is het veiliger als het via XCode verloopt? Het blijft code waar de gebruiker misschien wel of niet van weet wat het doet en hoe het werkt.

Het kan dus net zo goed brakke code zijn vol vulnerabilities en back doors.
Tevens kan dit ook gebeuren zonder AI.

Het uiteindelijke resultaat moet door Apple hun keuring voor het de store in mag.

[adje123]

Volgens mij is xcode uitgerust met allerlei tools om erover te zorgen dat je app App Store compliment is.

[willieverhoef]

En toch worden er apps afgekeurd.

[jbhc]

Zou het Apple echt veel uitmaken of die apps in de playstore komen?

[Lord Anubis]

Meer voor de veiligheid van gebruikers. Vind het niet verkeerd van Apple, je weet maar nooit wat de ontwikkelaar bij een latere release gaat uitvoeren.

[jbhc]

Volgens mij snap je niet welk punt ik probeer te maken

[SuperDre]

Je mag nog steeds gewoon gevibecode apps uitbrengen op de store, maar je mag niet deze apps, waarmee je op iOS zelf IN die app een andere app kunt bouwen en testen.

[lenwar]

dit is een blokkade voor de App Store. De betreffende apps kunnen dus wel in een andere appmarktplaats geplaatst worden.

[Sorcerer8472]

Maar in Xcode mag het wel?

Lijkt me weer een gevalletje EU-boete incoming dan!

[lenwar]

De betreffende apps kunnen natuurlijk ook in een andere appmarktplaats gaan zitten. Deze beperking is van de App Store. Niet van de rest van Apple.

[DLeijen]

Xcode draait enkel op macs, niet op iPhones of iPads.

[telenut]

Je hebt dus al een mac nodig als je een app wil maken??

[WhatsappHack]

Nee.

[apulmoes]

De  App Store heeft altijd volgestaan met legio apps die één of meerdere App Store guidelines overtreden. Soms wordt een app pas op de vingers getikt nadat meerdere voorgaande versies (kennelijk) goedgekeurd waren. Soms wekt dat de indruk dat het afhangt van welke reviewer er naar de App Store submission kijkt, maar het zou goed kunnen dat Apple ook interne review guidelines uitdraagt.

Apple heeft er belang bij dat er voldoende apps zijn die vergelijkbaar zijn, zodat de klant wat te kiezen heeft — smaken verschillen — dan kopen ze eerder wat. Dat zal altijd balanceerwerk zijn, want wie zit er nu te wachten op tientallen flappybird-klonen? iOS tutorial overtikken, googlen hoe je een app submit …en voìla!

Apple verdient ook aan Apple Developer Accounts en macs — al heb je geen gloednieuwe dure mac nodig om iets te builden en releasen. ¯\_(ツ)_/¯

[b12e]

Soms wekt dat de indruk dat het afhangt van welke reviewer er naar de App Store submission kijkt, maar het zou goed kunnen dat Apple ook interne review guidelines uitdraagt.

Dit is redelijk normaal bij menselijke reviews. Je kan je mensen nog zo trainen, de een gaat altijd beter zijn dan de ander.

Als voorbeeld heb ik vanmorgen 3x gebeld naar een luchtvaartmaatschappij. De eerste moest ik alles 3x herhalen (en het cijfer acht kende ze niet, a la 'what is eight, I no know what is' ), de tweede wilde me 65€ extra aanrekenen bovenop het verschil in prijs van het ticket, en de derde persoon had op 5 minuten klaargespeeld voor €5 waar ik al 3 kwartier voor aan het bellen was en wat ik online niet kon doen.

HUCA (Hang up, Call again) is net zo goed van toepassing op App Store reviews.

[Reactie gewijzigd door b12e op 18 maart 2026 21:12]

[Niema]

Blokkeert 2.5.2 dan ook het gebruik van browser extensies, zoals safari's adblock plus adblocker en safari's userscript manager die zijn te installeren vanaf de app store?

[telenut]

Typisch apple zeker?
Ik heb op 2 weken tijd 2 apps zelf gemaakt voor Homey, zuiver vibecoding! Hier ga ik andere mensen ook een plezier mee doen! Dus geen idee waarom zo veel mensen iets hebben tegen vibecode.
Ik denk dat ze hier vooral bang zijn dat je op die manier dus gelijk welke app kan maken en draaien op een Iphone, ook het soort apps waar Apple niet blij mee is.

[wiseger]

Dat is niet correct. Apple bepaald niet hoe jij je code schrijft. Het eindtesultaat moet echter eerst door de keuring heen voordat de app in de Apple Store wordt toegelaten.

Hier gaat het om apps die reeds in de Apple Store staan die dynamisch hun code wijzigen. Die gewijzigde code is nimmer goedgekeurd. Dat staat Apple niet toe.