You upload the build on a Friday. On Monday there is a message in App Store Connect with a guideline number and a paragraph that seems to describe a different app. You fix what you think it means, resubmit, and wait another day.
Most apps built quickly with AI tools hit this wall for the same reason: the tool optimized for the demo. App Review does the opposite. A reviewer installs a release build on a device you didn't test, says no to every permission, looks for the button that deletes the account, and reads your screenshots against what the app actually does.
Here are the rejections that come up again and again in Flutter apps, and what fixes them.
Guideline 2.1: the reviewer couldn't use the app
This is the most common one, and it's rarely about a real crash on your phone.
- The reviewer couldn't log in. If anything sits behind a login, the App Review Information section needs a working demo account, and the backend behind it needs to be up when they test. An expired test user is a rejection.
- It was tested on an iPad. Flutter's iOS template targets iPhone and iPad by default. If you never opened the app on an iPad, the reviewer may be the first person to see the layout break. Either make it work, or remove iPad from the supported devices in Xcode on purpose.
- The release build behaves differently. Debug mode is forgiving: asserts run, code is compiled just in time, and some timing problems disappear. Run
flutter run --releaseon a physical device before every submission. A surprising number of "it works for me" crashes only exist in release. - Placeholder content. Lorem ipsum, a "coming soon" tab, a button that does nothing. Anything that looks unfinished reads as unfinished.
Guideline 5.1.1: privacy and permissions
AI tools add packages generously, and every package can bring a permission, a tracking SDK or a privacy obligation with it.
- Vague purpose strings.
NSCameraUsageDescriptionset to "This app needs the camera" gets rejected. Say what the camera is used for, in the user's terms: "Used to scan the QR code on your ticket." - Permissions you don't use. If
Info.plistasks for location because a dependency mentioned it, the reviewer will ask why. Remove what you don't need. - No way to delete the account. If users can create an account inside the app, they must be able to start deleting it inside the app too. Not by emailing support, not only on the website.
- Privacy manifests. Apple requires a privacy manifest for apps and for many third-party SDKs that use certain system APIs. Outdated plugin versions often don't ship one, and the upload is flagged before review even starts. Updating the plugin is usually the whole fix, which is a good reason not to let dependencies drift for a year.
Guideline 3.1.1: selling digital things without In-App Purchase
If the app unlocks digital content or features, Apple expects In-App Purchase. A Stripe checkout inside a WebView, or a button that sends the user to pay on your website, is a classic rejection.
The rules on external payment links have changed in some countries, including the US storefront in 2025, so check the current guideline for each country you sell in. What hasn't changed: if you use In-App Purchase, the app needs a visible way to restore purchases. AI-generated paywalls almost never include one.
Guideline 4.8: login with Google, but not with Apple
If the app offers sign-in through a third-party service like Google or Facebook, Apple expects an equivalent option that limits data collection and lets users keep their email private. Sign in with Apple meets that requirement. Adding Google login in an afternoon and forgetting this is one of the most predictable rejections there is.
Guideline 4.2: it's a website in a box
An app that wraps a website in a WebView, with nothing that uses the device, gets rejected for minimum functionality. This catches a lot of quick builds, because wrapping the existing web app is the fastest path to "we have an app". If the product is genuinely a website, a well-built mobile site may serve you better. If it needs to be an app, it needs to do something an app does: offline access, notifications, camera, something native.
Guideline 2.3: the screenshots promise something else
Screenshots made in a design tool before the app was finished, features listed in the description that were cut, the word "Android" anywhere in the metadata. Reviewers compare the listing with the app. Make the listing describe the build you're submitting, not the roadmap.
How to stop going back and forth
Before you submit, do what the reviewer will do:
- Install the release build on a physical iPhone and, if you support it, an iPad.
- Start from a fresh install and deny every permission. The app should still open and explain what it can't do.
- Create an account, then delete it from inside the app.
- If there's a paywall, find restore purchases without help.
- Put a working demo account and short instructions in the review notes, and keep that account alive.
- Read the screenshots and description against the build, line by line.
When a rejection does come, read the guideline number before the paragraph. The number tells you what category of problem it is; the paragraph is often a generic template. Reply in the Resolution Center if you think the reviewer misunderstood something. A clear, polite explanation fixes more rejections than people expect.
When it keeps coming back
If you're on the third rejection for the same guideline, the problem is usually structural: a dependency that can't be updated without breaking the build, a payment flow that has to be redone, a login system that doesn't fit the rules. That's the point where patching the paragraph Apple sent you stops working.
That's exactly what our app rescue is for: a fixed-price audit of the app, a written plan of what to change, and the fixes if you want us to do them.