Lovable App Rejected Under Guideline 2.3.1: Snapshots, Empty Screens and Review Notes That Hold Up

Lovable app rejected under Guideline 2.3.1: what App Review found

If your Lovable app was rejected under Guideline 2.3.1, the reviewer met functionality your Notes for Review didn't mention, couldn't reach something you described, or both. Lovable projects rarely hide anything on purpose. The gap comes from speed: a snapshot published after you submitted, a prompt that added a feature, a role check nobody wrote down.

The guideline wants your app's functionality to be "clear to end users and App Review", and every new feature described "with specificity" and "accessible for review" (App Store Review Guidelines, 2.3.1). Apple doesn't ask which tool wrote the code. It compares the app it can open with the notes you wrote – so the fix is to make those two match.

A 2.3.1 letter is a documentation finding. If yours cites Guideline 5.6, Apple suspects intent, and our article on Lovable apps rejected under 5.6 is the better starting point. The general method behind the steps below is in the 2.3.1 overview for AI-built apps.

Which snapshot did App Review test? Rebuild the timeline

Lovable's publishing model (as of October 2026) makes the timeline easy to reconstruct. Each publish deploys a snapshot of the project to the live URL, and later edits stay unpublished until you publish again – a small dot on the Publish button shows that newer changes are waiting. Your iOS app loads that live URL. So the app App Review tested is whichever snapshot was live during the review, not the project you see in the editor today.

Two-way Git sync gives each snapshot an identity. Changes made in Lovable sync to the connected GitHub, GitLab or Bitbucket repository, and commits pushed to the active branch sync back. Lovable creates a new repository for this; you can't connect an existing one. Turn it into a release log:

1. Tag at submission. Publish, note the newest commit on the synced branch and tag it, for example ios-1.4-build-22.
2. Record the publish time next to the build number, so you know when each snapshot went live.
3. Diff after a rejection. git log ios-1.3-build-19..ios-1.4-build-22 or GitHub's compare view lists every change between the last approved build and this one.
4. Check the review window. Any publish between submission and decision may have changed what the reviewer saw. Name it in your reply.

The chat thread can't replace this log. It shows what you asked for, including attempts you rolled back; the repository shows what exists.

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 →

Features your prompts added that never reached the notes

Lovable's agent works from intent, and intent is broad. A request for "a client portal" can come back with file uploads, comments, an activity feed and an export button – useful, but none of it in the notes you wrote for the original plan. Three checks catch these extras:

• Routes. List every route in the synced repository, including pages no menu links to. Apps created since May 13, 2026 (June 22 for Enterprise workspaces) run on TanStack Start, older ones on React with Vite. In both, a route that exists is either a feature the reviewer can reach or a dormant one if nothing links to it.
• Backend. Lovable Cloud adds edge functions and scheduled jobs to the database. A nightly digest email or a function that sends text to an AI model is functionality too – and AI services belong in the list of external services in your notes.
• The agent's own summary. Ask, in a prompt that forbids code changes, for every user-facing feature with its route and the conditions that show or hide it. Treat the answer as a draft and check each line against the repository.

Each find goes one of two ways: into the Notes for Review with a screen and a test step, or out of the project before the next publish.

Row level security and roles: why the review account sees empty screens

Lovable Cloud is built on Supabase's open-source foundation, and its row-level security (RLS) policies, in Lovable's words, "control which users can access or modify data in your database". That protects real users. It is also why a brand-new review account often sees nothing: no projects, no invoices, a dashboard of zeros. If your listing promises reports and the reviewer finds an empty chart, the feature is described but not reachable – and 2.3.1 asks for both.

Roles behave the same way. Generated code often checks for admin, owner or pro flags, and a reviewer without them never sees those screens. Fix it without weakening your policies:

• Give the review account its own data – records it owns, created through the app or with a prompt that targets that account only.
• One account per role. Apple's guidance: if your app has several account types, "such as administrative and general user accounts", add the extra credentials in the Notes field.
• Passwords, not codes. Lovable's email sign-in supports password, magic link and one-time code. Use a password for review accounts; Apple warns that credentials that expire or change before the review starts can get a submission rejected.
• Skip the confirmation email. Users created with Add user → Create new user under More → Cloud → Users are confirmed automatically.

Two-factor prompts, region locks and demo videos are covered in our 2.1 Information Needed guide.

Lovable's Quick scan, which runs when you open the publish dialog, flags risky database access rules. What it doesn't judge is whether a fresh account sees enough to understand a feature – test that with the review account inside the TestFlight build.

Paddle, Stripe and the badge: keep the listing honest

Lovable's built-in payments run on Paddle or Stripe and are made for digital products and subscriptions. Inside an iOS app, digital access generally needs In-App Purchase under Guideline 3.1.1 – see our 3.1.1 guide. Under 2.3.1 the problem is consistency:

• A premium area the reviewer can't open, because the only way in is a web checkout, is a feature that isn't accessible for review.
• Guideline 2.3.2 asks your description, screenshots and previews to "clearly indicate whether any featured items, levels, subscriptions, etc. require additional purchases".
• Prices on your Lovable landing page are marketing "whether within or outside of the App Store". A "free" tier that is really a trial, or a discount that has ended, is the false price 2.3.1 names.

The clean pattern: StoreKit for iOS users, your Lovable checkout for the web and one entitlement record in Lovable Cloud so both agree. Then give App Review an account whose subscription has expired – Apple asks for exactly that, so reviewers can test the whole purchase flow.

One more leftover is the "Edit with Lovable" badge. On paid plans, Hide Lovable badge under Project settings → Publishing removes it immediately, without a republish. An app you present as your own product shouldn't advertise the tool that built it.

Let new Lovable features follow the reviewed build

Your iOS app always loads the live URL. For projects created since May 13, 2026 there isn't even a static build you could bundle, because TanStack Start renders pages on the server. So you need another way to keep a new feature away from installs that were reviewed without it: a version marker.

1. Expose the build number. In WebViewGold, the native app template our team makes for web apps, you set the user agent per device with useragent_iphone and useragent_ipad in Config.swift – ending, for example, in MyAppIOS/1.4 (22). Alternatively, its App Version Check API returns the installed version and build number to JavaScript via getappversion://, or injects them automatically when autoInjectVariable is set to true.
2. Let Lovable read it. A prompt such as Add a helper that returns the iOS build number from the user agent pattern MyAppIOS/x.y (n), or null in a normal browser. Show the Invoices tab to browser visitors and to iOS builds 22 and higher only. On a TanStack Start project the same check can also run on the server, using the request's user agent.
3. Submit build 22 with the feature switched on and described. The reviewer sees it, the notes explain it, and older installs keep the feature set App Review approved for them.
4. Remove the condition once old builds have faded out, or show users of older builds a prompt to update.

The marker ties features to reviewed versions. It never decides that the reviewer sees something different from other users of the same build. Content, data and bug fixes still go live with any publish.

Notes for Review for a Lovable app: an example

Apple's guidance for updates is to "Describe what's changed, and where reviewers can find significant new content or features", and the Notes field takes up to 4,000 bytes. A block for a typical Lovable project:

About the app: [App name] shows our web app from app.example.com (built with Lovable, backend on Lovable Cloud) in a native iOS shell with push notifications for booking updates, Face ID unlock and an offline screen.
New in 1.4 (build 22):
1. Invoices – Invoices tab, open "March", tap Download PDF. The customer account has three invoices.
2. Team roles – Settings → Team. Sign in as the admin account below and change the member's role to Viewer.
Accounts: customer account in the sign-in fields; admin: [email protected] / [password]. Both use email and password, no codes.
Purchases: Pro is an auto-renewable subscription via In-App Purchase (Settings → Plan). The customer account's subscription has expired, so the full purchase flow can be tested.
Server-side content: bookings and articles update from our server. New functionality ships only with new app versions; the two features above are enabled for build 22 and later.
External services: Lovable Cloud (database, authentication, storage), OneSignal (push notifications), [AI provider] for summaries, disclosed in the app before first use.

More patterns for other app types are in our Notes for Review guide.

Wrapping, resubmitting and handing off App Review

WebViewGold helps beyond the marker:

• Fixed screens. Bundle onboarding, house rules or the offline page as local HTML, and they stay exactly as reviewed no matter how often you publish in Lovable.
• Native modules, one line each in the notes. Push (OneSignal, Firebase or Pushwoosh), Face ID, the QR scanner and StoreKit purchases with the Extended license are configured in the Xcode project, so their scope can't drift between reviews.
• Apple's rating dialog in place of any "rate us" pop-up the agent built into the web app.
• Google sign-in outside the web view. Google blocks embedded user agents, so use ASWebAuthenticationSession or Google's native SDK, or offer email plus Sign in with Apple in the app. Lovable's auth accepts custom-scheme redirects such as myapp://callback for the return trip. The version marker above is for your own code only – changing the user agent is no way around Google's block.

WebViewGold is bought once, and the Xcode project is yours to publish from your own developer account. No tool can promise an approval, but this setup makes every release traceable. The complete setup is in our Lovable-to-iOS walkthrough.

To resubmit, upload a new build if anything native changed – a new user agent marker counts – select it for the version, update the notes and reply with your release log. appsubmitter.io can take that part over: our App Specialists run an AI-powered pre-submission check, write precise Notes for Review and correspond with App Review for you, inside your own developer account. Changes to your Lovable code are quoted separately. Book the iOS submission, or describe your Lovable project to us in a free consultation call first.

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 reviewing [App name] (version [x.y], build [build number]) and for the details regarding Guideline 2.3.1.

Our app displays our web app from [domain], built with Lovable, in a native iOS shell. We traced the issue to [a publish of our web app on [date] that added [feature] after we submitted / a review account without data / [feature] being visible to admin accounts only].

What we changed:
1. Every feature in this version is now described below with its location and test steps.
2. The review account now contains sample data, and an additional [admin] account is listed below.
3. [Unused pages such as /admin-test were removed.]
4. New web features are now enabled only for app builds whose Notes for Review describe them. Content updates and bug fixes continue to go live through our website.

Features in this version:
- [Feature 1] – [screen] – [steps]
- [Feature 2] – [screen] – [steps]

Accounts:
- [Customer]: [email] / [password]
- [Admin]: [email] / [password]

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• The commit behind the snapshot you submitted is tagged with the version and build number.
• No publish that adds functionality went live between submission and decision.
• Every route, edge function and scheduled job in the synced repository is described in the notes or removed.
• The review account owns realistic records, so no screen the notes mention is empty.
• Each role – customer, admin, member – has its own password login listed in the Notes field.
• Paid features are reachable for review: In-App Purchase for digital access and an account with an expired subscription.
• Prices and plan names on the Lovable landing page are true and match what iOS users get.
• The "Edit with Lovable" badge is hidden.
• New features are gated by build number via the WebViewGold user agent or App Version Check API.
• The Notes for Review list every change since the last approved build with screen and test steps.

Frequently asked questions

Sources and further reading

• Apple – App Store Review Guidelines, 2.3.1 Accurate Metadata
• Apple Developer – Provide information for a complete review
• Lovable Docs – Publish your Lovable project (snapshots)
• Lovable Docs – GitHub integration (two-way sync)
• Lovable Docs – Security overview (row-level security, Quick scan)
• Lovable Docs – Email authentication
• App Store Connect Help – App Review information (Notes, demo account)
• WebViewGold Docs – App Version Check API (iOS)

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.