Apple rejected your app under “Guideline 4.2 - Design - Minimum Functionality”: what it means and how to get approved

The short answer

Apple's reviewer decided your app is a website in an app's clothing. Guideline 4.2 asks for “features, content, and UI that elevate it beyond a repackaged website”, and a Lovable, Bolt or Replit web app wrapped with Capacitor or a WebView often shows none. To get approved, make the app do things the website can't, make it look and behave like an iPhone app, and tell the reviewer exactly where to find those things. If a phone adds nothing to what your app does, the honest fix is a native build, or no app yet.

What the rejection says

The message in App Store Connect usually reads like this. It's the wording developers have posted on Apple's own developer forums, and yours may differ slightly:

Guideline 4.2 - Design - Minimum Functionality

Your app provides a limited user experience as it is not sufficiently
different from a mobile browsing experience. As such, the experience it
provides is similar to the general experience of using Safari. Including
iOS features such as push notifications, Core Location, and sharing do not
provide a robust enough experience to be appropriate for the App Store.

It points at guideline 4.2 of Apple's App Review Guidelines, which opens:

Your app should include features, content, and UI that elevate it beyond
a repackaged website. If your app is not particularly useful, unique, or
“app-like,” it doesn’t belong on the App Store. If your App doesn’t provide
some sort of lasting entertainment value or adequate utility, it may not be
accepted.

Some rejections cite 4.2.2 instead: “Other than catalogs, apps shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.” Same problem, same fix.

Read the last sentence of the rejection again. Apple is saying that push notifications, location and a share button, on their own, don't make an app. Adding features only to tick boxes is how a second submission ends up with the same rejection.

Why wrapped web apps get it

Capacitor and similar tools put your web app inside a native shell that displays it in a WebView. That's a legitimate way to build an app, and plenty of approved apps work this way. The problem is that a straight wrap still behaves like a website: a hamburger menu instead of a tab bar, links that open more web pages, a blank screen with no connection, a login that bounces out to a browser, and nothing that uses the phone.

The worst case loads your live website by URL instead of shipping the app's files inside it. In Capacitor that's the server.url setting, which Capacitor's own documentation says “is not intended for use in production.” Bundle the built app instead, so the app itself opens without a connection and doesn't change every time the website does:

// capacitor.config.ts: no server.url, so the app ships its own files
import type { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  appId: 'com.yourcompany.yourapp',
  appName: 'Your App',
  webDir: 'dist',
};

export default config;

Run npm run build and then npx cap sync before every native build, so the app gets your latest code. webDir must contain a finished index.html: dist is right for Vite apps, which covers older Lovable projects and most Bolt ones. An app that renders its pages on a server, such as a newer Lovable project on TanStack Start, has to be set up to produce static files before it can be bundled like this.

What makes an app more than a repackaged website

Apple doesn't publish a checklist, so nothing here guarantees approval. What it asks for is an app that's useful as an app, so choose the changes that serve what yours is for:

• Native navigation. A bottom tab bar for the main sections, a back gesture that works, and no website header, footer or cookie banner. Remove links that lead out to your marketing site.
• Push notifications people would want: an order shipped, a booking confirmed, a reply to their message. Apple says they won't carry the app alone, but as part of a real workflow they count. @capacitor/push-notifications or OneSignal handle the native side.
• Offline behaviour. Show the last data the user loaded and a clear offline message, instead of a blank WebView or the browser's error page.
• Device features tied to the core job: the camera for photos and documents, local notifications for reminders, the native share sheet.
• Things that make it personal: saved items, history, settings. Apple's guidelines say that if your app doesn't include significant account-based features, people should be able to use it without a login, so don't add a login wall just to look substantial.
• No web giveaways: no pinch-zoom on the layout, no text that highlights when tapped, nothing hidden under the notch, and external links opened in an in-app browser (@capacitor/browser) rather than replacing your app.

Offline handling takes a few lines with Capacitor's official Network plugin (npm install @capacitor/network, then npx cap sync). A hook like this lets any screen swap a blank page for a proper offline state:

import { useEffect, useState } from 'react';
import { Network } from '@capacitor/network';

export function useOnline() {
  const [online, setOnline] = useState(true);

  useEffect(() => {
    Network.getStatus().then((status) => setOnline(status.connected));
    const listener = Network.addListener('networkStatusChange', (status) => {
      setOnline(status.connected);
    });
    return () => {
      listener.then((handle) => handle.remove());
    };
  }, []);

  return online;
}

The other rules that tend to come with it

An app that clears 4.2 can still fail on another guideline. Check these before you resubmit:

• Login services (4.8). If users can sign in with Google, Facebook or another social login, Apple requires an equivalent option that limits data collection to name and email, lets users keep their email private, and doesn't collect their activity for advertising without consent. Sign in with Apple meets all three, which is why it's the usual answer.
• Account deletion (5.1.1(v)). If people can create an account in the app, they must be able to delete it in the app.
• A demo account (2.1). If anything sits behind a login, put working credentials in the App Review Information section of App Store Connect. A reviewer who can't get past the sign-in screen sees a web login page and nothing else.
• In-app purchase (3.1.1). If the app unlocks digital features or content, such as a subscription to your software or credits, Apple's rule is in-app purchase, and a Stripe checkout inside the app won't pass. The rules on linking out to buy on your website vary by country; apps on the US storefront may include those links and buttons. Physical goods and real-world services are the opposite: under 3.1.3(e) they must use a payment method other than in-app purchase.
• Who submits it (4.2.6). Apps made with a template or app-generation service are rejected unless they're “submitted directly by the provider of the app’s content”. Publish from your own Apple Developer account, not a builder's.

How to reply in App Store Connect

Replies go through the App Review section of App Store Connect, which used to be called the Resolution Center. Open the app, click the link at the top of the page that says there are unresolved issues, click Resolve next to the submission, then Reply to App Review. You can attach screenshots and other files, and keep the conversation going until you resubmit. A 4.2 rejection is about what the app does, so the fix also means uploading a new build.

Say what changed and where to see it, in steps a reviewer can follow:

Hello App Review team,

Thank you for the feedback. We've rebuilt the app around native features:

1. Native tab navigation (Home, Orders, Messages, Account). The app no
   longer shows any website header, footer or external links.
2. Push notifications for order updates and new messages. To see one,
   sign in with the demo account and place a test order from Home.
3. Offline mode. Orders and messages stay readable without a connection,
   with a clear offline banner.
4. Camera capture for receipts on the Orders screen.

The demo account is in App Review Information. Screenshots of each
feature are attached.

If you believe the app already met the guideline and the reviewer missed something, say that in the reply first. Apple asks you to reply to the rejection before appealing. If that doesn't resolve it, you can file one appeal per rejected submission with the App Review Board, citing the guideline and explaining point by point how the app meets it.

When to rebuild in React Native instead

Wrapping is the right call when the web app is solid and the phone genuinely adds something: notifications, the camera, offline access. Rebuild the key screens natively, in React Native (usually with Expo) or Flutter, when:

• The app has been rejected under 4.2 more than once and the native additions are starting to feel forced.
• Most of the value is in the interface itself: long lists, gestures, maps or media that feel sluggish in a WebView.
• It needs things a WebView handles badly: background location, home-screen widgets, deep links into system features, or reliable offline sync.
• You're building a real mobile product rather than a companion to the website, and the code will live for years.

React Native is usually the shorter path for a Lovable or Bolt app, because the business logic, the API calls and the Supabase client are already JavaScript and carry over. The screens are what get rebuilt.

If you'd rather hand it over

Getting a web-built app through review is mostly judgment: which native features earn their place, what to take out, and how to explain it to App Review. If you'd like that handled, from the native build to submission and the back-and-forth with review, that's what my App Store and Google Play launch service covers.