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.

Four things degrade on their own, and each one shows up in your numbers long before it shows up in an error message.

Your app disappears from the stores

The stores actively hide and remove apps that stop updating. This is written policy, not a rumor. On Google Play, an app must target a recent Android version to stay fully visible; Google raises that bar every year, and an app more than two years behind stops being shown to new users on current devices (Google Play's target API level policy). Apple runs the cleanup from the other side: its App Store Improvements program removes apps that have not been updated for three years and fall under a minimal download threshold, after a 90 day notice. From your side, it just looks like downloads drifting down for no reason, while the ASO work you invested in quietly stops paying.

Your push notifications stop landing

Push reach decays even when you do everything right. Every uninstall, phone change and device restore kills subscriber tokens; a living app constantly renews its audience, an abandoned one only loses it. And the pipes themselves get replaced: Apple shut down its legacy push protocol in March 2021, and apps whose delivery chain was never migrated simply stopped delivering. You experience it as open rates sliding quarter after quarter. You blame your copywriting; it was never the copywriting.

Every autumn, a new OS ships new bugs

Each year, Apple and Google release major OS versions, and apps never rebuilt against them inherit glitches on day one: layouts shift, permission prompts change, features silently stop working. When Apple retired UIWebView in 2020, every app still built on it had a hard deadline to rebuild or die. The cruelest part is who sees it first: your most engaged users update their phones earliest, so your best audience meets the bugs before anyone else.

The day you finally need to publish, you can't

Store requirements pile up while an app sleeps, and all of them block the next submission. Since July 2022, Google Play requires a completed Data safety declaration. Since May 2024, Apple requires privacy manifests describing what an app and its components access. Neither existed when many apps were first published. So the day you finally need to ship a change, a new logo, updated legal terms, the submission bounces off requirements that accumulated while you looked away. The longer the sleep, the taller the wall.

Your app did not change. The ground under it did. Apple and Google each ship a major OS every year and tighten store requirements on the same rhythm: the Android version bar moves annually, privacy declarations arrived in 2022 and 2024, push protocols get rebuilt every few years. Together they form a treadmill that never stops, and an app standing still on a treadmill moves backwards.

Our engineering team wrote up a decade of these changes in a dedicated article on dev.to, and ran the autopsy of what breaks when nobody touches an app for three years. The short version: staying published is not a one time achievement. It is a subscription to change.

GoodBarber's answer to the treadmill is structural: the platform runs it so you don't. When Google raises the Android version bar, when Apple adds a manifest requirement, when a push protocol is retired, GoodBarber absorbs the change once, at the platform level, for the thousands of live apps it hosts. The fix rolls into your app the next time you publish an update: your binary is rebuilt on demand, against the current requirements, and submitted to the stores.

The same goes for your notifications. GoodBarber operates the push pipeline end to end and delivers several million notifications per week across its apps; token handling, protocol migrations and certificate renewals have never been your job. Even the paperwork is generated rather than filled in: your privacy declarations are derived from the features you actually activated, so what your app declares matches what it contains.

Submission itself is a service, not a fight. Apple rejects roughly 42% of the first submissions handled by GoodBarber's publishing team, Apple's own baseline over the last 12 months, and the team recovers 91% of those rejections without the app owner lifting a finger. With GoodBarber Takes Care, an update is something you trigger, not something you battle. And all of it lives inside the subscription you already pay: hosting, push infrastructure, store compliance, the whole maintenance treadmill. That is the difference between building an app and running one, the same line we drew for AI app builders.

You didn't buy an app editor. You bought someone who keeps your app alive.

GoodBarber cannot do the last step for you. The fixes travel inside your updates, and an update reaches the stores when you decide to publish it, because every new version must be submitted for review. The platform prepares everything; you provide the trigger.

So the habit that keeps a GoodBarber app healthy is unglamorous: publish an update regularly, even when nothing visible changed. A quiet update is not an empty update. It carries months of platform work into your users' hands, renews your standing with both stores, and resets every clock described above. It takes minutes in your back office.

Run through these six questions; every yes matches a symptom described above.

• Is your last store update more than 12 months old?
• Have downloads drifted down with no change in your marketing?
• Do push campaigns reach fewer devices than they did a year ago?
• Have you never filled in, or never revisited, Google Play's Data safety section and Apple's privacy declarations?
• Have you skipped testing your app on the latest iOS and Android versions?
• Are there unread warning emails from App Store Connect or the Google Play Console?

One yes means your app is drifting. Two or more mean it is at risk. The fix is the same in every case: ship an update.

Do I need to update my app if nothing changed?

Yes. Even if your content and design have not moved, the stores and operating systems around your app change every year: visibility rules, privacy requirements, push protocols, new OS versions. Regular updates keep an app visible, compliant and stable. On GoodBarber, each update also carries every platform-level fix shipped since your previous one.

Can my app be removed from the App Store or Google Play for being outdated?

Yes. Apple removes apps that have not been updated for three years and fall under a minimal download threshold, after a 90 day notice. Google Play stops showing apps that target an Android version more than two years old to new users on current devices. Both policies are public and actively enforced.

Does GoodBarber update my app automatically?

GoodBarber automatically maintains everything around your app: platform code, hosting, push infrastructure and store requirements are kept current by its engineering team. The store update itself ships when you trigger it, because every new version must be submitted to Apple and Google for review. You publish regularly; the platform makes sure each update carries every accumulated fix.

How often should I update my mobile app?

Publish a store update at least once a year, and ideally every few months. Apple and Google each ship a major OS yearly and tighten store requirements on the same rhythm, so a yearly update is the floor for staying visible and compliant. Frequent updates also signal to both stores that your app is actively maintained.

Why did my app's downloads or push delivery suddenly drop?

For an app that has not been updated in a long time, the usual causes are store visibility rules and push token decay. Google Play stops showing outdated apps to new users, which erodes downloads, and push subscriber tokens die with every uninstall, phone change and device restore. Regular updates reset both.

The fix takes minutes, not a migration. If your app runs on GoodBarber, open your back office and publish an update today: it ships with every platform improvement accumulated since your last one, and the publishing team can handle the submission end to end. If your app lives somewhere nobody maintains it, see what a subscription that includes the maintenance covers.

The Model Context Protocol has won fast. Introduced by Anthropic in November 2024 and donated to the Linux Foundation a year later, MCP is now the standard way to hand tools to an AI agent, with more than 9,400 public servers listed in the official MCP Registry in 2026. Which means the phrase “we have an MCP server” has quietly become a checkbox. Every platform can tick it, and the tick tells you nothing.

The questions that matter sit one level deeper. What does the server let an agent see? What does it let an agent change? And when the agent writes, what stands between a well-phrased prompt and a broken production system? The answers depend far less on the protocol, which is the same for everyone, than on the altitude at which a platform plugs into it.

Backend-as-a-Service platforms plug MCP into their infrastructure layer. Back4app's MCP server, as its documentation describes it in July 2026, lets an agent create and manage Parse apps, define database schemas, query and modify objects through the Parse REST API, manage users and permissions, and deploy cloud code. Supabase's official MCP server points the same way: list tables, execute SQL, run migrations, manage branches and Edge Functions. These are real, useful capabilities. They are also unmistakably backend-shaped: what the agent reads and writes are rows, schemas and deployments. Call it MCP for your database.

GoodBarber plugs MCP in at a different altitude: the application itself. GoodBarber's MCP server exposes the operations of a finished, published mobile app: publish an article, schedule a push notification, create a product with its variants, update an order, read the analytics. The agent never sees a table. It sees the same product-level actions the app's owner sees in the back office. Call it MCP for your app.

A BaaS MCP hands an agent the keys to your data. An application MCP lets an agent run your product, safely.

Side by side:

Same protocol, same JSON, same agents on the other end. Four things change completely.

Semantics: the agent knows what it is doing

A backend tool speaks data. An application tool speaks intent. When an agent's tool is a raw SQL query, the agent knows it is inserting a row; whether that row makes sense as a product, a subscriber or a campaign is entirely the prompt's problem. When an agent calls classic_create_push_broadcast on GoodBarber's server, the tool's name, its typed schema and its constraints already encode what a push campaign is. There is far less room to be confidently wrong, because the domain knowledge lives in the tool, not in the prompt.

Safety: where the guardrails live

Good BaaS MCP servers do ship controls, and they matter: Supabase, for instance, offers a read-only mode and project scoping. But at database altitude, a permitted write is still a raw mutation. Nothing checks that the new row respects the invariants your application enforces everywhere else.

GoodBarber's MCP server enforces its guardrails at the product level, on the server side. Feature gating: a tool only exists if the matching feature is active in the app, so an app without push configured exposes no push tools at all. Per-app OAuth scope: every session is bound to one authenticated app, an agent connected to app A cannot see or touch app B, and agencies connect each client app separately. Verified writes: every write returns a server-side flag requiring the agent to read the object back and confirm the result before moving on. Hallucinated success is the failure mode agents are most prone to; GoodBarber's answer is to make verification part of the server's contract rather than a best practice left to the prompt.

Completeness: a database is not a product

An agent with full control of your backend still controls no product. The mobile app around that backend remains yours to design, build, connect, submit to the App Store and Google Play, and maintain: exactly the gap we mapped in AI app builders can build an app. Can they run one? An application MCP starts on the other side of that gap. The app already exists: compiled native iOS and Android builds plus a PWA, with hosting, CMS, push infrastructure and payments included rather than assembled from separate subscriptions. The agent operates a live product from day one, and there is nothing left to build around it.

Operators: who can actually use it

Back4app's MCP documentation lists the clients it is built for: Cursor, Windsurf, VS Code, Claude Code. Developer tools, reasonably, because driving a backend safely requires a developer's judgment. An application MCP moves the interface up to plain language. A shop owner can ask Claude to reprice a product, a publisher can ask ChatGPT to publish the morning's article and schedule the push, a club manager can ask for last month's downloads, and none of them needs an IDE. GoodBarber built its MCP surface for that operator, the same person its no-code back office was built for, and it works from any MCP client, including automation platforms like Zapier.

GoodBarber runs a hosted, production MCP server: nothing to install, nothing to self-host. You plug the endpoint into your MCP client, sign in with OAuth 2, and the session is scoped to your app from the first call.

The inventory is public and machine-readable. The server card lists 150 domain-typed tools at the time of writing (July 2026), namespaced by what they operate: tools prefixed cms_ cover content (articles, events, maps, photos, videos, podcasts, including scheduled publication), shop_ tools cover commerce (products and variants, collections, orders, promo codes, customers), and classic_ tools cover the running of the app (push broadcasts, analytics, memberships). The card is the contract: when the platform grows, the card grows, and connected agents pick up the new tools automatically. On top of the server, GoodBarber publishes 44 open-source Claude Skills that wrap common workflows as tested recipes, part of the same agent-ready platform push.

Just as deliberate is what the server does not expose. Design and layout stay in the builder, where GoodBarber's design system can protect them; pushing visual design through text-shaped tools does not produce good apps. And agent ready does not mean the human left the room: you grant the scope, you set the policies, and the server verifies what the agent does. Details and per-client setup live on the MCP page.

If you are a developer building custom software, with your own data model, your own business logic and your own frontend, a BaaS MCP server is exactly the right tool, and the good ones are genuinely good. Back4app's gives your coding agent a real Parse backend to build against; Supabase's does the same for Postgres, with scoping controls that show the category maturing. GoodBarber is not that tool and does not try to be: it will not host your custom backend, and it is built for content apps and mobile commerce, not for arbitrary software.

These are two altitudes for two different jobs, not two competitors on one axis. The practical test: if your project needs an agent that can touch raw data structures, you want a BaaS MCP. If it needs an agent that can run a live mobile app, you want an application MCP.

• You are building custom software and want an agent working on your schema, data and cloud code: choose a BaaS MCP server such as Back4app or Supabase.
• You want an agent to operate a real mobile app in production, across content, catalog, push notifications, orders and analytics: choose an application MCP server. That is what GoodBarber runs.
• The app's day-to-day operator does not code: an application MCP is the only altitude that works in plain language from mainstream clients like Claude and ChatGPT.
• You need both: some teams run them side by side, a BaaS MCP for the custom system a developer maintains, GoodBarber's MCP server for the mobile app the business operates. The protocol is the same; only the altitude differs.

What is the difference between a BaaS MCP server and an application MCP server?

A BaaS MCP server exposes backend infrastructure to an agent: database tables, schemas, queries, cloud functions. An application MCP server exposes the operations of a finished product. GoodBarber's MCP server lets an agent publish content, schedule push notifications, manage a catalog and read analytics on a live mobile app, without ever touching raw data structures.

Does GoodBarber's MCP server give an agent access to my database?

No. GoodBarber's MCP server exposes product operations, not SQL. An agent works with articles, products, orders, push campaigns and stats through domain-typed tools, and every call runs through the same application layer as the back office, so business rules and validations apply. Raw table access is never on the menu.

Is an MCP server on a backend enough to run a mobile app?

No. A backend MCP server operates the data layer, and the app around it still has to be designed, built, connected, submitted to the App Store and Google Play, and maintained. An application MCP server operates an app that already exists. That is the difference between managing rows and running a product.

How does GoodBarber keep agent writes safe?

Through three server-enforced layers. Feature gating: a tool only exists if the matching feature is active in the app. Per-app OAuth scope: an agent connected to one app cannot reach another. Verified writes: after every write, the server requires the agent to read the object back and confirm the result. Safety lives on the server, not in the prompt.

What is the best MCP server for a no-code mobile app?

Judge any candidate on three criteria: tools that speak the app's language rather than raw SQL, authentication scoped to a single app, and server-enforced verification on writes. GoodBarber's MCP server checks all three, with 150 domain-typed tools at the time of writing and a public server card listing every one of them, so you can verify the inventory instead of taking the claim on faith.

See the altitude difference for yourself. Start a free trial, build your app, then plug its MCP endpoint into Claude, ChatGPT or any MCP client: connecting an agent to a live app takes about two minutes. The complete MCP guide covers setup client by client.

Someone asked exactly that in r/nocode in June 2026, and the replies are worth reading for how they split. Almost nobody argues the tools are useless. Almost nobody argues they are enough. The considered answers converge on the same line: yes for a prototype, not yet for production. Two people in the thread report shipping real apps to Google Play and the App Store with AI help and no development background, and both describe the same experience: it worked, and it took months.

The most useful reply does not answer the question. It replaces it. The gap, one commenter observed, is no longer whether AI can build an app. It is whether AI can build an app that is ready for real customers.

That is the right question, and it deserves its full form. Everyone has spent two years asking whether AI can build an app. Almost nobody has asked whether AI can run one. Building is a burst of work that ends. Running is work that never ends. Most of the disappointment around AI app builders comes from buying the first and needing the second. This article is about both halves.

Skip the caricature. These tools are good, and pretending otherwise is how you lose credibility with anyone who has used one.

They collapse the distance between an idea and something you can look at. You describe a product, and minutes later there is a screen you can click, show to a colleague, and react to. The entry cost is close to zero. When you are still asking whether an idea deserves your next six months, that speed is not a gimmick. It is the whole point, and it is hard to beat.

They also killed the excuse. You can no longer say the idea died because finding out was too expensive.

“The UI is usually the easy part now,” as one reply in that r/nocode thread put it, before listing where people actually stall: authentication, payments, permissions, integrations, deployment, and the backend details real users depend on.

That is the uncomfortable implication for everyone selling app creation, ourselves included. If a working interface is now a prompt away, the interface is no longer where the difficulty lives. Generating a screen is solved. What was never the hard part just got easier, and what was always the hard part did not move.

This is why the comparison conversation has shifted. Put GoodBarber next to any of the prompt-to-app generators, and the interesting differences are not in what appears on screen in the first ten minutes. They are in everything that happens after.

We have written the long version elsewhere, so here is the map rather than the tour. Between a prompt-generated prototype and an app your users download, five things recur.

Ownership. If you cannot inspect, export and genuinely own the underlying project, you are renting a result you cannot reason about. The moment something breaks in a way the prompt cannot fix, you are stuck.

Authentication and persistent state. Real accounts, sessions, permissions and data that survives a refresh are a different engineering problem from rendering a screen. This is the most reported failure point by a wide margin, and it is the one that turns a convincing demo into a rebuild.

Real data and edge cases. Production is mostly the unglamorous remainder: the empty state, the duplicate order, the user on a bad connection, the row that should not exist. Demos never contain these. Users produce them on day one.

Store publishing. This is the one the discussion consistently underestimates, because it is invisible from the web. A browser preview is not an app. iOS and Android want signed native binaries, store metadata, permission declarations, privacy disclosures, and a review process with opinions of its own. Apple rejected roughly 42% of the first submissions our own publishing team handled over the last twelve months.

Maintenance. Someone owns this code in six months. If it was generated rather than designed, and regenerating a section quietly rewrites the parts that worked, that someone has a problem that compounds.

The most grounded account in that r/nocode thread comes from a carpenter, not a developer, who did get an app onto Google Play with AI assistance. The prompt, he says, was the easy part. The real work was refining features, fixing bugs, testing, gathering feedback and handling app store requirements. It took months and, by his own count, probably thousands of prompts. That is a success story. It is also a precise description of a job AI did not remove.

If you want the full treatment of these, with the numbers, we mapped the seven walls between a prototype and the stores and, specifically for mobile, what vibe coding tools forget to tell you. This article is about what comes after you accept that list.

Ask what your app needs on an ordinary Tuesday, six months after launch. Almost none of it is generation. It is publishing an article. Sending a push to the right segment. Fixing a price. Reading yesterday's numbers. That workload is the part nobody demos, prompt-to-app tools do not cover it by design, and it is where GoodBarber's answer has two halves, both load-bearing.

Half one: the output is a real app. GoodBarber compiles native binaries, iOS in Swift and Android in Kotlin, not a web view in a wrapper. The same configuration also produces a Progressive Web App. Hosting, database, CMS, push notifications, analytics and payment processing are included in the subscription rather than assembled from four other vendors with four other bills. That is not a philosophical preference. It is what lets someone who does not code publish, operate and update the app, and it is why apps built this way are downloaded every 4 seconds across 152 countries.

Half two: the app is operable by AI agents. GoodBarber runs a hosted, production Model Context Protocol server, so any MCP-aware assistant, Claude, Cursor, ChatGPT or another, can operate a live GoodBarber app in natural language. You connect the endpoint to your AI client, sign in with OAuth, and Tuesday becomes one sentence:

“Publish the draft announcement, schedule the launch push for 6 p.m., drop the featured product to €29, and tell me how last week went.”

Here is what that sentence becomes on the wire, in the server's own tool names:

1. cms_create_article publishes the announcement in the app's CMS.
2. classic_create_push_broadcast schedules the 6 p.m. push.
3. shop_update_product writes the new price to the live catalog.
4. classic_list_page_views and classic_list_downloads read last week back into a plain-language summary.

Then the detail that separates production from party trick: after every write, the server requires a verification read-back. The agent re-fetches the article it created, the push it scheduled, the price it changed, and confirms each against what you asked; if a call fails, it reports the failure instead of improvising around it. That policy is enforced server-side, not left to the agent's good manners. The full, machine-readable inventory of tools is public, on the server card: content, push, analytics, memberships, shop, orders, promo codes, customers. What it deliberately does not cover is design and layout, which stay in the builder where a design system can protect them. On top of the server, GoodBarber publishes 44 ready-to-use Claude Skills in an open-source repository, so common workflows come as tested recipes rather than prompts you have to invent.

The details are on the MCP page and in the complete guide.

One clarification worth making, because the category is loud and imprecise. Agent ready does not mean the human left the room. Every action is scoped to your app, an agent connected to one app cannot reach another, and the server verifies after each write. You still design the app, set the policies, and review what the agent does. The door is open for agents to act on your behalf. That is different from claiming the app runs itself, and we are not going to claim that.

The honest recommendation is not “stop using AI builders.” It is to use each tool for the job it is good at.

Use an AI app builder to find out whether your idea is worth pursuing. That loop is fast, cheap, and better than anything that existed three years ago. Once the answer is yes, move the idea onto something built to survive contact with real users, real stores and real Tuesdays.

Moving over does not mean giving up the prompt, either. GoodBarber kept it, scoped to the place where it earns its keep: the feature that does not exist yet. Describe a custom section to the AI Extension Builder (in Beta) and it writes the code and renders it live, in your app. It can even work from your own files: drop in your logo and your data, and the generated section uses them instead of stand-ins. The difference with a prompt-to-app generator is everything around the prompt: the section plugs into GoodBarber's APIs and inherits the platform's hosting, design system, native compilation and store pipeline. The prompt writes what is unique to you; the platform carries what has to be engineered. Prompt only where it is needed, a platform everywhere it counts: the best of both worlds, without assembling anything.

Be equally honest about where that stops. GoodBarber is built for content apps and mobile commerce. It does not build games, and it is not the right tool for recreating a complex multi-sided marketplace like Airbnb or Booking.com, where the whole product is custom business logic. If that is what you are building, no app builder is your answer, and you should hear that from us rather than discover it in month four. If you are shipping content, community or a mobile storefront, it is exactly the right shape. Our guide to the best no-code app builders in 2026 shows how the category compares.

An AI app builder is judged on what it generates. A production app is judged on what happens next: who owns it, who publishes it, who updates it on a Tuesday, and who answers when it breaks.

Prototype with AI. Ship and run with GoodBarber. Those are not competing sentences. They are a sequence.

Can an AI app builder build a full app if you cannot code?

It can build a working prototype, often a convincing one. Where it stops is production: owning and inspecting the project, authentication, data that persists correctly, edge cases, publishing signed native binaries to the App Store and Google Play, and maintaining the result over time. For validating an idea, yes. For an app real users depend on, not on its own.

What are the limitations of AI app builders for a mobile app?

Most are strong web-first code generators and fast at producing a working interface. The mobile-specific gaps: they output web projects rather than compiled native iOS and Android binaries, and they stop at generation, so hosting, database, store submission, push notifications and daily operation are yours to assemble and run. Our comparison pages walk through the differences feature by feature.

What is the best no-code app builder for AI agents in 2026?

The useful criterion is whether the platform exposes the app's operations to an agent through an open protocol, not whether it uses AI to generate the app. GoodBarber runs a production Model Context Protocol server that lets Claude, Cursor, ChatGPT and other MCP-aware clients operate a live app by natural language, plus 44 open-source Claude Skills for common workflows. Check any candidate's server card before believing a claim.

Can an AI agent actually run my app for me?

It can do the operating work: publishing content, scheduling pushes, updating products and prices, processing orders, reading analytics. It does not replace you as the operator. You set the policies, review the actions, and stay responsible for the app. GoodBarber's term is agent ready: the door is open for agents to act on your behalf, not that the app is autonomous.

Do I have to choose between AI speed and a real production app?

No, and framing it as a choice is the mistake. Use AI builders for the phase where speed is the whole value, which is finding out whether the idea is worth building. Use a platform built for the lifecycle once the answer is yes. GoodBarber puts AI on its own side of that line too: the AI Extension Builder creates custom sections by prompt, and the MCP server makes the live app operable by conversation.

Ready to see the other half? Start a free trial, build the idea you prototyped last weekend, and connect your AI client to your app's MCP endpoint. The prototype took an afternoon. Running it should not take a developer.

The GoodBarber App API lets your Custom Code ask "who is using the app right now?" through one method:

It takes two callbacks: a success callback (called with a GBUser object when someone is logged in) and an error callback (called when nobody is logged in). It's callback-based — it does not return a value or a Promise.

The GBUser object changes shape per app type

The GBUser model carries an api_version property that tells you which kind of app produced it:

The list of attributes depends on that version. For a Membership app (api_version: 3), a GBUser looks like this:

The access_levels array is what makes Membership special: it lists the access levels the user currently holds. That's almost always what your Custom Code branches on ("does this user have premium? then show the bonus content").

In practice, your code reads access_levels to decide what to show:

Keep this in mind — it's exactly this code the mock below will feed.

The preview in the back office is a sandbox. It renders your app, but it has no login mechanism — there's no way to actually authenticate a real user inside it.

To keep development comfortable anyway, GoodBarber injects a fake user for some app types so that getCurrent() returns something you can work with:

So if your app uses Authentication or eCommerce, you can test your logged-in logic in the preview right away — a fake user is handed to you for free, no setup needed.

If your app uses the Membership extension, it's different: no fake user is injected. If your success callback never fires in the preview and you keep landing in the error path, that's expected — there simply is no current user to return, and unlike the other two app types, none is faked for you.

The rest of this article focuses on that Membership case, because it's the one that needs a bit of work. You have two ways to handle it.

The most faithful way to test is to run your app inside the MyGoodBarber app (available on iOS and Android). It loads your real app, with the real login flow and the real backend. You log in as an actual member, and getCurrent() returns your real GBUser with your real access_levels.

Use this when you want to validate the whole flow end-to-end before publishing. It's the closest thing to production.

The downside: it's a slower feedback loop. You can't iterate on a CSS tweak or a conditional branch as fast as you can in the preview. That's where Option 2 comes in.

For fast iteration, you can temporarily replace gb.user.getCurrent with your own version that hands back a fake member of your choosing. Your real logic stays exactly the same — your Custom Code still calls gb.user.getCurrent(success, error) like normal. You're only swapping out what the method does while you're testing.

Step 1 — Drop in the mock at the top of your code

Add this block at the very beginning of your Custom Code's JavaScript, before any call to getCurrent():

💡 "premium" is just an example. Use the real access level identifiers configured in your app — otherwise your conditions won't match anything.

You might wonder: can't my code just detect the preview and mock only there? Unfortunately, no — there's no reliable signal exposed to your Custom Code that says "this is the preview" (gb.platform() returns "web" in the preview, exactly like a real PWA in production), and from getCurrent alone the preview is indistinguishable from a genuinely logged-out user (both hit the error callback). That's why we use a flag you flip by hand: it's explicit, and it can't be triggered by accident in production.

That's it. From now on, anywhere in your Custom Code where you call:

…your onUserFound callback receives the fake member above — exactly as if a real premium member were logged in. You don't change your business logic at all; you only added the mock block on top.

Step 2 — Test the cases that matter

The whole point of Membership code is reacting to different users. Just edit the mock to cover each scenario:

A subscribed member (has access levels):

A logged-in user with no subscription:

Several access levels at once:

Nobody logged in at all — here you mock the error path instead of the success one:

Flip between these to make sure your Custom Code behaves correctly in every state — not just the happy path.

Step 3 (optional) — Mock gb.membership.getAccessLevels() too

Some Membership code reads access levels through the dedicated Membership method rather than the user object:

If you use it, mock it the same way:

This is the one rule you cannot skip. The mock is a development crutch — it must never reach production. If you ship it, every user of the app will be treated as your fake premium member, regardless of what they've actually paid for.

Two safe habits:

1. Keep everything behind the single PREVIEW_TESTING flag and set it to false before publishing.
2. Better yet, delete the mock block entirely once you've finished testing.

When PREVIEW_TESTING is false (or the block is gone), gb.user.getCurrent falls back to GoodBarber's real implementation, and your Custom Code works against actual logged-in members.

• gb.user.getCurrent — retrieve the current logged-in user.
• GBUser — the user model and how its attributes change per api_version.
• gb.membership.getAccessLevels — read access levels directly (available only with the Memberships add-on).

• In the back-office preview, there is no real login.
• For Authentication and eCommerce apps, GoodBarber injects a fake user automatically, so testing as a logged-in user just works.
• For the Membership extension, no fake user is provided — getCurrent() hits the error callback.
• To test fast in the preview, temporarily override gb.user.getCurrent (and gb.membership.getAccessLevels if you use it) to return a fake member with the access_levels you want to test.
• For a real, end-to-end check, run your app inside the MyGoodBarber app.
• Always remove the mock before publishing.

Why does gb.user.getCurrent() return an error in the preview for my Membership app?

Because the back-office preview has no login mechanism, and for Membership apps (api_version: 3) GoodBarber does not inject a fake user. With nobody logged in, the method calls your error callback with "There's no user logged in the app." — this is expected behavior, not a bug.

Why does the same code work in the preview for an Authentication or eCommerce app?

For Authentication (api_version: 1) and eCommerce (api_version: 2) apps, GoodBarber automatically injects a fake user (or fake customer) in the preview, so your success callback fires without any setup.

How do I test a logged-in member without publishing my app?

Either run your app inside the MyGoodBarber app (iOS/Android) to test under real conditions, or temporarily override gb.user.getCurrent in your Custom Code to return a fake member with the access_levels you want to test.

What is access_levels in the GBUser object?

It's an array of the access levels a Membership user currently holds (for example ["premium"]). Your Custom Code typically branches on it to decide what content to show. An empty array ([]) means a logged-in user with no active subscription.

Does gb.user.getCurrent() return a Promise?

No. It's callback-based: you pass a success callback and an error callback. It does not return a value, so you can't await it.

What happens if I forget to remove the mock before publishing?

Every user of your app will be treated as the fake member you hard-coded — they'd all get, say, premium access regardless of what they actually paid for. Always set PREVIEW_TESTING to false or delete the mock block before you publish.

Ready to try it? Open the Custom Code section in your GoodBarber back office, paste the mock block at the top of your JavaScript, and set the access_levels for the case you want to test. When everything behaves, flip PREVIEW_TESTING to false (or delete the block) and publish. For the full reference, see the App API documentation.

Picture a two-person ocean-conservation nonprofit. One runs operations, one runs the field work. Between them they also run an app: a news feed, a list of causes, an events agenda, push notifications to a few thousand supporters.

Every week, the same routine. Write up the weekend's cleanup, format it, pick a category, decide what publishes now and what waits for the campaign date, add the next meetup to the agenda, schedule a push so people show up. None of it is hard. All of it is time — taken from the cause. No-code tools made each step easier; they never made the person optional. That is the part an agent changes.

Running your app like a newsroom means you stop operating the CMS by hand and start briefing an editor who does it for you. You describe the week in plain language; the agent carries it out across your app; you review.

This works because every GoodBarber app is agent-ready: it exposes its operations through a public Model Context Protocol server — 150 of them, 61 for the CMS alone — so an assistant you already use, like Claude, can manage your content by conversation instead of you clicking through a dashboard. So we tried it. Not on a mockup — on a live app.

We connected Claude to a live demo app for an ocean-conservation nonprofit and gave it one brief:

"Publish this weekend's Calvi cleanup recap now. Prepare our Plastic Free July campaign piece and schedule it for July 1 at 8am. And put the June 21 volunteer cleanup on the agenda."

Here is what it did, in order.

It learned the newsroom first. Before writing a word, the agent listed the app's content sections — About us, Our causes — pulled up the events agenda, and read the existing articles. An agent about to publish on your behalf orients itself the way a new editor would.

It published the recap — live. The cleanup story went into Our causes, with a deck and SEO metadata, status published. Online immediately, at its own URL, in the feed supporters were already reading.

It scheduled the campaign. The Plastic Free July piece did not go live. The agent set it to scheduled with a publication date of July 1, 08:00. It now sits in the queue and publishes itself on the morning of the campaign — nobody has to remember a button at 8am.

It updated the agenda. The June 21 volunteer cleanup landed on the events calendar with its start time, three-hour window, and the Calvi venue — slotting in among the gala, the kitesurf race, and the rest of the season.

And the platform made it prove its work. Every write came back flagged for verification, so the agent re-read the scheduled queue and the live article before reporting back.

One more sentence closes the loop: "schedule the launch push for July 1 at 8am." The same MCP surface sends the notifications — a broadcast with a send-at time — so the campaign publishes and the supporters hear about it in the same motion.

Three sentences of brief. A week of content calendar, handled.

This is where the worry usually lands: if the agent does all that, what's left for me? The answer is the part that was always the real job.

The agent takes the mechanics — formatting, timing, the queue, the push. You keep the judgment — what's worth publishing, what the campaign says, which event matters. That division is enforced, not just promised: the platform flags every write for verification, and you can have the agent stage everything as a draft for you to approve before a single item goes live. Nothing publishes that you didn't green-light.

So it isn't "the agent runs the app instead of you." It's the agent doing the doing, while you keep the deciding. You stop being the one clicking publish; you stay the one who says what gets published. For a two-person nonprofit, that's the difference between a week in the tool and a week on the cause.

If you run a content app, you already have the newsroom. To hand it an editor: connect your AI assistant to your app's MCP endpoint — the address lives in your back-office — or start from the 44 ready-made Claude Skills that wrap these workflows. Then brief it the way you'd brief a colleague.

Want to see it on your own content first? Start a free Content App trial, connect an assistant, and give it a week to run.

How do I automate my app's content calendar?

Connect an MCP-aware AI assistant (like Claude) to your GoodBarber app's MCP endpoint, then brief it in plain language: what to publish now, what to schedule, what to put on the agenda, and when to push. The agent calls the same CMS operations the back-office uses and carries out the week for you.

Can an AI agent schedule blog posts and push notifications?

Yes. Through the MCP server, an agent can create an article or event with a future publication date — it stays out of the feed until then and publishes itself — and queue a push notification with a send-at time, so a campaign and its alert go live together.

What is an MCP editorial workflow?

It's running your app's editorial work — publishing, scheduling, agenda, push — through the Model Context Protocol instead of by hand. You instruct an AI assistant; it calls the app's CMS operations directly; you review and approve. No copy-pasting between a draft and a dashboard.

Can AI publish to a mobile app's CMS without code?

Yes. GoodBarber exposes 61 CMS operations over MCP — create and update articles, build and reorder their content, manage events, handle photos and videos — all callable in natural language by an assistant, scoped to your app, with no code and no separate integration to build.