Lovable App Rejected Under Guideline 5.6: How to Find the Trigger and Resubmit Cleanly

Lovable app rejected under Guideline 5.6: what Apple is telling you

If your Lovable app was rejected under Guideline 5.6, App Review has concluded that the app – or the way it reached review – breaks the Developer Code of Conduct. For apps built with Lovable, that nearly always means the reviewer met features that looked hidden, changed after review or stayed out of reach. The builder isn't the problem. How the project was published and tested usually is.

The letters developers shared in 2026 read almost the same: Apple has noticed "a pattern of unusual behavior" it associates with fraudulent activity, and the app "contains features that appear to have been intentionally hidden during the review process". Which feature, the letter rarely says, so you have to reconstruct it yourself. The rule behind the accusation is Guideline 2.3.1(a):

Don’t include any hidden, dormant, or undocumented features in your app; your app’s functionality should be clear to end users and App Review.

Guideline 5.6 turns that into a question of trust in you as a developer, and Apple has the tooling to notice. In 2025 it rejected more than 22,000 submissions for hidden or undocumented features, and it says machine learning helps it "flag potentially problematic changes in app updates" (Apple Newsroom, May 20, 2026). For the general mechanics, read our overview of 5.6 rejections for AI-built apps and the screen-by-screen diagnosis for WebView apps. This article covers what is specific to Lovable.

One clarification first: Apple's March 2026 pushback on vibe coding was aimed at tool apps that run generated code inside their own iOS app. Lovable's own iPhone builder app, launched on April 28, 2026, moved app previews into the web browser to comply (TechCrunch). Your wrapped Lovable app is a different case and goes through ordinary review.

Why Lovable projects trip the Developer Code of Conduct

Lovable is built for speed: the agent writes the code, Lovable Cloud brings the database and sign-in, and one click on Publish deploys a new snapshot. Each of those strengths has a side effect once an App Store build depends on the result.

One trigger is easy to miss: credits. Lovable's hosting docs say that when a workspace runs out of credits, apps that rely on the backend or AI features can pause, and a paused backend may not restart by itself. A reviewer who opens the app in that window sees data that never loads. That hollow app invites a 5.6 suspicion and a Guideline 2.1 completeness rejection at the same time.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

Where to look inside Lovable: a 30-minute audit

Walk through these places in order and write down everything you find. The list becomes the backbone of your reply to App Review.

1. Publish history. List every publish between your submission date and the rejection. A dot on the Publish button means changes are still waiting to go live, and accepted drafts only reach visitors once you publish. With Git sync switched on, the commit history in GitHub, GitLab or Bitbucket shows exactly what changed. Also check whether the publish tool in the chat runs on auto-approve.
2. Users and sign-in. Under More → Cloud → Users, open Auth settings. Which sign-in methods are enabled, is email confirmation on, and does the review account from your notes exist and sign in with the stated password?
3. Data access. The Quick scan Lovable runs before publishing looks for row level security mistakes, but it can't tell you whether a new user sees anything useful. Ask the agent directly: Which tables can a newly registered user read, and what does the dashboard show on their first login?
4. Conditional code. In the code editor or your synced repository, search for role, isAdmin, plan, beta, flag and userAgent. Anything that decides which features exist – rather than how they look – needs a closer look.
5. Payments. Open the Payments tab: which products are live, where does the checkout appear, and would an iPhone user reach it inside the app?
6. Visibility and domain. The visibility row in the Publish dialog should allow anyone with the link. The app's start URL should be your primary domain, because Lovable redirects other connected domains to it with a temporary 302 redirect.
7. Branding. On paid plans, Project settings → Publishing has a Hide Lovable badge switch that takes effect without a republish.
8. Backend health. More → Cloud → Overview shows whether the backend is paused and offers a Wake up button.

Seven fixes to make in Lovable before you resubmit

1. Freeze feature releases. Agree on one rule with everyone who can publish: while a build is in review, the project only receives content updates and bug fixes. Switch off auto-approve for publishing from the chat. New features reach app users after the build that describes them has been approved.
2. Create a review account that sees everything. Use Add user → Create new user in Cloud → Users – Lovable confirms accounts created there automatically. Give it a password, every role and realistic sample data. A prompt such as Create sample projects, invoices and messages for the user [email protected] only keeps the test data out of real accounts.
3. Make conditional features consistent. Either release a gated feature to every eligible user and describe it, or remove it from this version. Never tie features to anything that could identify a reviewer.
4. Settle digital purchases. Lovable's built-in payments are designed for digital products and subscriptions – exactly what Guideline 3.1.1 reserves for In-App Purchase inside an iOS app. Physical goods and real-world services can stay on Stripe or the Shopify integration. Our article on 3.1.1 rejections in WebView apps covers the options, including the storefronts where Apple now allows external purchase links.
5. Remove what the agent invented. Testimonials from people who don't exist, "trusted by thousands of teams", star ratings and AI features that are only mock-ups break the customer-trust promise of 5.6 and the marketing rules in 2.3.1. Check the app, the website and the App Store description.
6. Look like your own product. Hide the badge, load your own domain, replace the generated icon and default styling, and publish under the company that runs the service. Guideline 5.6.2 asks for an accurate representation of you and your business.
7. Write specific review notes. List every feature, where it lives and how to test it. Apple rejects generic descriptions under 2.3.1, and our 2.3.1 article for WebView apps shows what you may still change on the web after approval. A Lovable release log and a sample notes block are in Lovable and Guideline 2.3.1.

Wrap the Lovable app so the reviewed build is the one users get

How you package the web app matters as much as what is in it. Lovable projects created since May 13, 2026 are server-rendered with TanStack Start and deployed to Cloudflare Workers, so they need a running server – you can't copy a static build into the app. Capacitor's documentation says its server.url option for loading a remote site "is not intended for use in production". In practice, your iOS app loads the published Lovable URL, and that is exactly why publish discipline decides your 5.6 risk.

WebViewGold, the website-to-app solution built by our team, is designed for this setup. It is a ready-made Xcode project: you enter your domain in Config.swift and switch on native modules that make the app easier for a reviewer to trust:

• Apple's native rating dialog, triggered from your web code, instead of a web "rate us" pop-up – Guideline 5.6.1 disallows custom review prompts.
• Push notifications via OneSignal, Firebase or Pushwoosh for real events in your app.
• A native offline screen with a Reconnect button instead of a browser error page.
• Face ID or Touch ID to unlock the app, and automatic handling of Sign in with Apple pages.
• StoreKit In-App Purchases (with the Extended license) for digital goods.
• A custom user agent and the Custom CSS & JS API to switch the web app into app mode – for layout only, never to decide which features exist.

No tool can promise an approval, and WebViewGold won't fix a role check in your project. It does remove the classic WebView weak spots in one step. Our guide to converting a Lovable app to iOS covers the full setup, including Google sign-in, and the Android version explains what Google Play expects from the same project.

How to answer App Review after a Lovable 5.6 rejection

Upload the corrected build first, then reply in App Store Connect under the rejected submission. Replies can run up to 4,000 characters and carry attachments such as a screen recording. Guideline 5.6 itself asks for respectful communication with Apple, so stay factual even if the wording stings.

A convincing reply for a Lovable app covers four points:

• What you found – for example, a publish during review that added a booking feature, or a review account that saw no data.
• What you changed – the seeded review account, the deleted claims, the In-App Purchase setup.
• Your release rule – the app loads your web app from your domain, and new features only ship with a new, documented build.
• How to test everything – credentials, a feature list with locations and a recording.

If the letter names no feature, ask politely which screen raised the concern. Apple also offers 30-minute video appointments with App Review, which can settle a misunderstanding faster than another round of messages. Appeal to the App Review Board only if you are sure Apple misread the app: Apple accepts one appeal per rejected submission and expects open questions to be answered first (Apple's App Review page). If you'd rather not handle the exchange alone, an App Specialist from appsubmitter.io can prepare the reply with you and take over the communication with App Review in your account.

Mistakes that turn a fixable 5.6 into a lasting problem

• Hiding things from the reviewer. Showing a paywall or a feature only to people who aren't reviewing is the pattern 5.6 describes. Don't ask the agent to detect Apple's networks or test devices.
• Resubmitting the same build. Nothing changes except the length of your rejection history.
• Opening a second developer account or a new bundle ID. Apple terminated 193,000 developer accounts over fraud concerns in 2025. A workaround account turns a fixable rejection into a question about your identity under 5.6.2.
• Publishing again mid-review. Even a well-meant improvement can make the reviewer's next session differ from the last one.
• Arguing. A defensive reply rarely speeds anything up.

If the app matters to your business, let someone check it before the next submission. appsubmitter.io combines an AI-powered pre-submission guideline check with an App Specialist who reviews the app, writes precise review notes and handles the communication with App Review – in your own Apple Developer account. Changes to your code are quoted separately before any work starts. Book the iOS submission or talk it through first in a free consultation call.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for your message about [App name] (version [x.y], build [build number]) and Guideline 5.6.

The web part of our app is built with Lovable and published to [your domain]. We reviewed everything that could make features look hidden or inconsistent and made these changes in the new build:

1. Release process: new features now ship only together with a new app build that is described in the Notes for Review. While a build is in review, we publish content updates and bug fixes only.
2. Review account: [email] / [password]. The account is confirmed, contains sample data and has access to [roles / areas]. It no longer depends on a magic link.
3. [Digital purchases in the iOS app now use In-App Purchase. / We removed digital purchases from the iOS app.]
4. [We removed generated testimonials and user numbers from the app and the App Store description.]

Features and how to test them:
- [Feature 1] – [screen] – [steps]
- [Feature 2] – [screen] – [steps]
- [Feature 3] – [screen] – [steps]

A screen recording of these flows is attached. If a specific screen or flow raised the concern, we would appreciate a pointer so we can address it directly.

Kind regards,
[Your name]
[Company]

Checklist before you resubmit

• Nothing that adds functionality was published in Lovable while the build was in review, and auto-approve for publishing is off.
• The review account was created in Cloud → Users, signs in with a password and sees realistic data.
• Every role, plan and flag check in the code has been reviewed; the review account reaches every gated area.
• The published app is visible to anyone with the link, not only to workspace members.
• Digital goods use In-App Purchase in the iOS app; Paddle or Stripe only sell physical goods or services there.
• Generated testimonials, ratings, user counts and mock features are gone from the app, the website and the listing.
• The Lovable badge is hidden and the app loads your own primary domain.
• The backend is running and the workspace has enough credits for the review period.
• The Notes for Review list every feature with its location and test steps.
• A new build was tested through TestFlight before you replied.

Frequently asked questions

Sources and further reading

• Apple – App Store Review Guidelines, 5.6 Developer Code of Conduct
• Apple – App Store Review Guidelines, 2.3.1 Accurate Metadata
• Apple Newsroom – App Store fraud prevention in 2025 (May 20, 2026)
• Lovable Docs – Publish your Lovable project
• Lovable Docs – Users and authentication
• Lovable Docs – How Lovable hosts your app
• Lovable Docs – Add payments to your app
• TechCrunch – Lovable launches its vibe-coding app on iOS and Android (April 28, 2026)

Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.