The SEO of a PWA rests on a simple principle: for a page to show up in search results, an engine first has to visit it, read it, and index it. That visit — the crawl — isn't something you trigger. The engine decides when it comes back, at its own pace.For a static site, that wait barely matters. For an app whose content is alive — a media outlet publishing several times a day, a store whose prices and stock keep shifting, a schedule where events appear and expire — it's a genuine drag. You've already done the work: the content is live, up to date, ready to be found. But it sits there waiting on a crawler that hasn't come back yet. In the meantime, it's sometimes an old version of the page — or nothing at all — that surfaces in results.

Name any content section of your app in your prompt, and the AI Extension Builder builds a section that displays that content — in the exact layout you described. Your articles, your template, always up to date. Every content section in a GoodBarber app comes with a set of carefully designed templates. You pick one, and it works — that's the point of an integrated platform. But the layout you have in mind isn't always in the list. Maybe you picture your latest articles magazine-style: one big cover photo with the title overlaid, smaller cards underneath. Or your events as a compact agenda with just the date and the venue. Until now, you picked the template that came closest.What many AI Extension Builder users haven't discovered is that this limit is gone. The builder doesn't just create standalone widgets — it can read the content of your app's existing sections. Which turns it into something more interesting than a widget generator: a tool for designing your own display templates.

If you've published your PWA, it's serving a robots.txt right now — the first thing any crawler reads, and the file that decides what happens next: which parts of your site get fetched, and by whom. Yours has been saying yes to everyone.Everything below concerns that web version of your app. Your iOS and Android apps aren't crawled by anyone, and the tab only appears once your PWA has been published at least once — before that, there's no file to configure.That was a defensible answer. It just wasn't one you made — and the population it answers has changed. A few years ago, a crawler on your content was Google, Bing, or a scraper you didn't care about. Today a growing share of that traffic belongs to AI companies, and they don't all want the same thing from your pages. Treating them as one block means choosing between all of them and none of them.The new tab splits them into four families, in plain language: search engines (Google, Bing and the others that list your site in their results), AI answers (ChatGPT, Claude or Perplexity citing your site when they answer), AI training (robots collecting your content to train their models), and on-demand reading (someone asks an AI to open one specific page of your site). Four families, because those are four different deals.

The short version. A mobile app that is not updated does not stay frozen: it decays. Push notifications quietly stop landing, new users stop finding it, and the stores eventually hide or remove it. On GoodBarber, the platform absorbs every OS and store change and ships the fix with your next update, so a year of mobile churn reaches you as a release note. The one thing you still have to do: update regularly.Your app works today. Leave it untouched for a year: it will still open, still look right, still do its job on your own phone. Nothing in your dashboard warns you. That is the trap.Because while your app stood still, everything underneath it moved. Apple and Google shipped new operating systems, rewrote store rules, retired old plumbing. You notice months later, through symptoms that look like a marketing problem: downloads sag, push campaigns reach fewer people, a loyal user writes that the app misbehaves on their new phone. The decay is real, and it has nothing to do with the quality of your content.

An MCP server on a backend gives an agent your database. GoodBarber's application MCP gives it your live app: feature-gated, per-app OAuth, verified writes.

Nobody doubts anymore that an AI can generate capable code — even "vibe-coded," it works, sometimes very well. That's not the interesting question. The interesting question is: once it's generated, what does that section actually do inside your app? Does it sit in a corner as an isolated block, or does it use what the phone and the app already know how to do? The most honest way to answer is to take a prompt and pull it apart, line by line.That's what this series is for. In each episode, we'll take one prompt from the AI Extension Builder's library and pull it apart: where it trusts the platform, where it overrides it, and what the resulting section can really do. First up, one of the library's example prompts: "where did I park?"Here's the shortest prompt you could write for this:Build a "remember where I parked" helper.That's it. One sentence, not a spec. And here's what comes out:A button to save your location. A section that finds that spot again when you reopen the app. A button to head back to the car. A discreet link to clear it. And if you decline location access, a screen that explains it instead of crashing.The surprise isn't that seven words draw a screen. It's that this section, born from one sentence, already reaches the device: it reads the GPS, it keeps a memory, it opens Maps. We asked for none of those three things.

A personality quiz — "Which 2026 Summer Blockbuster Is Your Vibe?" — built entirely by prompting GoodBarber's AI Extension Builder. Here's the quiz, why the format works, and the exact prompt to steal for your own app.

AI app builders nail the prototype. Production is another job: ownership, auth, stores, upkeep. How GoodBarber ships a native app AI agents can actually run.

We hosted a live AMA on r/GoodBarber, opening the floor to any question about publishing an app on the App Store — App Review, App Store Connect, developer accounts, all of it. The answers came directly from the support team that handles App Store and Google Play submissions every day, with iOS engineers pulled in whenever a question got technical. Here's the recap. We get this question a lot, so we looked at our own support cases from the last 18 months. The most common rejection reasons are less dramatic than people expect:Incomplete or inaccurate App Store metadata — missing or misleading information, screenshots, descriptions.An incorrectly configured App Privacy form.Apps that Apple considers incomplete or not fully functional during review.Beyond that, we regularly see rejections tied to content rights (especially audio or video), apps in regulated industries that don't meet Apple's expectations, or apps judged too close to something that already exists.For a first-time submission, it starts with the metadata: highlight your app's real value instead of generic promotion, and follow Apple's guidelines — they're the baseline for everything else. And if you do get rejected, don't panic. A rejection isn't a dead end, it's usually just part of the process. Read Apple's feedback carefully, address each point, and resubmit — we've seen plenty of apps get approved after one, or several, rounds of review.If you're convinced a reviewer got it wrong, stay factual. Explain clearly why you believe your app complies with the guideline in question, and back it up with whatever helps — screenshots, a screen recording, test credentials, step-by-step instructions if a feature isn't obvious. If the discussion stalls, you can request a call with an Apple representative through the App Resolution Center in App Store Connect — a direct conversation often clears up misunderstandings faster than a written back-and-forth. As a last resort, you can appeal to the App Review Board, where a senior member of Apple's team reviews the case. Either way, the goal isn't to prove Apple wrong — it's to make it as easy as possible for the reviewer to see why your app complies.

On February 2, 2025, Andrej Karpathy named the thing: “There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Nine months later, “vibe coding” was Collins Dictionary's Word of the Year. Few tech terms have traveled that fast — because few tech experiences are that intoxicating.The numbers say the same. Lovable reached $100M in annual recurring revenue eight months after launch, with more than 10 million projects created on the platform. Bolt.new reached roughly $40M ARR in about five months. Replit multiplied its revenue tenfold in half a year after launching its agent. Millions of people typed a sentence and watched software appear.We understand the high. It's the same one our users feel when they describe a feature and see it running in their app. Seeing your idea work — not mocked up, working — changes what you believe you can build. That part deserves no irony.But Karpathy put the caveat in the very same post: vibe coding is “not too bad for throwaway weekend projects.” The people living it say it with less restraint. One builder on r/nocode titled his post “Tried Bolt.new. Felt Like a God. Then Reality Slapped Me.” and summed up the morning after: “Suddenly, the dream of 'AI-powered coding' turned into 'AI-powered anxiety.'”The demo isn't a lie. The mistake is reading it as a finished product.

A video game isn't what you'd expect from an app builder.That's exactly what makes it a good test. To find out what the AI Extension Builder is really capable of, you're better off asking it for the improbable than for one more section. So we described a full arcade game — finger-tappable, full-screen, a leaderboard shared across every player — and watched to see how far it would hold up.It held up. The lesson isn't “go publish games,” it's “the ceiling is far higher than you think”: what's true for a Flappy Bird is true for the sharp, specific feature your app actually needs. Everything was described in plain language, in a few paragraphs. Here's the result.

This month's updates focus on visibility, compliance, and user experience — new ways to highlight key actions, protect younger users, and smooth out everyday interactions in your app. Here's what's new: New global Floating Button: highlight a key action across your whole app, configured once from the Structure panel. Age Protection: a new feature to comply with regional age-verification laws and automatically protect younger users. Event map thumbnails: events shown on a map can now appear as their own thumbnail image instead of a standard pin, so each one is instantly recognizable. Show/hide password: your users can now tap the eye icon to show or hide their password on any login or sign-up screen, so a typo never blocks them again.

The AI Extension Builder already lets you create a custom app section by describing it in plain language. Now those sections can remember and share real data. Ask for a poll, a booking list, or a guestbook, and the builder sets up the data behind it and connects it to your live app — through a new integration with Supabase. Until now, the AI Extension Builder was brilliant at one thing: turning a sentence into a working section. Describe a countdown, a mood board, a mini-game — it appears in your app, styled to fit right in. But every section it built lived entirely on the visitor's device. Nothing it produced could hold on to information or pass it between people.That was the limit. Ask for a "reader poll" and you'd get a poll that worked perfectly for one person, on one device. The votes lived in the browser. Close the app, and they were gone. Open it on another phone, and the count started at zero. A guestbook only you can read isn't a guestbook. A booking list that resets on every device isn't a booking list.The reason was always the same: those features need a place to keep their data, and a set of rules for who can read and write it. That layer — a backend — is the hard part, and it's exactly the kind of thing that used to sit among the limitations of no-code app builders. The new Supabase connector brings it inside the builder. The AI Extension Builder now builds the data layer along with the section, in the same conversation, before it writes a line of code.(If you're new to building sections this way, start with how the AI Extension Builder works — this article picks up from there. It's the same tool that recently learned to handle file uploads, now with a data layer too.)

When we launched the AI Extension Builder, it could build a custom section from a single prompt. The missing piece was your own material: until now the assistant started from a blank slate, wrote the code, rendered it live — but with its own stand-in images. To use your logo or your data, you had to point to an external URL, a fragile link hosted somewhere else. The new file manager removes that step.Take a running club that wants a "Race calendar" section in its app.The owner opens the Assets panel and drops in two files: logo.png and a races.csv with the dates and locations. Then they ask the assistant:"Show the upcoming races from this CSV, with our logo at the top."The assistant already knows these files. It doesn't invent them, recreate them, or base64-encode them: it references them by their exact URL — logo.png in an <img> tag, races.csv through a fetch(). The section renders live, in the club's colors, with its real dates.Days of work for a developer, minutes here. And the result isn't a mockup: it's a native extension, hosted by GoodBarber, that ships into the published app like any other section.

Last week we ran an AMA on r/GoodBarber, focused on the AI Extension Builder — the beta feature that turns a plain-language description into a real, integrated section of your app. Better still, the developers who actually built the feature were in the thread, answering directly. The questions were excellent: specific, hands-on, and often from people who'd already built something. Here's what came out of it.A recurring discovery from people testing the builder: more iterations don't automatically mean a better result. Past a point, changes get less relevant — and starting fresh with a clearer prompt often beats endlessly steering an existing one.Our take: iteration works best when you're refining the original intent. When each round changes the direction of the project, it's usually more productive to start over. The quality of that first prompt has an outsized impact — the clearer you are about what you want to build, the expected functionality, and the user experience, the better the output.

A lot of Custom Code needs to know who is using the app right now: showing premium content, greeting members by name, hiding a section from anonymous visitors, adapting a checkout. The GoodBarber App API gives you the current user through gb.user.getCurrent().And Custom Code isn't only something you write by hand anymore. With GoodBarber's AI Extension Builder, you describe the section you want in plain language and the assistant generates the extension for you — code that plugs straight into the same GoodBarber App API. Hand-written or AI-generated, it calls gb.user.getCurrent() the same way, and you test it the same way. So this guide applies whether you typed the code or prompted for it.But here's the catch every developer eventually hits: inside the back-office preview, there is no logged-in user. The preview is just a render of your app — there's no login screen, no session, nothing to authenticate against.For most app types, GoodBarber quietly works around this for you, so testing “as a logged-in user” just works. For the Membership extension, it doesn't — and that's on purpose. This article walks through how the current user behaves in the preview for each app type, and gives you a simple, copy-paste way to test the trickiest case: a logged-in member.

Gartner says 33% of enterprise software will include agentic AI by 2028. Your GoodBarber Skills already qualify — here's how to activate them, no code needed.

Agencies and resellers: run a daily review across every client app from one AI agent. How to manage multiple GoodBarber apps with AI through MCP — in 3 steps.

AI content publishing for editors and nonprofits: let an agent publish, schedule and run your app's content calendar through MCP — shown live, step by step.

Most app-builder comparisons pit two opposite philosophies against each other: a tool that makes you design a database against one that hands you finished features. GoodBarber and BuildFire are not that comparison. They agree on the method — you configure pre-built features instead of wiring atomic building blocks, and you reach a publishable app fast. That shared starting point is exactly why the decision between them is interesting: when two tools take the same shortcut, the question stops being "which approach" and becomes "what do you actually ship, and how well does it hold up?"To answer that concretely, we ran the same brief through both platforms: AURORA, the test app we use across this whole series.BuildFire is a mature, capable platform with thousands of live apps and a deep plugin catalog. The honest answer is that the two tools fit different operators — and the clearest fault lines run through native output, what's included in the subscription, and the economics of running apps over time.