Safe by design: waarom Buildy Apple's 2.5.2 overleeft

In maart 2026 begon Apple Guideline 2.5.2 te handhaven tegen AI-app-builders. Buildy is zo ontworpen dat de regel niet van toepassing is op de apps die je ermee bouwt.

In maart 2026 begon Apple Guideline 2.5.2 te handhaven tegen AI-app-builders. Volgens berichtgeving van MacRumors en 9to5Mac blokkeerde het updates voor de apps van Replit en Vibecode en haalde het de app Anything (voorheen Create.xyz) volledig uit de store. De handhaving rolde geleidelijk over de maand uit in plaats van in één klap, en sommige statussen verschoven daarna — Anything keerde later terug en Replit hervatte het publiceren. De regel erachter was App Store Review Guideline 2.5.2.

Wat 2.5.2 echt zegt

De guideline is kort: apps "mogen geen code downloaden, installeren of uitvoeren die features of functionaliteit van de app introduceert of verandert." In gewone taal: een app op een telefoon moet self-contained zijn. Hij mag niet tijdens runtime nieuwe code ophalen en die uitvoeren.

Dat is precies wat de teruggetrokken builders deden. Het patroon was identiek bij elk van hen:

1. De gebruiker opent de AI-builder-app op zijn telefoon.
2. De app accepteert of downloadt tijdens runtime user-gegenereerde code.
3. Een ingebedde webview of JavaScript-engine voert die code uit.

Stap drie is de overtreding. Op het moment dat een geshipte binary code draait die hij niet door de review heen heeft meegedragen, is het in overtreding — en Apple begon dat in maart 2026 te handhaven tegen deze hele categorie.

Waarom dit niet op Buildy van toepassing is

Buildy is een build-tool, geen engine die binnen de apps van je gebruikers draait. Het onderscheid klinkt subtiel. Architectonisch is het het hele verhaal.

Wanneer je met Buildy bouwt, bestaan er twee volledig gescheiden dingen:

• De editor en preview. Die leven op buildy.me, op onze servers. Wanneer je op een element in de live preview klikt, compileert Buildy je code server-side en rendert het in een gesandboxte iframe. De preview-engine verlaat nooit onze infrastructuur. Hij wordt nooit gebundeld in iets dat een telefoon bereikt.
• De app die je shipt. Dat is gewone React Native- en Expo-broncode. EAS Build compileert het naar een signed .ipa of .apk. De binary in de App Store bevat nul code-uitvoering, nul remote loaders, nul 2.5.2-oppervlak.

De builders die werden teruggetrokken vervaagden die twee dingen tot één. De preview-engine was de geshipte app. Wij hebben het nooit zo bedraad, en er is geen instelling die we morgen zouden kunnen omzetten om dit te doorbreken — zo is de architectuur gebouwd.

Waarom we deze keuze vroeg maakten

Server-side preview is moeilijker te bouwen dan een runtime in de app inbedden. Een in-app JavaScript-engine is de weg van de minste weerstand: bundel hem één keer en elke preview is gratis. Wij namen die weg niet, en een tijdlang leek het extra werk zonder opbrengst. Toen kwam de handhaving van 2.5.2 en was de opbrengst dat de hele categorie buiten de afwijzingsloterij bleef.

Er is een tweede voordeel dat uit dezelfde beslissing voortvloeit. Omdat de preview op onze servers draait en de export gewone broncode is, is de code die je shipt precies de code die je kunt lezen, auditen en bezitten. Er wordt tijdens het builden geen propriëtaire runtime ingenaaid. (Meer daarover in Jouw code is van jou.)

Wat dit voor jou betekent

Als je concurrenten hebt zien verdwijnen uit de store en je afvroeg of een mobiele app bouwen met AI het risico waard is, dan is dit het antwoord: het risico dat die producten droegen was een architectonische keuze, geen inherente eigenschap van AI-app-bouwen. Buildy maakte de andere keuze.

Jij beschrijft de app. Wij genereren React Native-broncode. Jij previewt hem veilig op onze servers, exporteert hem met een betaald abonnement en shipt een gewone signed binary die niets te verbergen heeft voor de review.

Bouw mobiele apps zonder de afwijzingsloterij. Start gratis met bouwen.