Skip to content
WebViewGold Vibe Coding to App Store Get WebViewGold

Before you submit

Remove builder badges before you submit the app

The floating "Edit with Lovable" button is harmless on the web. Inside a store app it is a link to another product, it covers your UI, and it tells the reviewer your app is a website. Hide it before you build.

Why it matters in review

Apple's guidelines on design (4.0), metadata (2.3) and minimum functionality (4.2) all push in the same direction: the app should be yours, complete, and not a wrapper around something else. A badge that links out to a builder is an external promotional link inside your app and the clearest possible hint that the app is a website in a shell. Google is more relaxed, but the badge still covers content on small screens.

How to hide the badge per builder

Most builders gate this behind a paid plan, which you likely need for a custom domain anyway.

  1. Lovable

    Project settings → hide the "Edit with Lovable" badge (paid plans). Publish again afterwards.

  2. Bolt

    If your deployed site shows a Bolt badge, check the hosting/plan settings or ask Bolt to remove the badge component from the layout, then redeploy.

  3. Base44

    App settings → disable Base44 branding (paid plans). Publish again.

  4. Replit, Mocha, Create, Softgen, Emergent

    Ask the agent to remove any "Made with …" footer element; check the settings for a branding toggle; redeploy.

  5. Webflow, Framer, Bubble, Glide

    Site/app settings → disable the builder badge or banner (paid site plans). Publish again.

Fallback: hide it only inside the app

If your plan does not allow removing the badge on the web, WebViewGold can inject custom CSS when your site is loaded inside the app. Add a rule that targets the badge element; for the Lovable badge the element carries an id of lovable-badge. Example (verify the selector in your project):

#lovable-badge, a[href*="lovable.dev"] { display: none !important; }

Custom CSS injection is documented in the iOS docs and the Android docs. The same mechanism hides cookie banners and "Download our app" sections inside the app. Removing it at the source is still the cleaner solution.

Other elements to hide in the app

  • App Store / Google Play badges and "Get the app" banners (pointless inside the app, and Apple dislikes links to other stores).
  • Cookie consent banners that cover the first screen (keep them on the web, hide in the app if your legal setup allows it).
  • Desktop headers and mega-menus on wide iPad layouts.
  • Smart App Banner meta tags (apple-itunes-app) inside the app.

Frequently asked questions

Will Apple reject my app only because of the badge?

Rarely as the only reason, but it is frequently listed together with 4.2 or 2.3 remarks. Remove it and you remove one argument.

Does the badge have to go from the website too?

No. Only the version loaded inside the app matters. If you cannot remove it on the web, use WebViewGold's custom CSS.

Is hiding the badge against the builder's terms?

Builders that offer a badge toggle on paid plans expect you to use it. Check your builder's terms before hiding it with CSS on a free plan.

Ready to ship your app?

App Store & Google Play approval guarantee – or your money back within 14 days

Prefer to hand it over? Full Service: we configure, build and submit for $349. Questions? Chat with us 24/7.

Refunds are granted under the conditions listed in our FAQ: a non-content rejection by Apple and/or Google, claimed within 14 days after purchase.