DEV Community: LetsDeployIt Team

App rejected under Apple Guideline 4.3 (Spam): how to fix it

LetsDeployIt Team — Thu, 29 Oct 2026 14:54:48 +0000

Guideline 4.3 is Apple's spam rule. 4.3(a) rejects several copies of the same app under different Bundle IDs, and 4.3(b) rejects apps that are hard to tell apart from ones already in the store. AI-built apps hit it because they share a builder's look, a generic name and template copy. To fix it, ship one app that is visibly yours, then explain what's different when you resubmit.

What does Apple Guideline 4.3 say?

You hit Submit, wait two days, and the note in App Store Connect says Guideline 4.3, Design, Spam. Nothing in your app is broken. Apple is saying it looks like an app the store already has, or like a copy of one of yours. The rule has two parts:

Don't create multiple Bundle IDs of the same app.

Apple App Review Guideline 4.3(a)

Don't submit apps that are indistinguishable from what's already widely available.

Apple App Review Guideline 4.3(b)

4.3(b) names categories that are already crowded, such as dating, flashlight, sound effects, wallpaper, simple timers and fortune telling, and says Apple won't take new ones unless they offer a meaningfully different or improved experience. Repeated spam submissions can get you removed from the Apple Developer Program, so this is not a rejection to keep resubmitting unchanged.

4.3(a) or 4.3(b): which one did you get?

Read which letter the note cites, because the fix is different. Apps that hit 4.3 often get a related guideline in the same review, so check for these too:

Guideline	What it means	What usually triggers it in AI-built apps
4.3(a) Spam	Several apps that are really one app	A second Bundle ID for a city, client or variant, or resubmitting the rejected app as a "new" app
4.3(b) Spam	Your app looks like many apps already in the store	A builder's default look, a generic name like "Habit Tracker", template screenshots and copy, in a crowded category
4.2.6 Templates	Apps from a template or app generation service, submitted by that service for its clients	An agency or builder account submitting your app for you, instead of your own developer account
4.1 Copycats	Copying a popular app's name, look or idea with small changes	Prompting a builder to "make an app like" a well-known app and shipping what it makes
2.3.7 Metadata	A unique name, accurate keywords, no other apps' names	Keywords that list competitors, or a name that is only the category

The 4.2.6 row matters for publishing services: Apple wants an app from a template submitted by whoever owns its content. That is why the app should be listed in your own Apple Developer account, under your name or company.

Why do apps built with Lovable, Bolt and Base44 get 4.3?

Because the builder gives thousands of people the same starting point, and the reviewer has seen it before. A habit tracker, a fitness log or an AI chat app made in an afternoon tends to arrive with the same things:

The builder's default design: the same cards, buttons, fonts and empty states as every other app made with it.
A name and subtitle that only describe the category, such as "AI Fitness Coach: Track your workouts".
Screenshots of the template's sample data, or of screens the app doesn't really have.
A description written by the builder, which reads like every other one it writes.
A wrapper around the website that shares its native shell with every other app from the same wrapper service.
A category Apple calls saturated, with nothing that sets it apart.

None of this means your idea is spam. It means the version the reviewer saw doesn't show what makes it yours. Wrapped web apps often get a Guideline 4.2 rejection alongside 4.3, for looking like a website.

How to fix a 4.3 rejection

If you got 4.3(a): keep one app. Remove the duplicates from App Store Connect and put the variants inside it, as settings, locations or in-app purchases.
Give the app its own identity: a specific name (Apple allows 30 characters), your own icon and splash, and colours and type that aren't the builder's defaults.
Replace every template leftover: sample data, placeholder images, "Welcome to your app" text and default onboarding screens.
Make the difference real. Add the one thing your app does that the others in its category don't, and put it on the first screens a reviewer sees.
Retake the screenshots from the app itself, showing those screens with realistic data, and rewrite the description and keywords in your own words.
If the app is a wrapped website, rebuild it with native screens. A shared wrapper shell looks the same to review whatever site is inside it.
Resubmit the same app with a reply that explains what changed.

Don't resubmit it as a new app under another Bundle ID or a second developer account. That is exactly what 4.3(a) describes, and repeated attempts are what Apple says can lead to removal from the program.

What to write back to App Review, and when to appeal

Reply in App Store Connect when you resubmit. Reviewers decide 4.3 by comparing your app with others, so tell them what to compare:

Who the app is for and what it does that similar apps don't, in two or three sentences.
Where to see it: "Open the app, sign in with the demo account, then tap Plan to see the weekly programme it builds."
What you changed since the rejection: name, icon, screens and features.
That this is your only app with this content, if they suspect duplicates.
A demo account in the App Review information, so the reviewer can reach the parts that are different (Guideline 2.1).

If you believe the reviewer misunderstood the app, you can appeal to the App Review Board from Apple's App Review page. Apple asks for specific reasons the app complies, one appeal per rejected submission, and answers to any open questions from review first. Appeals work when the app really is different and the reviewer missed it; they don't fix an app that looks like a template.

Does Google Play reject apps for spam too?

Yes. Google Play's Spam policy doesn't allow apps that "merely provide the same experience as other apps already on Google Play". Its examples include copying another app's content without adding value, and publishing several apps with highly similar functionality, content and user experience.

The fix is the same as for Apple: one app per product, with its own name, icon, listing and features. For a new personal Play account, keep the 12-tester closed test in mind too: the testers have to try a real version of the app, not a placeholder.

Can you fix a 4.3 rejection yourself?

Often, yes. If it was 4.3(a), deleting the duplicates and resubmitting one app can be done in an afternoon. If it was 4.3(b) and your app already has something unique, new screenshots, a better name and a clear reply are often enough.

It gets harder when the app is a wrapped website or still looks like the builder's template, because then the fix is a real rebuild of the screens. That is the work we do: we turn the web app into a native React Native and Expo app with its own look, then handle the listing and the review replies. The launch checklist covers everything else reviewers check.

How LetsDeployIt helps

We rebuild AI-built web apps as native React Native and Expo apps that read as their own, with your name, icon and screens, not the builder's template. We write the listing, take screenshots from the real app, reply to App Review with what makes your app different and resubmit until it's approved. If it meets the store policies and we can't get it approved, you get your money back.

Try a free native preview of your app on your phone: letsdeploy.it.

Common questions about Guideline 4.3

What does Apple Guideline 4.3 mean?

It is Apple's spam rule. 4.3(a) forbids several Bundle IDs for the same app, and 4.3(b) forbids apps that can't be told apart from ones already widely available on the App Store.

Why was my AI-built app rejected for spam?

Usually because it looks like many other apps: the builder's default design, a generic name, template screenshots and copy, often in a crowded category. The reviewer couldn't see what makes it yours.

Can I just resubmit under a new Bundle ID?

No. Submitting the same app again under another Bundle ID is what 4.3(a) forbids, and repeated spam submissions can lead to removal from the Apple Developer Program. Fix the app and resubmit the same one.

Will changing the name and icon be enough?

Sometimes, if the app already does something different and the reviewer missed it. If it still looks and works like the template underneath, you also need screens and features that are clearly your own.

Should I appeal a 4.3 rejection?

Only if you believe the reviewer misunderstood an app that is already distinct. You appeal to the App Review Board with specific reasons it complies, one appeal per rejected submission.

Does a 4.3 rejection affect my developer account?

One rejection doesn't. Apple says repeated spam submissions may lead to removal from the Apple Developer Program, so fix the cause before you resubmit.

Can you fix my app after a 4.3 rejection?

Yes. We rebuild it as a native app with its own identity, redo the listing, reply to App Review and resubmit until it's approved, with resubmissions included.

Sources

Originally published on letsdeploy.it. Facts checked 2026-10-26.

App rejected for account deletion (Apple 5.1.1(v)): how to fix it

LetsDeployIt Team — Thu, 29 Oct 2026 14:54:31 +0000

Since June 30, 2022, Apple rejects any app that lets people create an account but not delete it from inside the app, under Guideline 5.1.1(v). Google Play asks for the same, plus a web link to request deletion. To fix it, add a Delete account option in your settings that deletes the account and its data, then resubmit.

Why was my app rejected for account deletion?

Because your app has a sign-up and no way to delete the account it creates. Apple has enforced this since June 30, 2022, and it is one of the most common rejections for apps built with Lovable, Bolt, Base44 or v0, because the builders add sign-up for you and never add the delete option.

You submit, wait two days, and the review note says your app "supports account creation but does not include an option to initiate account deletion". Usually nothing in the app is broken. Apple just wants people to be able to delete the account they made.

If your app supports account creation, you must also offer account deletion within the app.

Apple App Review Guideline 5.1.1(v)

It counts even if sign-up is only email and password, only Google sign-in, or a guest account the app creates on its own. If people can get an account from your app, they need a way to delete it there.

What does Apple accept as account deletion?

Apple accepts a delete option that is easy to find, usually in account settings, and that removes the account and the personal data that goes with it. Its account deletion page spells out the details:

Deactivating or disabling the account isn't enough. You can offer it, but not as the only option.
Delete the whole account record and the personal data tied to it, including content the person shared, such as posts, photos and reviews.
Don't make people call, email or chat with support to delete, unless your app is in a highly regulated field such as banking or health.
A link is fine if deletion finishes on your website, as long as it goes straight to that page.
It doesn't have to be instant. Tell people how long it takes and confirm when it's done.
One confirmation step is fine. Making deletion hard on purpose fails review.
If the person has an auto-renewing subscription, tell them billing continues through Apple and point them to cancel it first.
If you offer Sign in with Apple, revoke the person's Apple tokens when you delete the account.

Does Google Play require account deletion too?

Yes. Google Play has required it since May 31, 2024, and it asks for two ways in, not one:

An in-app path to delete the account and its data, easy to find, for example in settings.
A working web link where people can ask for deletion without the app installed. It must name your app or your developer name.

You give Google that link in the Data safety form in Play Console, under the data deletion questions. If you keep some data after deletion, for fraud prevention or legal reasons, say so in your privacy policy. The launch checklist covers the rest of the Data safety form.

How to add account deletion to your app

Most AI-built apps keep their users in Supabase, so the fix has two halves: a button in the app and a small server function that does the deleting.

Add a Delete account row at the bottom of your account or settings screen, in red so it reads as final.
Open a confirmation that says what gets deleted and how long it takes, with Delete and Cancel.
On Delete, call a server function (a Supabase Edge Function) with the signed-in user's session.
In that function, delete the user's rows in your tables (profiles, posts, bookings, uploads in Storage), then delete the user with Supabase's auth.admin.deleteUser.
Sign the person out and show a short "Your account has been deleted" screen.
Publish a deletion page on your website for Google Play, with your app's name and a form or email to request deletion.
Test it on a fresh account: sign up, add some data, delete, then check the user and their rows are gone in your database.

Why a server function: deleting a user in Supabase needs the service role key, and Supabase says never to put that key in the browser or the app. The app asks, the function checks who is asking and deletes only that user.

If your tables point at the user with a foreign key set to delete on cascade, deleting the user removes their rows too. Check that before you rely on it: files in Storage are not removed by a cascade.

Account deletion in Lovable, Bolt, Base44 and v0 apps

The steps are the same whichever builder you used. What changes is where your users are stored:

Builder	Where users usually live	What to ask for
Lovable	Supabase, through Lovable Cloud or your own Supabase project	A Delete account option in settings that calls an Edge Function to delete the user's data and the user
Bolt.new	Supabase, or Bolt Database on newer Bolt Cloud projects	The same, then check the user is gone from the database Bolt set up
Base44	Base44's built-in users	A delete account action, then check the user and their records disappear from your app's data
v0	Usually Supabase, connected through Vercel	The same Edge Function, or a server action in the Next.js app

A prompt that works in most builders: "Add a Delete account option at the bottom of the settings screen. Ask for confirmation, then delete all of this user's data and their auth account on the server, sign them out and show a confirmation." Then test it yourself on a fresh account. The builder will say it's done whether or not the user is really deleted.

Builder-specific steps for the stores: Lovable, Bolt.new, Base44 and v0.

What to write back to App Review

Resubmit with a short reply in App Store Connect that tells the reviewer exactly where to look. Reviewers test by hand, so a path they can follow saves a round trip.

Where the option is: "Account deletion is in Settings, then Delete account, at the bottom of the screen."
What it deletes: "It deletes the account and all its personal data."
How long it takes, if it isn't instant.
A demo account in the App Review information, so the reviewer can sign in and try it (Guideline 2.1).

Apps rejected for this are often rejected for something else in the same review. The Guideline 4.2 guide covers the most common one for AI-built apps.

Can you fix it yourself?

Yes. If your builder can add the button and the server function, and you test it on a fresh account, most people get this done in a few hours without help.

Where it gets harder is when deletion has to reach several places: Stripe customers, files in Storage, Sign in with Apple tokens and a web deletion page for Google Play. That's the kind of store work we do when we convert an app to native, and it's covered in our plans.

How LetsDeployIt helps

We convert your web app into a native React Native and Expo app, add account deletion that really deletes the account and its data, set up the web deletion page and Data safety answers for Google Play, and submit to both stores until approved.

Try a free native preview of your app on your phone: letsdeploy.it.

Common questions about account deletion

Is deactivating an account enough for Apple?

No. Apple says only offering to deactivate or disable an account is not enough. You can offer it alongside deletion, but not instead of it.

Can I ask people to email us to delete their account?

No, not unless your app is in a highly regulated field such as banking or health. Apple wants deletion started in the app, without calls, emails or support chats.

Does account deletion have to be instant?

No. A manual process is fine if you tell people how long it takes and confirm when the account has been deleted.

My app only uses Google sign-in. Do I still need account deletion?

Yes. Signing in with Google still creates an account in your app, so people must be able to delete it, along with its data.

Do I need a web page for account deletion?

For Google Play, yes. Google asks for a working web link where people can request deletion, entered in the Data safety form. Apple only needs the in-app option.

Why can't the app delete the Supabase user directly?

Because deleting a user needs Supabase's service role key, which must never be in an app or a browser. A server function holds the key and deletes only the user who asked.

Sources

Originally published on letsdeploy.it. Facts checked 2026-10-25.

How to get a Lovable app through Google Play's 12-tester closed test

LetsDeployIt Team — Thu, 29 Oct 2026 14:08:21 +0000

If your Google Play developer account is a personal one created after November 13, 2023, you need a closed test with at least 12 testers opted in for 14 days in a row before you can apply for production. Google then reviews the application, usually within 7 days. Organization accounts skip the test.

Do you need the 12-tester closed test?

You need it if your Google Play developer account is a personal account created after November 13, 2023. Until you meet the requirement, Play Console keeps Production and Pre-registration locked for your apps.

You finish your Lovable app, open Play Console, and find the publish button behind a two-week test. It catches a lot of first-time publishers, so check your account type before you plan a launch date.

Personal accounts created after November 13, 2023: closed test required.
Personal accounts created before that date: not affected.
Organization accounts: not affected. They need a registered business and a D-U-N-S number.

What counts as 12 testers for 14 days?

At least 12 testers must be opted in to your closed test when you apply, and they must have stayed opted in for the 14 days before that, without a break.

Opted in means the tester accepted your invite through the opt-in link, not only that you added their email.
A tester who opts in, leaves before day 14 and rejoins starts their 14 days again.
Google originally asked for 20 testers. Older posts that say 20 are out of date.

How to set up a closed test for a Lovable app

Lovable builds web apps, and Google Play needs an Android app, so the first step is a native build. We convert Lovable apps to React Native and Expo, which gives you an Android App Bundle (an .aab file) for Play and the same app for the App Store.

Create the app in Play Console and fill in the store listing basics.
Open Testing, then Closed testing, and create a track.
Upload your App Bundle to that track and roll out the release.
Add testers by email list or Google Group, choose your countries, and save. The opt-in link appears once the closed test release is published, which can take a few hours.
Send the opt-in link to your testers. They accept it with their Google account, then install the app from Google Play.

Your listing, content rating and Data safety form are needed for production anyway, so fill them in now. The Lovable launch checklist lists everything else the stores ask for.

Where to find 12 testers for Google Play

Start with people who already care about your app: they stay opted in and give useful feedback, which you need for the production application.

Friends, family and colleagues with an Android phone.
Your own users: the people already using the web version of your Lovable app.
Your waitlist, newsletter or social followers.
Communities where builders swap testing, such as tester-swap groups and forums. Offer to test their app in return.

Invite 15 to 20 people, not 12. Someone always forgets to accept the invite or uninstalls on day 6, and every drop below 12 delays your application.

The closed test problems nobody warns you about

Testers added but not opted in. Adding an email does nothing until that person accepts the opt-in link. Check the count in Play Console, not your invite list.
Google Group members who never joined. Testers in a Google Group must join the group before they can opt in. Check the group lets people outside your organization join, then confirm the opted-in count in Play Console.
Low engagement. Google can ask you to keep testing if testers didn't use the app. Ask them to open it a few times and send you feedback.

Use the 14 days well: fix what testers report and finish your store listing, so the build you send to production is better than the one you started with.

How to apply for production access

Once 12 testers have been opted in for 14 days, apply from the Play Console dashboard. The form has three parts: your closed test, your app, and your production readiness.

How easy it was to recruit testers.
How testers engaged with the app.
A summary of their feedback and what you changed because of it.
Who the app is for and why it is ready for production.

Answer with specifics: the bugs testers found and what you fixed. Review usually takes 7 days or less. If Google asks for more testing, the usual reasons are fewer than 12 opted-in testers or too little engagement.

Can you do the closed test yourself?

Yes. The closed test is free and every step above is something you can do on your own. What it takes is 12 to 20 willing testers and two weeks of reminding them.

If you would rather not, we run it for you with vetted testers as part of getting your app on Google Play, alongside the native build and the store work. You can also skip it with an organization account if you have a registered business.

How LetsDeployIt helps

We convert your Lovable app to a native React Native and Expo app, run the 14-day closed test with vetted testers, prepare the listing and Data safety form, and submit to Google Play and the App Store until approved.

Try a free native preview of your app on your phone: letsdeploy.it.

Common questions about Google Play's closed test

Do testers have to use the app every day?

No, Google doesn't ask for daily use, but testers must stay opted in for all 14 days, and Google can ask for more testing if they barely used the app.

What happens if a tester leaves before day 14?

They stop counting. You need 12 testers opted in for the full 14 days when you apply, which is why inviting 15 to 20 people is safer.

Does an organization account skip the closed test?

Yes. The requirement only applies to personal accounts created after November 13, 2023. Organization accounts need a registered business and a D-U-N-S number.

How long does Google take to approve production access?

Usually 7 days or less after you apply, sometimes longer. Count on about three weeks from the start of the closed test to production access.

Is it 12 or 20 testers?

Google originally asked for 20, so older guides that say 20 are out of date.

Can I put a Lovable app on Google Play without the closed test?

Only with an organization account or a personal account created before November 13, 2023. Either way, you still need a native Android build of the app.

Sources

Originally published on letsdeploy.it. Facts checked 2026-10-22.

How to publish a Lovable app to the App Store and Google Play

LetsDeployIt Team — Thu, 29 Oct 2026 14:04:25 +0000

Lovable can't publish to the App Store or Google Play by itself. It builds web apps, and its own docs say it has no built-in flow to package or submit a project to either store. Your options are a PWA (not listed in the App Store), a wrapper around your published site, or converting the app into a native React Native app.

Can Lovable publish to the App Store?

Not directly. Lovable builds web applications: apps created from May 13, 2026 use TanStack Start, and older apps use React and Vite. Publishing always deploys your project to a web address.

Lovable also has an app for iOS and Android, but that is for building with Lovable on your phone. It does not turn your project into an app you can list in the stores.

Lovable builds web applications, which you can design to be fully mobile friendly, and it does not generate React Native projects.

Lovable FAQ

Your options: PWA, wrapper or native app

Progressive Web App

How it works: People add your site to their home screen from the browser.
Stores: Not in the App Store. Google Play only through a Trusted Web Activity.
Watch out for: It isn't where most people look for apps.

Wrap your site

How it works: A native shell, for example Capacitor, loads your published site.
Stores: Possible on both.
Watch out for: Apple rejects apps that are mostly a repackaged website (Guideline 4.2).

Convert to a native app (recommended)

How it works: Your screens are rebuilt as a React Native and Expo app.
Stores: Yes, both.
Watch out for: More work than a wrapper, but much less likely to hit Guideline 4.2.

Lovable's own docs suggest the first two. A wrapper is the quickest route into the stores, but it is also the one most likely to run into Apple's Guideline 4.2. If that has already happened, see how to fix a Guideline 4.2 rejection.

Lovable PWA vs a real app

Lovable's docs suggest turning your published app into a Progressive Web App that people add to their home screen. It is still your website; it just opens like an app once installed.

	Lovable PWA	Native app
Listed in the App Store	No	Yes
Listed on Google Play	Only through a Trusted Web Activity	Yes
How people install it	Add to Home Screen from the browser	From the store
Push notifications on iPhone	iOS 16.4 and later, once added to the Home Screen	Yes
Phone features	What the browser allows	Full native access
Updates	Instant, like your website	Through store review
Cost	Free	$99 a year (Apple) and $25 once (Google), plus the build

A PWA is enough for internal tools, for testing an idea, or when your users already find you through your website. You need a real app when your users look in the App Store or on Google Play, when you sell digital features (which need Apple's and Google's in-app purchase), or when you need reliable push notifications on iPhone.

Can Lovable export to React Native or Expo?

No. Lovable doesn't generate React Native, so it can't output an Expo project either. What you can export is your web code:

Two-way GitHub sync with github.com, on every plan.
A .zip download of the whole codebase, on paid plans.
Your backend (Lovable Cloud, Supabase or third-party APIs), which a native app can keep using.

React Native and the web both use React, but they render different things. A web app draws HTML styled with CSS; a React Native app draws native views and uses native navigation. So getting to React Native means converting the app:

Carries over	Has to change
Your backend (Lovable Cloud, Supabase or your APIs)	Every screen's UI components
Business logic and data fetching	Routing and navigation
Your design and brand	Sign-in redirects and web-only libraries
Your content and users	Payments for digital goods, which must use Apple's and Google's in-app purchase

You can rewrite it in Expo yourself, rebuild it with an AI builder that outputs React Native, or have it converted. Our Export plan hands you the converted React Native and Expo source code; see pricing.

Getting a Lovable app on Google Play

An Android App Bundle (.aab). New apps have had to publish as App Bundles since August 2021.
A target API level of Android 16 (API 36) or higher, for new apps and updates from August 31, 2026.
A developer account, with a one-time $25 registration fee.
A Data safety form and a privacy policy, even if your app collects no data.
A closed test, if your personal account was created after November 13, 2023: at least 12 testers opted in for 14 days before you apply for production access.

A PWA can reach Google Play through a Trusted Web Activity, which Google documents and supports with its Bubblewrap tool, but the app still shows your website. A native conversion gives you one app for both stores. More on the 12-tester requirement.

What you need before you submit

Developer accounts on both stores, a privacy policy, privacy labels, account deletion, a demo login for reviewers and store screenshots. The full list, with every fee, is in the Lovable launch checklist and costs.

How LetsDeployIt helps

We convert your Lovable app into a native React Native and Expo app, then handle the store work: icons, screenshots, privacy labels, signing, submission and reviewer replies. Preview the native version on your phone for free, then pick a plan on our pricing page.

Try a free native preview of your app on your phone: letsdeploy.it.

Common questions about publishing from Lovable

Does Lovable have a button to publish to the App Store?

No. Lovable's docs say it has no built-in flow that packages and submits a project to the App Store or Google Play. Publishing in Lovable deploys your app to a web address.

Can I submit my Lovable PWA to the App Store?

Not as a PWA. The App Store only lists native apps. To get in, you need to wrap the site in a native shell or convert it into a native app.

Will Apple accept a Lovable app wrapped with Capacitor?

Sometimes, but it is risky. Apple's Guideline 4.2 asks apps to go beyond a repackaged website, and a wrapper that only loads your site is the classic case it rejects.

Does Lovable support React Native or Expo?

No. Lovable's docs say it builds web applications and does not generate React Native projects, so it can't output an Expo project either.

Can I export my Lovable code?

Yes. Lovable offers two-way GitHub sync on every plan and a full .zip download of the codebase on paid plans. The code is yours, but it is web code.

Can I put my Lovable app on Google Play?

Yes, but not from Lovable directly. You need an Android build of the app, a Google Play developer account and, for new personal accounts, a 14-day closed test with 12 testers. A PWA can also go on Play through a Trusted Web Activity.

Will my Supabase backend still work in a native app?

Yes. The backend doesn't change. The native app talks to the same Supabase project, so your data and users carry over.

Do I have to stop using Lovable?

No. Lovable can keep powering your website, and you can sync your Lovable code to GitHub at any time.

Sources

Originally published on letsdeploy.it. Facts checked 2026-10-12.

The best ways to publish a Lovable app to the App Store and Google Play

LetsDeployIt Team — Thu, 29 Oct 2026 14:04:00 +0000

There are three routes. Wrapper services like Median, Despia and Natively put your published Lovable app inside a native app; Capacitor does the same, but you build it yourself; LetsDeployIt rebuilds the app as native React Native and does the store work for you. Wrappers are cheaper and update with your website; a native rebuild is the safest route through App Review.

Every option at a glance

Option	How the app is built	Who submits	Starting price
Median	Your live site in a native shell	You, or Median's publishing service	Free plan; Starter $229 once, then $179 a year
Despia	Your web app in Despia's native runtime	You, with one-click publishing	$249 once for one platform, $498 for both
Natively	Your site in a native shell	You, or Natively's publishing service from $600	$19 a month, or $699 once
Capacitor	Your site in a WebView, built by you	You, with Xcode and Android Studio	Free and open source
LetsDeployIt	Rebuilt as a native React Native app	Us, approved or refunded	Free preview, then a flat fee

Prices are from each company's own pricing page, checked on the date above.

Wrapper services: Median, Despia and Natively

All three take the Lovable app you've published and run it inside an app, adding native features like push notifications through plugins. Your website stays the source of truth, so updates go live without a store review. The catch is App Review: an app that is mostly your website is what Apple's Guideline 4.2 rejects, so the native features you add matter.

Median vs LetsDeployIt: the longest-running wrapper, with an optional publishing service.
Despia vs LetsDeployIt: a one-time price and a runtime with 40+ native features.
Natively vs LetsDeployIt: a monthly or lifetime plan and a website-to-app builder.

Capacitor: wrap it yourself

Capacitor is Ionic's free, open-source runtime for running a web app on iOS and Android. It suits developers: you add it to your Lovable code, build with Xcode (which needs a Mac) and Android Studio, and do the signing, store listings and submission yourself. See Capacitor vs LetsDeployIt.

A native rebuild: LetsDeployIt

We convert your Lovable app into a native React Native and Expo app on the same backend, then do every store task: icons, screenshots, privacy labels, signing, submission and replies to reviewers. You preview the native app on your phone for free before you pay, and if a compliant app isn't approved, you get your money back.

How to choose

You want the lowest price and are happy to do the store work: a wrapper service or Capacitor.
You change your app every day and want updates without store review: a wrapper.
You want the app to pass review the first time and someone else to handle the stores: a native rebuild.
You'd rather pay someone to do it for you, but not a wrapper: compare DIY, a freelancer and an agency.

How LetsDeployIt helps

We rebuild your Lovable app as a native React Native and Expo app, do all of the store work and submit it to both stores, approved or your money back. See pricing.

Try a free native preview of your app on your phone: letsdeploy.it.

Common questions about publishing a Lovable app

What's the cheapest way to get a Lovable app on the App Store?

Capacitor is free, but you build and submit the app yourself and still pay Apple's $99 a year. Among paid tools, Median has a free plan and Despia starts at $249 once for one platform.

Will Apple accept a wrapped Lovable app?

Sometimes. Apple's Guideline 4.2 rejects apps that are mostly a repackaged website, so a wrapped app needs native features and app-like navigation to pass.

Which option updates without a store review?

Wrappers do, because the app shows your live website. A native rebuild like ours goes through store review for changes to the app's screens.

Which options submit the app for me?

LetsDeployIt does, on every plan that includes submission. Median and Natively offer publishing services on top of their plans; with Despia and Capacitor you submit yourself.

Do any of them guarantee approval?

Median's publishing service has a money-back publishing guarantee and Natively advertises a release guarantee. We refund the full fee if a compliant app isn't approved.

Sources

Originally published on letsdeploy.it. Facts checked 2026-10-12.