Guideline 4.2 Minimum Functionality: when App Review says your app isn't "app-like" enough

There's no feature count and no checklist behind this. It's a judgment call by the reviewer, which is why the same app can pass one week and be rejected on the next update. The sub-points narrow it down a little:

Apple doesn't publish a count for 4.2 alone. Its 2025 Transparency Report puts 415,532 rejections under Design, a category it describes as covering "copycat apps, apps with minimum functionality, and spam" — so 4.2 shares that number with Guideline 4.3.

Almost every 4.2 rejection posted on Apple's developer forums uses one of three messages. Work out which one you got — the fix is different for each.

1. "Not sufficiently different from a mobile browsing experience"

This is the web-wrapper rejection. It hits apps built as a WKWebView around an existing site, and many hybrid apps whose main screens are web content. Apple's App Review page is blunt about it: "Websites served in an iOS app, web content that is not formatted for iOS, and limited web interactions do not make a quality app."

2. "Limited by the minimal amount of content or features"

This is the thin-app rejection: a single calculator, a timer, a one-screen tracker, a soundboard. The same message usually goes on to say Apple expects apps to "provide valuable utility or entertainment" and to "enable people to do something they couldn't do before or in a way they couldn't do it before."

3. "Main functionality is to market your service"

This is 4.2.2: an app for a gym, clinic, agency or restaurant that shows opening hours, a gallery and a contact button. The business is real; the app gives the user nothing to do.

Developers often respond by adding iOS features until the app feels busier. Apple's own rejection text rules out the most common ones. What reviewers respond to is a task the user completes inside the app.

Native code helps, but it isn't the test. A Swift app that shows three static screens is rejected for the same reason as a web wrapper. A web-heavy app can pass if the part users spend time in is a proper app experience.

This catches agencies and no-code builders that publish one app per client from their own developer account. Apple gives two acceptable routes:

• The client submits under their own account. The restaurant, gym or school enrolls in the Developer Program and the app ships from their account, not the agency's.
• One "picker" app for all clients. A single binary that hosts every client's content — Apple's examples are a restaurant finder with a page per restaurant, or an event app with an entry per event.

Using a template or boilerplate for your own app is a different matter. That's allowed under 4.2.6, but if the result looks like many other apps in the store, expect Guideline 4.3 Spam instead.

1. 01

   Name the gap honestly

   Write one sentence describing what a user does in your app that they can't do as well in Safari or in five minutes with Notes. If you can't, that's the work.

2. 02

   Build one core task natively

   Pick the job users came for and make it work end to end inside the app: create, save, revisit. Depth in one task beats a long list of shallow features.

3. 03

   Move the value to the first screens

   The reviewer should reach the core task within a minute. Cut splash content, marketing pages and forced sign-up in front of it.

4. 04

   Explain it in the review notes

   List the native features, where to find them, and a demo account if one is needed. A missing demo login is its own rejection under Guideline 2.1.

5. 05

   Update the screenshots to match

   Show the core task in use. Screenshots of an app the reviewer can't find run into Guideline 2.3.

Hello App Review team,

Thank you for the feedback on Guideline 4.2.

Build [number] changes how the app works, not only how it looks:
- [Core task] is now built natively: users can [create / log / edit]
  [thing], and it is saved on the device and available offline.
- Added [widget / Shortcuts action / HealthKit sync] for [reason].
- Removed the web view that previously showed [section].

To try it: launch the app > tap [button] > [action].
Demo account (if needed): [username] / [password]

Thank you,
[Name]

If you believe the app already meets 4.2, you can appeal the decision to the App Review Board, or book a Meet with App Review session to ask what the reviewer expected. Appeals on 4.2 rarely succeed without changes, because the guideline is a judgment call and the reviewer has already made it.