Het moeilijkste aan een content-app is zelden de content. Het is om alles doelbewust te laten ogen, scherm na scherm, wanneer ontwerpen niet je vak is. Een thema lost dat op door je een complete visuele richting te geven: kleuren, typografie, beeldstijl en lay-out werken al samen. Jij brengt je content en je merk; het thema brengt de afwerking. En omdat elk thema op Smart Design draait, blijft het resultaat consistent hoever je het ook aanpast.

Wat er met een app gebeurt in de drie jaar na de lancering: wat er om de app heen beweegt, wat het platform in uw plaats opvangt en het korte lijstje van wat op uw naam blijft staan.

In het kort: de lanceringsdag is het punt halverwege, niet de eindstreep. Het echte werk van een mobiele app is het dagelijkse beheer: publiceren, pushcampagnes, catalogusupdates, bestellingen. Precies in dat dagelijkse werk wordt een AI-agent echt nuttig.Het gesprek over AI is geobsedeerd door bouwen. Prompt-naar-app-demo's, gegenereerde schermen, prototypes in één keer. Logisch: bouwen levert een spectaculaire demo op. Maar wie echt een app heeft gelanceerd, kent het ongemakkelijke stuk: op de dag dat uw app in de stores staat, ligt het meeste werk nog vóór u.Een app die niemand beheert, sterft een stille dood. De content veroudert, de pushcampagnes vallen stil, de catalogus loopt achter en de retentie volgt. Wij draaien al sinds 2011 live apps, en vijftien jaar operationeel werk leert één les: wat het lot van een app bepaalt, is niet hoe hij gebouwd is, maar hoe hij gerund wordt. Die blinde vlek onderzochten we in AI-appbuilders kunnen een app bouwen. Kunnen ze er ook een runnen?: de sector werd heel goed in het genereren van apps en bleef merkwaardig stil over het beheren ervan.Daarom tekent zich een nieuwe categorie af: de app die een agent kan bedienen. Geen app die door AI is gebouwd, maar een app waarvan een AI-agent het dagelijkse beheer daadwerkelijk kan uitvoeren, op uw instructies, binnen duidelijke kaders. Bouwen doet u één keer. Beheren doet u voor altijd. In dat tweede deel brengt u uw dagen door.

Replit bouwt sinds 2016 ontwikkeltools in de browser. Begin 2026 kwam daar een mobiel aanbod bij, onder een pagina met de titel „Idea to Mobile App in Minutes" — waarmee het bedrijf voor het eerst op het terrein van de app builders staat.We hebben er dus onze gebruikelijke briefing doorheen gehaald: AURORA, dezelfde hoogwaardige reisgids-app die we op elke tool in deze reeks bouwen. Geen functielijstje, maar een echte app die de stores moet halen, elke week wordt bijgewerkt en wordt beheerd door iemand die geen code schrijft.Wat Replit oplevert, is degelijk. En het is tegelijk, zonder enige twijfel, een codebase: een React Native-project, een cloud die per gebruik wordt afgerekend, en een ontwikkelconsole. De hele vergelijking zit in die zin — Replit antwoordt u in gewone taal en geeft u daarna iets dat zich gedraagt als een engineeringproject. Of dat een cadeau of een probleem is, hangt volledig af van wie de app volgende week dinsdag moet draaien.

Noem een contentsectie van uw app bij naam in uw prompt, en de AI Extension Builder bouwt een sectie die die content toont — in precies de lay-out die u beschreef. Uw artikelen, uw sjabloon, altijd actueel. Elke contentsectie van een GoodBarber-app wordt geleverd met een reeks zorgvuldig ontworpen sjablonen. U kiest er een en het werkt — dat is het voordeel van een geïntegreerd platform. Maar de lay-out die u in gedachten heeft, staat niet altijd in de lijst. Misschien ziet u uw nieuwste artikelen voor zich in magazinestijl: één grote coverfoto met de titel eroverheen, kleinere kaarten eronder. Of uw evenementen als een compacte agenda, met alleen datum en locatie. Tot nu toe koos u het sjabloon dat er het dichtst bij kwam.Wat veel gebruikers van de AI Extension Builder nog niet hebben ontdekt: die grens bestaat niet meer. De builder maakt niet alleen op zichzelf staande widgets — hij kan de content van de bestaande secties van uw app lezen. En dat maakt hem interessanter dan een widget-generator: een gereedschap om uw eigen weergavesjablonen te ontwerpen.

De vindbaarheid van een PWA berust op een eenvoudig principe: voordat een pagina in de zoekresultaten verschijnt, moet een zoekmachine haar eerst bezoeken, lezen en indexeren. Dat bezoek — de crawl — activeer je niet zelf. De zoekmachine bepaalt zelf wanneer ze terugkomt, in haar eigen tempo.Voor een statische site maakt dat wachten weinig uit. Voor een app met levende inhoud — een medium dat meerdere keren per dag publiceert, een winkel met wisselende prijzen en voorraden, een agenda met evenementen die verschijnen en verlopen — is het een echte rem. Het werk is al gedaan: de inhoud staat online, is up-to-date, klaar om gevonden te worden. Maar ze wacht op een crawler die nog niet terug is geweest. Ondertussen verschijnt er in de resultaten soms een oude versie van de pagina — of helemaal niets.

Als je je PWA hebt gepubliceerd, serveert die op dit moment een robots.txt: het eerste bestand dat een crawler leest, en het bestand dat bepaalt wat er daarna gebeurt — welke delen van je site worden opgehaald, en door wie. Dat van jou zegt tegen iedereen ja.Alles hierna gaat over die webversie van je app. Je iOS- en Android-apps worden door niemand gecrawld, en het tabblad verschijnt pas zodra je PWA minstens één keer is gepubliceerd — daarvoor is er geen bestand om in te stellen.Het was een verdedigbaar antwoord. Alleen was het niet het jouwe — en het publiek waaraan het antwoordt, is veranderd. Een paar jaar geleden was een crawler op je content Google, Bing of een scraper waar je niet wakker van lag. Vandaag hoort een groeiend deel van dat verkeer bij AI-bedrijven, en ze willen niet allemaal hetzelfde van je pagina's. Ze als één blok behandelen betekent kiezen tussen allemaal of geen enkele.Het nieuwe tabblad verdeelt ze in vier families: Search engines (Google, Bing en de andere zoekmachines die je site in hun resultaten tonen), AI answers (ChatGPT, Claude of Perplexity die je site in hun antwoorden citeren), AI training (de bots die je content verzamelen om hun modellen te trainen) en On-demand reading (wanneer iemand een AI vraagt één specifieke pagina van je site te openen en te lezen). Vier families, want het zijn vier verschillende afspraken.

In het kort. Een mobiele app die niet wordt geüpdatet, blijft niet bevroren: hij takelt af. Pushberichten komen niet meer aan, nieuwe gebruikers vinden de app niet meer, en de stores verbergen of verwijderen hem uiteindelijk. Op GoodBarber vangt het platform elke verandering van de besturingssystemen en de stores op en levert de correctie mee met uw volgende update: een jaar aan mobiele schokken bereikt u als een release note. Het enige dat bij u blijft: regelmatig updaten.Uw app werkt vandaag. Laat hem een jaar met rust: hij blijft opengaan, blijft er goed uitzien, blijft zijn werk doen op uw eigen telefoon. Niets in uw dashboard waarschuwt u. Precies dat is de valkuil.Want terwijl uw app stilstond, bewoog alles eronder. Apple en Google brachten nieuwe besturingssystemen uit, herschreven de regels van hun stores, saneerden oude leidingen. U merkt het maanden later, aan symptomen die op een marketingprobleem lijken: de downloads zakken in, pushcampagnes bereiken steeds minder mensen, een trouwe gebruiker schrijft dat de app hapert op zijn nieuwe telefoon. De aftakeling is echt, en heeft niets te maken met de kwaliteit van uw content.

In het kort. Een MCP-server is maar zo nuttig als wat hij ontsluit. BaaS-platformen zoals Back4app en Supabase ontsluiten hun backend: databasetabellen, schema's, queries, cloud code. De MCP-server van GoodBarber ontsluit de operaties van een live mobiele app: een artikel publiceren, een push inplannen, de catalogus bijwerken, de statistieken lezen. 150 domeingetypeerde tools op het moment van schrijven, feature-gated, via OAuth beperkt tot één app, met een geverifieerde read-back op elke schrijfactie. Zelfde protocol, heel andere vlieghoogte.Het Model Context Protocol heeft snel gewonnen. Geïntroduceerd door Anthropic in november 2024 en een jaar later geschonken aan de Linux Foundation, is MCP inmiddels de standaardmanier om tools aan een AI-agent te geven, met in 2026 meer dan 9.400 publieke servers in het officiële MCP Registry. Dat betekent dat de zin “wij hebben een MCP-server” stilletjes een checkbox is geworden. Elk platform kan hem aanvinken, en dat vinkje zegt u niets.De vragen die ertoe doen, liggen één laag dieper. Wat mag een agent van de server zien? Wat mag hij veranderen? En als de agent schrijft, wat staat er dan tussen een goed geformuleerde prompt en een kapot productiesysteem? De antwoorden hangen veel minder af van het protocol, dat voor iedereen hetzelfde is, dan van de vlieghoogte waarop een platform erop aansluit.

Niemand twijfelt er nog aan dat een AI capabele code kan genereren — zelfs «vibe-coded» werkt het, soms heel goed. Dat is niet de interessante vraag. De interessante vraag is: wat doet die sectie, eenmaal gegenereerd, werkelijk binnen je app? Blijft ze een geïsoleerd blok in een hoekje, of benut ze wat het toestel en de app al kunnen? De eerlijkste manier om dat te beantwoorden is een prompt nemen en hem uit elkaar halen, regel voor regel.Daarvoor is deze nieuwe reeks bedoeld. In elke aflevering nemen we een prompt uit de bibliotheek van de AI Extension Builder en halen we hem uit elkaar: waar hij het platform vertrouwt, waar hij het forceert, en wat de resulterende sectie echt kan. We beginnen met een van de voorbeeldprompts uit de bibliotheek: «waar heb ik geparkeerd».Dit is de kortste prompt die je hiervoor zou kunnen schrijven:Build a "remember where I parked" helper.Dat is alles. Eén zin, geen bestek. En dit komt eruit:Een knop om je locatie op te slaan. Een sectie die dat punt terugvindt bij het heropenen van de app. Een knop om terug te keren naar de auto. Een discrete link om te wissen. En als je de locatie weigert, een scherm dat het uitlegt in plaats van te crashen.De verrassing is niet dat zeven woorden een scherm tekenen. Het is dat deze sectie, geboren uit één zin, al de mogelijkheden van het toestel benut: ze leest het GPS, houdt een geheugen bij, opent Maps. Om geen van die drie dingen hebben we gevraagd.

Een persoonlijkheidsquiz — « Which 2026 Summer Blockbuster Is Your Vibe? » — volledig gebouwd door hem te beschrijven aan de AI Extension Builder van GoodBarber. De quiz, waarom het format werkt, en de exacte prompt om te stelen.

AI-appbuilders blinken uit in prototypes. Productie is ander werk: eigendom, logins, stores, onderhoud. GoodBarber levert een native app die AI-agents runnen.

We hielden een live AMA op r/GoodBarber, open voor elke vraag over het publiceren van een app in de App Store: App Review, App Store Connect, ontwikkelaarsaccounts, noem maar op. De antwoorden kwamen rechtstreeks van het supportteam dat dagelijks App Store- en Google Play-publicaties begeleidt, met iOS-engineers die aanschoven zodra een vraag technisch werd. Hier is de samenvatting. Deze vraag krijgen we vaak, dus keken we naar onze eigen supportcases van de afgelopen 18 maanden. De meest voorkomende afwijzingsredenen zijn minder dramatisch dan je zou denken:Onvolledige of onjuiste App Store-metadata — ontbrekende of misleidende informatie, screenshots of beschrijvingen.Een verkeerd ingevuld App Privacy-formulier.Apps die Apple tijdens de review als onvolledig of niet volledig functioneel beschouwt.Daarnaast zien we regelmatig afwijzingen door contentrechten (vooral audio of video), apps in gereguleerde sectoren die niet aan Apples verwachtingen voldoen, of apps die als te vergelijkbaar met iets bestaands worden beoordeeld.Bij een eerste indiening begint alles bij de metadata: laat de echte waarde van je app zien in plaats van algemene promotie, en volg Apples richtlijnen — die vormen de basis voor al de rest. En als je wordt afgewezen: geen paniek. Een afwijzing is geen doodlopende weg, meestal is het gewoon een normaal onderdeel van het proces. Lees Apples feedback goed door, pak elk punt aan en dien opnieuw in — we hebben genoeg apps na één of meerdere reviewrondes goedgekeurd zien worden.Ben je ervan overtuigd dat een reviewer het bij het verkeerde eind had, blijf dan feitelijk. Leg duidelijk uit waarom je denkt dat je app aan de betreffende richtlijn voldoet, en onderbouw dat met alles wat helpt — screenshots, een schermopname, testgegevens, stap-voor-stapinstructies als een functie niet meteen duidelijk is. Loopt het gesprek vast, dan kun je via het App Resolution Center in App Store Connect een gesprek met een Apple-vertegenwoordiger aanvragen — een direct gesprek verheldert misverstanden vaak sneller dan een schriftelijke uitwisseling. Als laatste redmiddel kun je in beroep gaan bij de App Review Board, waar een senior lid van het Apple-team de zaak opnieuw bekijkt. Hoe dan ook, het doel is niet om te bewijzen dat Apple ongelijk heeft, maar om het de reviewer zo makkelijk mogelijk te maken te begrijpen waarom je app voldoet.

Op 2 februari 2025 gaf Andrej Karpathy het beestje een naam: “Er is een nieuw soort programmeren dat ik 'vibe coding' noem: je geeft je volledig over aan de vibes, omarmt de exponentiëlen en vergeet dat de code überhaupt bestaat.” Negen maanden later was “vibe coding” het Woord van het Jaar bij Collins Dictionary. Weinig techtermen hebben zich zo snel verspreid — omdat weinig tech-ervaringen zo bedwelmend zijn.De cijfers vertellen hetzelfde verhaal. Lovable zat acht maanden na de lancering op 100 miljoen dollar aan jaarlijks terugkerende omzet, met meer dan 10 miljoen projecten op het platform. Bolt.new haalde in zo'n vijf maanden ongeveer 40 miljoen dollar ARR. Replit zag zijn omzet in een half jaar vertienvoudigen na de lancering van zijn agent. Miljoenen mensen typten een zin en zagen software verschijnen.Wij snappen die kick. Het is dezelfde die onze gebruikers voelen wanneer ze een functie beschrijven en die meteen in hun app zien draaien. Uw idee zien wérken — niet als mock-up, maar écht — verandert wat u denkt te kunnen bouwen. Daar past geen greintje ironie bij.Maar Karpathy zette de kanttekening in diezelfde post: vibe coding is “niet zo gek voor wegwerp-weekendprojecten”. Wie het zelf meemaakt, zegt het minder diplomatiek. Een bouwer op r/nocode gaf zijn post de titel “Tried Bolt.new. Felt Like a God. Then Reality Slapped Me.” en vatte de kater zo samen: “Ineens sloeg de droom van 'AI-powered coding' om in 'AI-powered anxiety'.”De demo liegt niet. De fout is hem aan te zien voor een afgerond product.

We hebben de AI Extension Builder van GoodBarber om een compleet arcadespel gevraagd: een Flappy Bird die u met uw vinger speelt, schermvullend, met een ranglijst die alle spelers delen. Hier ziet u het resultaat, de exacte prompt die het opleverde, en wat deze proof of concept blootlegt: met de AI Extension Builder kan zowat alles wat u beschrijft een sectie van uw app worden. Een videospel verwacht u niet van een app builder.En juist daarom is het een goede test. Wilt u weten wat de AI Extension Builder in zijn mars heeft, dan vraagt u hem beter iets onwaarschijnlijks dan zomaar nog een sectie. Dus beschreven we een compleet arcadespel — met de vinger te spelen, schermvullend, een ranglijst die alle spelers delen — en keken we hoe ver hij zou komen.Hij kwam er. De les is niet "publiceer voortaan spellen", maar "het plafond ligt veel hoger dan u denkt": wat voor een Flappy Bird geldt, geldt evengoed voor de gerichte functie die uw app echt nodig heeft. Alles werd in gewone taal beschreven, in een paar alinea's. Dit is het resultaat.

De updates van deze maand draaien om zichtbaarheid, compliance en gebruikerservaring — nieuwe manieren om belangrijke acties te benadrukken, jongere gebruikers te beschermen en de dagelijkse interacties in uw app soepeler te laten verlopen. Dit is er nieuw:Nieuwe globale Floating Button: benadruk een belangrijke actie in uw hele app, in één keer geconfigureerd vanuit het Structure panel.Age Protection: een nieuwe functie om te voldoen aan regionale wetgeving rond leeftijdsverificatie en jongere gebruikers automatisch te beschermen.Miniaturen voor evenementen op de kaart: evenementen die op een kaart worden getoond, kunnen nu verschijnen als hun eigen miniatuurafbeelding in plaats van een standaardpin, zodat elk evenement meteen herkenbaar is.Wachtwoord tonen/verbergen: uw gebruikers kunnen nu op het oogpictogram tikken om hun wachtwoord te tonen of te verbergen op elk inlog- of registratiescherm, zodat een typefout hen nooit meer blokkeert.

Met de AI Extension Builder maakt u al een eigen app-sectie door hem gewoon in gewone taal te beschrijven. Vanaf nu kunnen die secties ook echte gegevens onthouden en delen. Vraag om een poll, een reserveringslijst of een gastenboek, en de builder zet de gegevens erachter klaar en koppelt ze aan uw live app — dankzij een nieuwe integratie met Supabase. Tot nu toe blonk de AI Extension Builder in één ding uit: een zin omzetten in een werkende sectie. Beschrijf een aftelklok, een moodboard, een minigame — het verschijnt in uw app, meteen in de juiste stijl. Maar elke sectie die hij bouwde, leefde volledig op het toestel van de bezoeker. Niets wat hij maakte, kon informatie vasthouden of doorgeven aan anderen.Daar zat de grens. Vroeg u om een "lezerspoll", dan kreeg u een poll die perfect werkte voor één persoon, op één toestel. De stemmen bleven in de browser. Sloot u de app, dan waren ze weg. Opende u hem op een andere telefoon, dan begon de teller weer op nul. Een gastenboek dat alleen u kunt lezen, is geen gastenboek. Een reserveringslijst die op elk toestel opnieuw begint, is geen reserveringslijst.De reden was altijd dezelfde: die functies hebben een plek nodig om hun gegevens te bewaren, en een set regels voor wie ze mag lezen en schrijven. Die laag — een backend — is het lastige deel, en precies zo'n zaak die vroeger tot de beperkingen van no-code app-builders behoorde. De nieuwe Supabase-connector brengt die laag naar binnen, in de builder zelf. De AI Extension Builder bouwt nu de gegevenslaag samen met de sectie, in hetzelfde gesprek, nog voordat hij een regel code schrijft.(Bent u nieuw met het bouwen van secties op deze manier? Begin dan met hoe de AI Extension Builder werkt — dit artikel gaat daarop verder. Het is dezelfde tool die onlangs leerde om bestanden te uploaden, nu ook met een gegevenslaag.)

Toen we de AI Extension Builder lanceerden, kon hij al een sectie op maat bouwen vanuit één enkele prompt. Eén stuk ontbrak: je eigen materiaal. Tot nu toe begon de assistent met een leeg blad, schreef de code, toonde die live, maar met zijn eigen tijdelijke afbeeldingen. Om jouw logo of jouw data te gebruiken, moest je naar een externe URL verwijzen – een kwetsbare link, ergens anders gehost. De nieuwe bestandsbeheerder schrapt die stap.Neem een hardloopclub die een sectie «Wedstrijdkalender» in zijn app wil.De beheerder opent het paneel Assets en sleept er twee bestanden in: logo.png en een races.csv met de data en de locaties. Daarna vraagt hij de assistent:«Toon de aankomende wedstrijden uit deze CSV, met ons logo bovenaan.»De assistent kent die bestanden al. Hij verzint ze niet, maakt ze niet opnieuw, codeert ze niet in base64: hij verwijst ernaar via hun exacte URL – logo.png in een <img>-tag, races.csv via een fetch(). De sectie verschijnt live, in de kleuren van de club, met zijn echte data.Voor een ontwikkelaar dagen werk, hier een paar minuten. En het resultaat is geen mockup: het is een native extensie, gehost door GoodBarber, die net als elke andere sectie in de gepubliceerde app belandt.

We hielden onlangs een AMA op r/GoodBarber over de AI Extension Builder — de betafunctie die een beschrijving in natuurlijke taal omzet in een echte, in je app geïntegreerde sectie. Nog beter: de ontwikkelaars die de functie hebben gebouwd, waren in de thread om rechtstreeks te antwoorden. De vragen waren uitstekend: concreet, praktisch en vaak van mensen die al iets hadden gebouwd. Dit kwam eruit.Een terugkerende vaststelling bij wie de builder test: meer iteraties betekenen niet automatisch een betere app. Vanaf een bepaald punt worden de wijzigingen minder relevant — en opnieuw beginnen met een duidelijkere prompt verslaat vaak het eindeloos bijsturen van een bestaande.Onze visie: itereren werkt het best wanneer je de oorspronkelijke bedoeling verfijnt. Wanneer elke ronde de richting van het project verandert, is het meestal productiever om opnieuw te beginnen. De kwaliteit van die eerste prompt heeft een enorme impact — hoe duidelijker je bent over wat je wilt bouwen, de verwachte functionaliteit en de gebruikerservaring, hoe beter het resultaat.

Moet je GoodBarber Custom Code zich anders gedragen voor een ingelogde gebruiker — premium content tonen, een member bij naam begroeten, een sectie verbergen voor anonieme bezoekers? Of je die code nu zelf hebt geschreven of hem hebt gegenereerd met de AI Extension Builder, hij vraagt de App API wie er is ingelogd via gb.user.getCurrent(). Maar de preview in de back office heeft geen echte login, dus bij Membership-apps komt die aanroep altijd in het error-pad terecht. Deze gids legt uit hoe de huidige gebruiker zich in de preview gedraagt voor elk app-type, en geeft je een kant-en-klare manier om als ingelogde member te testen. Veel Custom Code moet weten wie de app op dit moment gebruikt: premium content tonen, members bij naam begroeten, een sectie verbergen voor anonieme bezoekers, een checkout aanpassen. De GoodBarber App API geeft je de huidige gebruiker via gb.user.getCurrent().En Custom Code is allang niet meer alleen iets wat je met de hand schrijft. Met de AI Extension Builder van GoodBarber beschrijf je de sectie die je wilt in gewone taal en genereert de assistent de extensie voor je — code die rechtstreeks aansluit op diezelfde GoodBarber App API. Met de hand geschreven of door AI gegenereerd, ze roept gb.user.getCurrent() op dezelfde manier aan, en je test ze op dezelfde manier. Deze gids geldt dus of je de code nu zelf hebt getypt of erom hebt gevraagd.Maar er is een addertje onder het gras waar elke developer vroeg of laat tegenaan loopt: binnen de preview van de back office is er geen ingelogde gebruiker. De preview is gewoon een weergave van je app — er is geen loginscherm, geen sessie, niets om tegen te authenticeren.Voor de meeste app-types lost GoodBarber dit stilletjes voor je op, zodat testen "als ingelogde gebruiker" gewoon werkt. Voor de Membership-extensie is dat niet zo — en dat is met opzet. Dit artikel loopt door hoe de huidige gebruiker zich in de preview gedraagt per app-type, en geeft je een eenvoudige, kant-en-klare manier om het lastigste geval te testen: een ingelogde member.