Rejected Under Apple Guideline 4.2? How to Get Your Wrapped Web App Approved

You wrapped your Lovable, Bolt or Base44 app with Capacitor, uploaded it to App Store Connect, and a day later the answer came back: Guideline 4.2 - Design - Minimum Functionality. The message usually says the app is not sufficiently different from a mobile browsing experience.

Apps that started life as websites hit this rejection more than any other. It is fixable, and usually without a rebuild, once you know what the reviewer is comparing your app against.

What guideline 4.2 says

Guideline 4.2 asks that your app include features, content and UI that elevate it beyond a repackaged website. If an app is not useful, unique or "app-like", Apple says it does not belong on the App Store.

Two related rules matter for AI-built apps:

• 4.2.2: apps should not primarily be marketing material, web clippings, content aggregators or a collection of links.
• 4.2.6: apps created from a commercialized template or app generation service are rejected unless they are submitted directly by the provider of the app's content. In practice: submit the app from your own Apple Developer account (or your company's), not from an agency's or a generator's account.

Apple does not ban Capacitor or web technology. Plenty of approved apps run on web views. What gets rejected is an app that gives the user nothing they would not get by opening the website in Safari.

Why wrapped vibe-coded apps get flagged

The reviewer opens your app and compares it with your website. These are the signs that make it look like a repackaged site:

• It is the website, pixel for pixel. Same header, same footer, same hamburger menu, same cookie banner, sometimes even a "Download our app" banner inside the app.
• It loads your live site. Setting server.url in capacitor.config to your production domain turns the app into a browser pointed at one address. Capacitor's own configuration docs say this option is for live reload during development and not intended for production.
• No connection, blank screen. Turn on airplane mode and the app shows a white page or a browser error.
• Links escape the app. Tapping around opens pages that look like a browser, or sends the user to Safari for basic tasks like signing up or paying.
• Nothing uses the phone. No notifications, no sharing, no camera, no haptics, nothing a website could not do.

How to pass: make it an app, not a website in a frame

1. Bundle the build instead of loading your site

Ship the built files inside the app. For a Vite project (which is what Lovable and Bolt generate), the config should point at the build output and should not contain a production server.url:

// capacitor.config.ts
import type { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  appId: 'com.yourcompany.yourapp',
  appName: 'Your App',
  webDir: 'dist',
  // no server.url here in production builds
};

export default config;

Then run npm run build and npx cap sync before every native build. Your app still talks to Supabase or your API as before; only the interface is bundled.

2. Remove the parts that only make sense on a website

Check whether you are running inside the app and hide web-only elements: the marketing header and footer, cookie banners, "get the app" prompts and links to your blog or pricing pages.

import { Capacitor } from '@capacitor/core';

const isApp = Capacitor.isNativePlatform();

// e.g. {!isApp && <MarketingFooter />}

Use app-style navigation instead: a bottom tab bar for the main sections, screens that slide in, and a back gesture that works.

3. Add native features that genuinely help your users

You do not need all of these. Pick the ones that make sense for your app and make them visible early, because the reviewer will not dig for them:

• Push notifications for events a user would want on their lock screen: a reply, a delivery update, a booking reminder.
• Offline handling with the Network plugin: show a proper "you're offline" screen and cached content instead of a blank page.
• Native sharing so users can send content to WhatsApp, Messages or email from the system share sheet.
• Camera and photos where the app needs uploads, using the native picker.
• Biometric login (Face ID) for returning users.
• Haptics, a native splash screen, a styled status bar and a proper app icon.
• Deep links so shared links and login emails open the right screen in the app.

The test is simple: could a user explain why they would install your app instead of bookmarking the site? If yes, you are in good shape.

4. Make the app complete for the reviewer

Many 4.2 rejections come with other issues from guideline 2.1 (app completeness). Before you resubmit:

• Give the reviewer a working demo account in App Store Connect, with sample data, so they see the real app and not just a login screen.
• Make sure there are no placeholder screens, broken links or "coming soon" sections.
• Test on a real iPhone, not only the simulator, including with a slow or missing connection.

How to reply to a 4.2 rejection

1. Read the rejection message carefully. Note any other guidelines it mentions.
2. Make the changes above, increase the build number and upload the new build.
3. In the Review Notes, list what changed and where to find each native feature, for example: "Push notifications for order updates (Orders tab), offline mode with saved orders, native share sheet on every product, Face ID login."
4. Reply in the Resolution Center that you have submitted a new build that addresses the feedback.

If you believe the reviewer misjudged an app that already offers real native value, you can submit an appeal to the App Review Board. Fixing the app is usually faster than appealing.

When a rebuild makes more sense

Capacitor plus native features is enough for most apps. Consider rebuilding the screens in React Native or Flutter, while keeping your Supabase backend, if the app is your core business, needs smooth animations and gestures throughout, or relies heavily on background tasks and device hardware. See our full guide to publishing a Lovable app for how the two routes compare.

We take apps built with Lovable, Bolt, Base44, Cursor and Replit through App Store review: bundling the build, adding the native features reviewers look for, fixing login and deep links, and handling the replies to App Review until the app is approved. See how we ship vibe-coded apps to the stores, or message us on WhatsApp with your rejection message for a free assessment.

Frequently asked questions

Will adding push notifications alone get my app approved?

Sometimes, but do not count on one feature. Reviewers look at the whole experience. Combine a few useful native features with app-style navigation and removing website-only elements.

Can I submit my app from my developer's Apple account?

Under guideline 4.2.6, apps made with app generation services should be submitted by the provider of the app's content. Use your own or your company's Apple Developer account and add your developer as a team member.

Do I need a new app record after a rejection?

No. Fix the app, upload a new build with a higher build number to the same app in App Store Connect, and submit it for review again.