A minimum functionality rejection is guideline 4.2, and Google Play does not call it that.
On the App Store it is App Store Review Guideline 4.2, titled Minimum Functionality, and it sits inside section 4 of the guidelines, Design. The test Apple prints is whether your app includes features, content and UI that elevate it beyond a repackaged website. If the app is not particularly useful, unique or app-like, Apple says it does not belong on the App Store. Google Play enforces much the same thing under a different name, which is why searching Google's policies for the words minimum functionality finds nothing. Every guideline number and policy name below comes from Apple's and Google's own pages, read on 21 October 2026. For how often this happens at all, and what Apple does and does not publish about it, see app store rejection rates.
What follows is the guideline numbers on both stores, the examples each one prints, the two subsection numbers under 4.2 that are now retired, and the one lever that gets a bug fix out of the door while a 4.2 argument is still open.
Start hereThe short version
Rejected under 4.2 means the reviewer found too little app.
Most rejections name a thing. A missing permission string, an icon with the wrong channel, a login the reviewer could not get past. 4.2 names a shortfall instead. It says the app you submitted does not do enough to be worth a slot on the store, and no file in your project is the cause. That is why it reads as unfair and why the fix is slower than it looks.
Apple puts the rule in the Design section and introduces that section as the minimum standards for approval. Google puts its version in a policy whose current title is Functionality, Content, and User Experience, under a parent section called Spam, Functionality, and User Experience. Neither store gives you a threshold. Neither counts screens, features or lines of code. Both give you a short list of named examples, and those examples are the only concrete thing you have to work with.
Which guideline number is a minimum functionality rejection?
Guideline 4.2. The App Store Review Guidelines page prints its own date, and on 21 October 2026 that date read 16 October 2026, so these numbers are the live ones. Section 4 is Design. Inside it, 4.1 is Copycats, 4.2 is Minimum Functionality and 4.3 is Spam. They sit together for a reason: each one asks whether your app deserves a slot next to what is already on the store. None of them asks whether it works.
Under 4.2 there are seven numbered subsections, and two of them are gone. 4.2.4 and 4.2.5 both read, in full, Intentionally omitted. Apple retired the rules and kept the numbers so the rest of the numbering did not shift. This matters if you are reading advice written a few years ago, because a page that tells you to comply with 4.2.4 is quoting a rule that is no longer there. Check the number against the live guidelines before you act on it. The live ones are 4.2.1 for ARKit apps, 4.2.2 for marketing materials and link collections, 4.2.3 for apps that lean on another app or on a first launch download, 4.2.6 for commercialized templates and app generation services, and 4.2.7 for remote desktop clients.
One number people reach for by mistake is 2.1. If the reviewer said your app crashed, would not install or showed placeholder content, that is guideline 2.1(a) App Completeness, which says Apple will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems. It is a different rule with a different fix. A 2.1 rejection gives you a defect to chase. A 4.2 rejection gives you an opinion to answer. Read the number in the message before you decide which problem you have.
Apple, App Store Review Guidelines, page dated 16 October 2026, read 21 October 2026
Find your rule
Which rule the reviewer is reading
Tick what the reviewer said about your app. The guideline numbers and policy names are the ones each store prints today.
Nothing ticked. Read the rejection message again and find the sentence that describes your app, not the sentence that describes the rule.
What examples does Apple actually give?
Fewer than you would hope, and they are worth reading literally. The body of 4.2 asks for features, content and UI that elevate the app beyond a repackaged website, and for some sort of lasting entertainment value or adequate utility. Then it redirects two whole categories off the App Store. An app that is simply a song or a movie belongs in the iTunes Store. An app that is simply a book or a game guide belongs in the Apple Books Store. If your app is a container for one piece of content, that is the sentence you are arguing with.
4.2.2 is the one that catches honest work. Other than catalogs, Apple says, apps should not primarily be marketing materials, advertisements, web clippings, content aggregators or a collection of links. Read that list against what you built. A restaurant app that is a menu, an address and a phone number is marketing material. A news app that only pulls other people's feeds is a content aggregator. The catalogs exception is real and narrow, and it is the only exception in the sentence.
4.2.3 has two parts that people run into separately. The first says your app should work on its own without requiring installation of another app to function, which rules out a companion app that is useless by itself. The second says that if your app needs to download additional resources in order to function on initial launch, you must disclose the size of the download and prompt users before doing so. That second one is a build decision, so it is cheaper to get right before you submit than after. 4.2.1 covers ARKit, where merely dropping a model into an AR view or replaying animation is not enough, and 4.2.7 covers remote desktop clients with five lettered conditions, including that the host device must be a personal computer or dedicated game console the user owns, on the same local network.
The rule next door is the one nobody expects. 4.3 Spam says Apple will not accept new submissions in certain well established categories unless they offer a meaningfully different or improved experience, and it names them: dating, flashlight, sound effects, wallpaper, simple timers and fortune telling. It adds that apps it calls mediocre, low-quality or low-effort, naming drinking games, Kama Sutra, fart and burp apps, do not add value, and that repeated submissions of that kind may lead to removal from the Apple Developer Program. If your app is in one of those categories you can be rejected on quality without ever hitting 4.2. The same guidelines page is the source for both, which makes checking cheap.
Apple, App Store Review Guidelines, sections 4.2 and 4.3, read 21 October 2026
Does Google Play have the same rule?
It does, and the name has changed, which is the single most useful thing on this page. Google's old policy address for it still carries the words spam and min functionality in the path, and on 21 October 2026 that address lands on a Play Console Help article titled Functionality, Content, and User Experience. The parent section of the policy centre is titled Spam, Functionality, and User Experience. So the phrase minimum functionality is Apple's heading and a historical Google URL, and it is not the name of anything Google publishes today. Quoting it to a reviewer or in a policy appeal will not match a page they can open.
The policy itself is short. Apps should provide a stable, responsive and engaging user experience, and apps that crash, do not have the basic degree of adequate utility as mobile apps, lack engaging content, or behave in other ways inconsistent with a functional and engaging user experience are not allowed on Google Play. Under that sit two numbered parts. Part 1, Limited Functionality and Content, names apps that are static without app-specific functionalities, with text only and PDF file apps given as the example, then apps with very little content and no engaging user experience, with single wallpaper apps given as the example, then apps designed to do nothing or have no function. Part 2, Broken Functionality, names apps that do not install, apps that install but do not load, and apps that load but are not responsive.
Two structural differences change where you look. First, a crash is inside this policy on Google Play and outside it on the App Store, where it is 2.1(a). Second, the website wrapper case is the other way round. Apple folds it into 4.2 with the phrase repackaged website. Google puts it in a separate Spam policy, under Webviews and Affiliate Spam, which bars apps whose primary purpose is to drive affiliate traffic to a website or to provide a webview of a website without permission from the website owner or administrator. That permission clause has no Apple equivalent, so an approved wrapper on one store tells you nothing about the other.
One thing to note before you cite Google on a date. The Apple guidelines page carries a last updated line, so a figure taken from it can be dated honestly. The Google article does not. We read the page source on 21 October 2026 and the only last updated strings in it belong to the help centre's own support case widget, not to the policy. So the most you can say about that page is the day you read it, which is why this page says that and nothing more.
Google Play Console Help, Functionality, Content, and User Experience, read 21 October 2026
What do you change before you resubmit?
Start by separating this from the rejections that have a file attached. An app icon alpha channel rejection is one asset and one export setting. A location permission always rejection is one string and one API call. Both have a right answer you can ship this afternoon. 4.2 does not. If you treat it as a configuration problem you will resubmit the same app with a new build number and get the same reply.
What moves a 4.2 is work the user can see. Something the app does that a browser tab cannot: data stored on the device and usable offline, a notification that arrives when something changes, the camera, the contact list, a widget, a share sheet. If your app is marketing material under 4.2.2, give it a job. A booking that completes in the app rather than a tap through to a web form. A saved order the person comes back to. On the Google Play side, if you were told the app is static without app-specific functionalities, that phrase is telling you the same thing in different words.
Then write the review notes. Apple expects a submission to be final and fully testable, with demo account details if there is a login, and it has a field for notes to App Review. A reviewer who cannot find the part of your app that answers 4.2 will decide it is not there. Say where it is, in two sentences, and say what the app does that a website could not. This costs nothing and it is the single cheapest change available to you.
If you think the call is wrong, the guidelines tell you to submit an appeal, and say it may help get your app on the store. Our appeal app store rejection walkthrough takes that route in order. There is also a lever most people miss for an app that is already published. Apple says bug fixes will not be delayed over guideline violations except for those related to legal or safety issues, and that you can use App Store Connect to tell App Review you would like to use that process and will address the issue in your next submission. A minimum functionality argument is neither legal nor safety, so a real bug fix for your existing users does not have to wait for it to end.
The same rejection, filed under two different rules
| The question | App Store | Google Play | Same on both |
|---|---|---|---|
| What the rule is called | 4.2 Minimum Functionality, inside section 4, Design | Functionality, Content, and User Experience | No |
| Where a crash is filed | 2.1(a) App Completeness, a separate rule | Broken Functionality, inside this same policy | No |
| A webview of someone else's site | 4.2, a repackaged website | The Spam policy, and it wants the owner's permission | No |
| Numbered subsections you can cite | 4.2.1 to 4.2.7, with 4.2.4 and 4.2.5 retired | Two, Limited Functionality and Content, and Broken Functionality | No |
| The policy page prints its own last updated date | Yes, 16 October 2026 | No | No |
| Fixing it needs a new build, not a changed form | Yes | Yes | Yes |
Where this lands if a builder generated your app
There is a subsection aimed squarely at this. Guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. The same subsection tells those services not to submit on behalf of their clients, and to offer tools that let clients create customized apps instead. It also offers template providers a second route: a single binary hosting all client content in an aggregated or picker model, and it gives two examples, a restaurant finder with a customized entry per client restaurant and an event app with an entry per client event.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, with two-way GitHub sync so the code is never trapped. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It is $25 a month and there is no free tier. It does not press submit on the App Store for you, and 4.2.6 is the reason: Apple wants the provider of the content to be the one submitting, and that is you.
That split works in your favour. Because the project is yours and the submission is yours, a 4.2 reply is a product note you can act on in code you can read. The honest limit is that no builder can decide for you whether your app clears the bar. Ask for the thing a browser tab cannot do, get it into the first submission, and keep the guideline numbers above open while you decide what the app is for.
Questions people ask about minimum functionality rejections
It is a rejection under App Store Review Guideline 4.2, titled Minimum Functionality. Apple asks whether your app includes features, content and UI that elevate it beyond a repackaged website, and says that an app which is not particularly useful, unique or app-like does not belong on the App Store. It also asks for lasting entertainment value or adequate utility. The rule sits in section 4 of the guidelines, Design, which Apple introduces as the minimum standards for approval. So it is a judgement about how much app there is, not a bug report.
Build the part a website cannot do, then submit
Write down the one thing your app does that a browser tab on the same phone could not. If that sentence is hard to write, 4.2 is going to be hard to pass, and the fix belongs in the build rather than in the appeal.
Start building