Review notes, demo videos, calls with Apple, expedited reviews, scope creep, the flood of AI-built apps: what actually helps you get through App Review, what's folklore, and what can cost you far more than a rejection.
Tempers are rising among iOS developers right now, on X and in WhatsApp communities, including one I run. People talk about reviews that drag on, terminated accounts, and swap recipes for getting "approved in under 48 hours": detailed review notes, a demo video, a call with Apple to get into a separate queue, a stripped-down MVP to avoid "the 14-day pile"…
There are some very good instincts in that advice. There are also claims nobody can verify, and one or two ideas that, applied the wrong way, can cost you much more than a rejection.
Review times and terminations each deserve their own chapter, because they shed light on everything else.
For context (though if you've landed on my site, you probably "know" who I am): I've been shipping on the App Store since 2008, for my own apps and for clients. I took each piece of advice and checked it against what Apple writes in black and white on its App Review page, in the App Review Guidelines and in App Review Help. Here's what holds up, and what doesn't.
First, put the 48 hours in context
The recipes going around imply that 48 hours is an achievement. On paper, it's the norm Apple publishes: App Review works around the clock, all around the globe (Cupertino, Cork and elsewhere), with the goal of reviewing at least 50% of submissions in under 24 hours and 90% in under 48 hours.
In practice, it's more nuanced. Those figures are averages across all submissions, and a large share of them are updates to apps already on the store, which often go through in a few hours. In recent weeks, I've had updates approved in 7 hours, others in 12. A new app, on the other hand, can wait much longer: as I write this, some of my new apps have been in review for more than ten days. It's long, but that's the game.
Apple has shared recent figures. Asked by MobileGamer.biz on October 20, the company said it had processed an average of 378,000 submissions per week over the previous twelve weeks, with an average review time of 1.5 days across all apps and 14 hours for minor updates. It also noted that some new apps take longer when they need additional scrutiny. For that volume, the average is remarkable; the outliers are concentrated in first submissions.
The community used to have its own tool for tracking this. Old-timers will remember appreviewtimes.com, launched in the early 2010s by my friend Dave Verwer, of iOS Dev Weekly fame. The idea was simple: developers tweeted how long their reviews took with the #iosreviewtime hashtag (yes, it was still Twitter back then), and the site computed an average. Back when you counted in weeks, it was an essential tool for managing client expectations.
In 2019, Dave shut the site down for the best possible reason: reviews had become so fast, around a day, that measuring them no longer made much sense. It never came back. Dave has since joined Apple this summer along with the Swift Package Index, and iOS Dev Weekly is now run by Alex Ozun.
The upshot: in 2026, there's no longer a go-to community barometer, just scattered reports on forums and social media. A sign of the times: the tool that shut down because review had become fast would find its place again today.
A brief history of time
This isn't the first time review times have moved. In the early App Store days, a review could take several weeks. My very first app waited 26 days to be approved, for a release on July 14, 2008, four days after the App Store opened. It then came down to a week, which was the norm for a long time. Then Apple sped things up dramatically, until one to three days became the expectation. Since early 2026, times have been climbing again for new apps, and the reason deserves its own chapter (right below).
So aiming for 48 hours isn't about finding a shortcut: it's about not falling out of the normal flow, knowing that for a launch, the normal flow is now measured in days. Plan accordingly.
The real question is: what makes a submission fall out of that flow? Apple gives a valuable hint on its App Review page: over 40% of unresolved issues fall under guideline 2.1, App Completeness — crashes, placeholder content, missing information. Reviewer subjectivity isn't what slows most apps down. Incomplete submissions are.
Coding agents: more apps, longer waits
Why are review times climbing? The most likely explanation fits in one word: agents.
Claude Code, Codex, Cursor, the agents now built into Xcode: building an iOS app has never been more accessible. According to Sensor Tower, as reported by The Information, the App Store received 235,800 new apps in Q1 2026, up 84% year over year — the fastest growth it had recorded in four years. Across the first half, Sensor Tower estimates about 560,000 new apps, double the year before, while downloads grew just 2%. Apple itself wrote in its May fraud-prevention report that AI development tools are driving a surge in submissions.
Apple maintains its 90%-in-48-hours goal and has adapted how it works: more automation, and priority given to updates. Developer reports are consistent with that choice: updates to established apps still go through quickly, new apps wait longer.
The good side: what a great time to be a developer
First, this is great news, on many levels. The coding barrier has never been lower. Designers, domain experts and indies who would never have learned Swift can now ship a useful app. Experienced developers deliver in a week what used to take a quarter. I work with agents every day myself: they write SwiftUI, tests, and even a first draft of review notes.
A word of caution, though: saying the barrier is gone would be a lie. An agent writes code; it doesn't know for you which framework to pick, which pattern will hold up as the app grows, how Swift concurrency, StoreKit or permissions behave, or why a review is stuck. Agents amplify what you already know. The better you know the platform, the faster they make you; the less you know it, the faster you pile up problems you can't read.
The ingredients are the same for everyone: Swift, SwiftUI, Xcode, the Human Interface Guidelines, and now an agent. What makes a great app is how you put them together, with intent and care: a reason to exist you can state in one sentence, a single source of truth for your data, an honestly audited accessibility pass, testing on real devices. An agent can write the screen; it won't tell you whether the app deserves to exist. Or worse, it’ll go full proud mum: “That’s a fantastic idea, darling!” — then help you burn a billion tokens building an app whose entire target audience is you, your mum, your cat, your canary and maybe — just maybe — your partner. I walked through that whole approach, from Apple's eight design principles all the way to release, in The recipe for a great iOS app (in French).
Used well, they also help with compliance. An agent can review your purpose strings, check that account deletion exists, compare your flows against the guidelines, and list the non-obvious features you need to document. Everything in this article, an agent can check before you do.
To make that easier, I'm giving you a skill that helps flush out mistakes before you submit: app-review-skill. It's not a guarantee of approval, but at least it's a safeguard. 😉
In short: what a great time to be a developer.
The millionaire-in-three-prompts mirage
The flip side is the story that comes with this wave. The same promise is everywhere: three prompts, a subscription (or ads everywhere), and you're a millionaire in three days.
Spoiler: it's false. And the numbers leave no room for doubt. RevenueCat's State of Subscription Apps 2026 report, covering more than 115,000 apps and $16 billion in revenue, shows that:
- one year after launch, the median app makes about $72 a month;
- only 17.3% of apps reach $1,000 in monthly revenue within their first two years, and 4.6% pass $10,000;
- even the top 10% barely clear $2,574 a month after a year: a long, long way from a million;
- apps launched in 2025 or later account for just 3% of subscription revenue, while apps launched before 2020 capture 69%.
And these are apps serious enough to have set up a subscription in the first place.
Everyone thinks they have the next big idea. Sorry to bring you back down to earth. If your idea doesn't exist on the App Store yet, there are only two possibilities: either it's been tried and it didn't work, or a hundred other people are building it right now. And with agents, that hundred quickly becomes a thousand.
That's not pessimism; it's a well-documented phenomenon called multiple discovery. Alexander Graham Bell and Elisha Gray filed their telephone patent applications on the same day in 1876. Darwin and Wallace each arrived at natural selection independently, to the point of presenting their work together in 1858. Newton and Leibniz invented calculus in parallel. There's nothing magical about it: at any given time, everyone shares the same tools, the same problems and the same access to information. Two minds facing the same problem with the same tools naturally reach the same solution. As the line often attributed to Victor Hugo puts it, nothing is more powerful than an idea whose time has come.
The takeaway: don't keep your idea secret for fear of someone stealing it. Others are already working on it. The people you talk to may even point you to competing apps that have flown under your radar. The difference won't come from the idea, but from execution, distribution, time, and your personal touch.
I know developers whose apps make anywhere from $80,000 to more than $1 million a month. They exist, they're brilliant, and they usually have years of iteration behind them. They're clearly not the majority.
That's no reason not to start. It's a reason to start for the right reasons: solving a real problem, learning, building something that lasts. And to take care of the one thing that can't be automated: quality.
The not-so-good side
Sloppy apps land in review, and the queue is shared. Generating an app over a weekend doesn't mean it's ready: plenty of submissions arrive untested on a device, with placeholder content, no privacy policy and no review notes. Others are of no interest to anyone but their own developer. Yet Apple says so in the very introduction to its guidelines: an app you just want to show family and friends doesn't belong on the App Store; that's what Xcode and Ad Hoc distribution are for. Each of these submissions ties up a reviewer who isn't looking at yours. By prioritizing updates to existing apps, Apple protects current users and established developers; the trade-off is a longer wait for new apps.
Spam is the first target. Guideline 4.3 prohibits submitting multiple variants of the same app, and saturated categories without a meaningful difference. With an agent, producing five clones takes an afternoon; that's exactly what Apple filters out. Apple says it has expanded automation and abuse detection, and added safeguards against repeated submissions with the same unresolved issues. Its guidelines already said so: repeated rejections for the same reason make review take longer.
Apps that generate code are in the crosshairs. Apple blocked updates to or removed several vibe coding apps this year, including Replit, Vibecode and Anything. The issue isn't vibe coding itself but guideline 2.5.2: an app can't download or execute code that changes its features after review.
More apps doesn't mean more users. With downloads nearly flat, every new app competes for the same attention. The technical barrier has dropped; the quality bar has gone up.
What it means for you
- You're still accountable. The guidelines say it plainly: everything in your app, third-party SDKs included, is your responsibility. "The agent wrote it" isn't an argument.
- Submission quality becomes an edge. In a clogged queue, a complete app with clear notes stands out even more than before.
- One app, not five variants. Use in-app purchases or settings for variations instead of multiplying bundle IDs.
- Never resubmit without fixing. A pointless round trip costs you days, and can put you among the behaviors Apple watches for.
- Build in margin. For a new app, plan on a week, plus a possible round trip. If it clears in 48 hours, great.
The advice that holds up
Quality matters, and it's written into the rules
"A polished app gets treated better" is true, but not because of a reviewer's mood. Section 4 of the guidelines says it plainly: Apple expects interfaces that are simple, refined and easy to use. Guideline 4.2 (Minimum Functionality) rejects apps that are just a repackaged website, a collection of links, or content without lasting value.
"Build native with SwiftUI": good advice, not a rule
I'm a native iOS developer: I build with it, advocate for it, promote it and teach it. To me, native development is the standard for building an app that respects the platform's conventions and makes full use of what iPhone and iPad can do. With SwiftUI, you get Dynamic Type, safe areas, sheets, system navigation and iPhone/iPad adaptation, with direct access to widgets, Live Activities, App Intents and many other capabilities across Apple's frameworks. That integration makes a real difference in everyday use and naturally reduces the small flaws a reviewer notices.
But no guideline requires SwiftUI. A well-built Expo, Flutter or UIKit app passes just fine. What gets penalized is the outcome: a disguised web view, a UI that breaks on iPad (guideline 2.4.1 encourages iPad support whenever possible), a keyboard covering a text field. Native raises your ceiling; it doesn't guarantee anything.
P.S. Martin, don't hit me, don't hit me, don't hiiii... slap
Privacy policy, support and permissions
Here the advice usually undersells it. These aren't best practices, they're requirements:
- A privacy policy linked in App Store Connect and inside the app (5.1.1(i)). It must describe what data you collect and how you use it, commit third parties to equivalent protection, and explain retention, deletion and how to withdraw consent.
- A support link with up-to-date contact information, and every link working (2.1 and 5.1).
- Clear purpose strings for every sensitive permission, ideally with a concrete example of use.
- Data minimization (5.1.1(iii)): prefer system pickers, like the photo picker, over full photo library access.
- In-app account deletion as soon as users can create an account (5.1.1(v)).
The "static HTML" format often recommended isn't required. What matters is that the page is reachable, current and consistent with what the app does.
Social apps: four specific requirements
Reporting, blocking, contact, moderation: that's exactly guideline 1.2 (User-Generated Content), which requires:
- a way to filter objectionable material before it's posted;
- a reporting mechanism with timely responses;
- the ability to block abusive users;
- published contact information.
Since the October 16, 2026 update, the guideline explicitly names AI content creation apps, and Apple states that nonconsensual intimate imagery, including AI-generated imagery, must be proactively prevented and removed. Developers who don't put safeguards in place, or don't remedy violations after notice, may be considered in breach of the Developer Code of Conduct.
OpenAI's free moderation API comes up a lot in these discussions. Technically that's a valid option, with one important caveat: guideline 5.1.2(i) requires you to clearly disclose when personal data is shared with third parties, including third-party AI, and to get explicit permission. Sending your users' photos to an external model without telling them just swaps one rejection for another.
In-app purchases have to work
Obvious, yet often missed: guideline 2.1(b) requires in-app purchases that are complete, visible and functional for the reviewer. If a configured product can't be reached in the submitted build, explain why in the notes. And include a "Restore Purchases" button.
Review notes: the most underrated lever
This is the most useful advice of all, and Apple goes even further.
What Apple asks for in its "Before You Submit" checklist:
- full access to the app: an active demo account or a fully featured demo mode, plus any hardware or resources needed (credentials, a sample QR code…);
- back-end services live for the whole review;
- a detailed explanation of non-obvious features and in-app purchases in the notes, with supporting documentation where appropriate.
Yes, there's some automation involved, and that's normal at this volume. But Apple says it in black and white in the introduction to its guidelines: every app is reviewed by experts. Nine times out of ten, if not more, a human is at the controls, pressing the little green (or red) button.
So your notes are addressed to a person who's discovering your app in a few minutes. Write them for that person.
And guideline 2.3.1(a) leaves no room for doubt: every new feature must be described with specificity in the review notes, and generic descriptions are rejected.
One detail to watch: a demo mode instead of a demo account is only accepted with Apple's prior approval, and only if legal or security obligations prevent you from providing an account.
A structure that works
No need to copy someone else's essay. Here's the skeleton I use:
Hello,
[App name] is [one sentence: what the app does, for whom, and the problem it solves].
Business model: [free / subscription / one-time purchase], via In-App Purchase.
Access:
- Demo account: [username] / [password]
(or: no account required)
Main flow:
1. …
2. …
3. …
In-app purchases:
- Where the paywall appears, how to test in sandbox.
- "Restore Purchases": [location].
Non-obvious features:
- [Feature]: how to reach it, what it does.
Data and permissions:
- Which permissions, when they're requested, and why.
- Data shared with third parties (including AI) and how consent is collected.
External services:
- [Service]: what it's used for (data, authentication, payments, AI, ads…).
Regional differences:
- [None / which ones].
Regulation and third-party content:
- [Not applicable / documents attached].
Account and safety:
- Account deletion: [path].
- Report / block: [path] (if user-generated content).On style, the golden rule: short sentences, readable by someone who's never seen the app. I'd only push back on the "don't use AI" you sometimes hear: having an agent that knows your code draft a first version is a real time-saver. What matters is that you reread and simplify before submitting.
A real example: disclosing what's remotely controlled
Here's a note I left on one of my apps (anonymized). It's a classic case: the ad SDK is integrated, but ads can't be switched on before release, because AdMob requires an app published on a store to complete its app readiness review. So ads are turned off by a feature flag at review time.
ADVERTISING DISCLOSURE - INITIAL 1.0 RELEASE
This app includes the Google Mobile Ads (AdMob) SDK and Google UMP consent integration. Production advertising is currently disabled through a remote feature flag. This is the general launch configuration, not a condition targeting App Review. We are disclosing the advertising integration explicitly; it is not disabled to hide it from reviewers.
The reason is that this initial release is not yet publicly available on the App Store. AdMob requires a published, downloadable app linked to a supported store for its app readiness review, and approval before full ad serving. We therefore cannot complete that activation process before publication. After release, we plan to link the App Store listing, complete AdMob's readiness process and enable production advertising through the feature flag.
The absence of ads during review should not be interpreted as an ad-free product. Ad presentation will remain subject to the applicable consent and tracking permissions.
Google's explanation: https://support.google.com/admob/answer/10564477?hl=enWhy this note works:
- It names what's in the binary: the AdMob SDK and the UMP consent module.
- It discloses the feature flag and states that it doesn't target the review. That's the exact opposite of a dormant feature under guideline 2.5.19.
- It explains why, with a verifiable external source.
- It announces what will change after release, so turning ads on comes as no surprise.
- It mentions consent: personalized ads will remain subject to tracking permissions.
Nothing hidden, nothing to interpret: the reviewer knows exactly what they're approving.
The demo video: not mandatory, but increasingly requested
You sometimes read that first submissions without notes and a video get auto-rejected. Nothing in Apple's documentation says so. What Apple does say is that you should be prepared to provide a demo video or the hardware when features depend on an environment that's hard to replicate or on specific hardware.
In practice, a short annotated screen recording attached in App Review Information helps a lot as soon as the app is out of the ordinary: a connected device, location-based features, a social feature that needs several accounts. For a note-taking app with no account, it's overkill.
The goal is still the right one: make the review obvious. A reviewer who understands your app in three minutes has no reason to ask you anything.
When Apple asks for "additional information"
For new apps, one message is showing up more and more often: a standardized information request, tied to guideline 2.1. Here's the one I recently received for one of my apps:
We need additional information to better understand the app and complete the review.
Reply in App Store Connect with all of the following information and also add this
information to the Notes field of the App Review Information section in App Store
Connect, for reference on future submissions:
1. A screen recording captured on a physical device, running the latest operating
system, demonstrating the app's functionality. The recording must begin with
launching the app and show the typical user flow. If the app has any of the
following, include them in the recording:
- Account registration, login, and account deletion flows.
- Any user-generated content, including the required content reporting and
blocking mechanisms.
- Accessing paid content or features within the app.
2. A description of the app's purpose and target audience, including the problem
it solves and the value it provides
3. Instructions for setting up and accessing the app's main features, including
any required login credentials or sample files
4. A list of the external services, tools, or platforms the app uses to deliver
its core functionality (for example, data providers, authentication services,
payment processors, or AI services)
5. Describe any regional differences in the app's features or content, or confirm
that the app functions consistently across all regions
6. If the app operates in a highly regulated industry or includes protected
third-party material, provide any relevant documentation or credentials to
demonstrate you are authorized to provide these services or protected materialThe message also lists the classic pitfalls: bugs on physical devices, demo accounts, screenshots that show the app in use, in-app purchases configured alongside the app, and business-only distribution.
And here's my reply, anonymized:
1. [Screen recording attached, captured on a physical device.]
2. [App] is a [category] app that [what the app does]. It's inspired by
[well-known reference], but adds [its own distinctive features]. It's designed
for [target audience], and [the problem it solves / the value it provides].
3. There's no account to create and no login required. Users can simply open the
app and start using it. The main flow consists of [main interaction]. Users
can also [secondary features] directly from the app. The app includes optional
rewarded ads to unlock [optional extra].
4. The app runs primarily on the device. [Core processing] is handled locally,
so there's no external API involved in the core functionality. Google's AdMob
is used to display advertisements, including optional rewarded ads.
5. The app works the same way in every region where it's available. The main
difference is the language: the app has a localized name and content adapted
to each language. Features and core mechanics remain consistent across all
supported regions.
6. Not applicable. [App] is an original app and doesn't operate in a regulated
industry.Three takeaways:
- The video isn't required by default, but it's explicitly requested here: recorded on a physical device, on the latest iOS, starting from app launch. You might as well prepare it before your first submission.
- Apple asks you to add these answers to the Notes field for future submissions. In other words: had they been there from the start, the round trip could probably have been avoided.
- The six questions make an excellent checklist. Purpose, audience, access, external services, regional differences, regulation: I've added them to the notes template above.
What not to do (and why it can be worse than a rejection)
"Coming soon" screens
Placeholder content, dead buttons, empty links: that's the heart of guideline 2.1, and the top source of issues according to Apple. Remove the feature from the build rather than shipping half of it.
Changing your paywall after review
"Making a remote paywall non-compliant after review" sometimes gets filed as just another dark pattern. It's far more serious than that.
Guideline 2.5.19, added on October 16, 2026 to target bait-and-switch by name, prohibits hidden, dormant or undocumented features, and provides for removal of the app and termination of the developer account. The guidelines' introduction is even more direct: trying to trick the review process gets your apps removed and you expelled from the Apple Developer Program. That's not a bet on a lenient reviewer; it's a risk to your entire business.
Configuring your paywall remotely isn't forbidden. Switching it to something the reviewer never saw is.
Rating prompts
Guideline 5.6.1 requires Apple's provided API to ask for ratings and disallows custom review prompts. Guideline 3.2.2(x) prohibits forcing users to rate the app in order to access functionality.
Asking for a rating during onboarding isn't explicitly banned, but it makes no sense: the user hasn't seen anything yet, and the system limits how often the prompt is shown anyway. Wait for a genuine moment of satisfaction.
Fake social proof and unverifiable claims
Made-up "1 million users", fake reviews, "fixes 100% of your problems": guideline 5.6.3 prohibits manipulating reviews, charts or search, and 2.3.7 prohibits unverifiable claims in metadata. For health apps, 1.4.1 requires you to disclose the methodology behind any accuracy claim.
Copying an app
Obvious, and Apple goes further. Guideline 4.1 rejects copycats, and impersonating another app is a Developer Code of Conduct violation. Guideline 4.3 closes the door on saturated categories (flashlights, wallpapers, dating apps, simple timers…) unless the experience is meaningfully different. There are already a million fart boxes, flashlights and dating apps: Apple even names fart and burp apps among those that add no value to the App Store.
Retention offers: use the official tools
There's a lot of talk about "transaction abandon" and "exit offers" (offering a deal to someone who hesitates or wants to cancel). These aren't forbidden in themselves, and StoreKit provides official mechanisms for them: promotional offers, win-back offers, the system subscription management sheet.
Saving them for a later update is sensible: less surface, fewer questions. But the real rule lies elsewhere. Guideline 3.1.2(c) requires you to clearly describe what users get for the price, and 5.6 prohibits tricking people into unwanted purchases. A clear offer, described in the notes, has nothing to fear. An offer that muddies the price does.
Account terminations: understand them so they don't happen to you
A rejection costs you a few days. A termination costs you every app you have. The topic has been all over social media these past weeks, and it deserves a calm look.
Why Apple is tightening things up
On October 16, 2026, Apple strengthened its guidelines on two fronts: nonconsensual intimate imagery, including AI-generated imagery, which apps must prevent and remove (1.2), and bait-and-switch, apps that look harmless during review and switch on harmful features after approval (2.5.19). In the same announcement, Apple said it stopped more than 150,000 apps with safety issues from reaching users last year, and terminated more than 193,000 developer accounts for fraud and abuse.
Those numbers say it all: fraud on the App Store is massive and organized. "Nudification" apps have multiplied, authorities such as the city of San Francisco have demanded their removal, and the flood of AI-generated submissions adds even more pressure. That users still trust the App Store is largely thanks to this work.
At that scale, good-faith developers can also get caught in the net. That's exactly what the appeal to the App Review Board is for.
What developers describe
The notices being shared invoke Section 3.2(f) of the Developer Program License Agreement and cite a "pattern of manipulative or misleading behavior", followed by a list of possible behaviors: inaccurate metadata, misleading content, inauthentic reviews, misleading responses to support or in App Store Connect, bait-and-switch purchasing schemes…
Phillip Shoemaker, who used to run App Review, published his analysis at the end of October. He believes rejection history now weighs heavily: number of submissions, name changes, repeated objectionable-content rejections, especially for generative photo apps. He also acknowledges the difficulty on Apple's side: generative apps are very hard to review, a server-side fix can be reversed at any time, and Apple links accounts together, which gives it a view the developer doesn't always have. His proposals are constructive: more specific rejections about what needs to change, and concrete details in notices so that appeals are useful.
Too clever by half
No need to name names: the stories going around all look alike. Read them closely and the same habits keep coming up. They rarely start from bad intent, but seen from Cupertino, they look an awful lot like what Apple is trying to catch:
- Resubmitting in a loop, changing one detail each time "to see if it gets through".
- Renaming the app, or switching concept or category along the way, sometimes more than once.
- Cosmetic fixes: removing an option from a menu while the feature stays reachable another way.
- Keeping a server-side switch the reviewer never saw.
- Stuffing keywords, or borrowing a little too much from a competitor's name.
- Juggling accounts, or lending yours, to get around a rejection.
- Bending the truth in replies to App Review.
On its own, each of these can seem harmless. Put end to end, they form a pattern. And at the scale of hundreds of thousands of submissions a week, that pattern is what Apple reads, not your intentions.
The moral is simple: trying to outsmart App Review is betting against the house. And the house has your full history.
The App Review Board is still there to fix mistakes, and good-faith developers do win appeals. But the best appeal is the one you never need to file.
What it means for you
I'm not going to play lawyer: for a termination, the only route is an appeal to the App Review Board, and in the cases reported the notice gives you 30 days to file it. If it happens to you, get help. That said, a few habits significantly reduce the risk:
- Your rejection history counts. Every submission leaves a trace. Never resubmit "just to see": ask a precise question in App Store Connect before you fix anything.
- Don't change the app's identity along the way. Name, concept, category: repeated changes look like exactly what Apple is trying to catch. If App Review is the one asking, get it confirmed in writing in App Store Connect, including after a call, and summarize in writing what was said on the phone.
- When a rejection goes in circles, stop resubmitting. Ask in writing for the complete list of blocking issues, then go to the App Review Board rather than piling up attempts.
- Document everything that can be configured remotely. Feature flags, paywall, AI models: say so in the notes, and show what can change.
- For a generative app, fix it at the source. Removing an option from a menu isn't enough if the model still produces the content from a simple prompt. Filtering has to be real, on the model side and on the output side.
- Answer accurately in App Store Connect. "Misleading responses" are explicitly on the list of grounds.
- Keep an archive of every submission. Build, notes, screenshots, conversations with App Review: that's your only file if you need to appeal.
- Watch who you associate with. Shared accounts, lent certificates, partners with shady practices: Apple links accounts together.
That's also why I don't buy the idea, sometimes floated, that "Apple wants us to find the line". In 2026, every submission counts in your history. Aim for clarity, not the line.
Speeding up a review: what actually exists
This is where the most myths circulate.
Expedited review
It exists, for extenuating circumstances: a critical bug or a release tied to an event you're directly associated with. A few details that often get left out:
- only a submission that has already been sent to review can be expedited;
- for a critical bug, include steps to reproduce it on the current version in the notes;
- for an event, include the event, its date and how the app relates to it;
- Apple handles requests as availability and demand allow, with no guarantee;
- and above all, if you abuse it, Apple may reject your future requests.
"You don't need to give a reason" is therefore misleading: the form is simple, but the justification belongs in the notes. As for a "viral moment" or "marketing", they're not in the criteria. I wouldn't burn that card on them.
A call with Apple: not a fast lane
The call is often presented as an overlooked trick that puts you in a separate queue. That's not what Apple describes.
You can request a call with an Apple representative from the Reply to App Review window, after App Review has replied to you, specifying your time zone and preferred language. These calls are typically completed within three to five business days. It's an excellent tool for clearing up a misunderstanding about a rejection. It's in no way a shortcut to 48 hours. Keep in mind that the next review may be handled by someone else: always get the conclusions confirmed in writing in App Store Connect.
App Review appointments: the real secret
What rarely gets mentioned, and what I recommend to every client before a tricky first submission: App Review appointments through Meet with Apple. Thirty minutes on video with an App Review expert, on Tuesdays and Thursdays subject to availability, to ask precise questions about how a guideline applies to your app.
Two limits to know: the appointment is informational — it doesn't replace, expedite or guarantee the review — and Apple won't pre-approve any feature. But walking into your submission already knowing how Apple reads your case is the best investment you can make.
Breaking out of the rejection loop
The nightmare is well known: a rejection, a fix, then another rejection for a different reason. Getting out of it means using the right channels:
- Reply in App Store Connect with a precise question: the feature, guideline or step you need clarified. A specialist familiar with your app will answer. Asking "are there any other blocking issues?" is fair, even if nobody can promise you a complete list.
- Bug Fix Submissions: for an app already on the store, a bug fix update isn't held up by other guideline issues unless they're legal or safety-related. You fix the rest in your next submission.
- Appeal to the App Review Board if you believe the app was misunderstood: once per rejected submission, with specific arguments.
And on tone, guideline 5.6 reminds you to treat everyone with respect, including when communicating with Apple. Complaining gets you nowhere; arguing from the guidelines does.
Scope creep: the best advice, with one caveat
"Ship an MVP" is excellent advice, and Apple confirms it in its own way: an app that's complex or raises new issues may need greater scrutiny, and repeated rejections for the same guideline make review take longer.
However, the description of "two piles", with escalation to a senior specialist and a 14-day wait, isn't documented anywhere. What Apple does document are regulated areas that require more paperwork and time:
- banking, finance, healthcare, gambling, crypto or air travel apps must be submitted by the legal entity providing the service (5.1.1(ix));
- gambling apps should expect extra review time (5.3);
- medical apps or apps using licensed content must provide the matching authorizations.
One last caveat: an MVP isn't a thin app. The 4.2 bar applies from version one. Cut the number of features, not their finish.
Summary: true, overstated, wrong
| What you hear | Verdict | What Apple says |
|---|---|---|
| You can get approved in 48 hours | Overstated | Official goal, met for most updates; a new app can wait more than a week |
| Detailed review notes help | True | Required for non-obvious features (2.3.1(a)) |
| You need a demo account | True | Mandatory if the app has a login (2.1(a)) |
| Social apps must moderate | True | Filter, report, block, published contact (1.2) |
| You should build in SwiftUI | Overstated | Not required; only the outcome counts (4.2) |
| A demo video is all but mandatory | Overstated | No documented auto-rejection, but increasingly requested for new apps |
| Save aggressive offers for later | Overstated | Wise, but the real rule is clarity (3.1.2, 5.6) |
| An MVP gets through faster | Overstated | Yes, as long as it clears the 4.2 bar |
| No need to justify an expedite | Wrong | Justification goes in the notes; abuse is penalized |
| A call puts you in a separate queue | Wrong | After App Review replies, within 3–5 business days |
| No notes or video means auto-rejection | Undocumented | No official source |
| Two piles, one with a 14-day wait | Undocumented | Apple only mentions greater scrutiny |
| Apple wants us to find the line | Wrong | Tricking the review gets you expelled |
My pre-submission checklist
Completeness (2.1)
Review information
Metadata (2.3)
Strategy
The real secret: be boring and honest
You sometimes hear that Apple wants us to find the line. I disagree. The guidelines are a living document, and Apple openly owns a degree of judgment. But the introduction is clear: the guiding principle is a safe experience for users, and any attempt to trick the review comes at a very high price.
For the rest, one rule has everyone's agreement: be clear, be honest, explain what you're doing and show it. A complete, readable, surprise-free submission goes through in the normal timeframe. For an update, that's often under 48 hours. For a new app in 2026, plan on a week and let yourself be pleasantly surprised.
Now that agents let anyone submit an app over a weekend, App Review is back to what it was at the start: a filter. And that's a good thing. That filter is what lets a user install an unknown app without a second thought, and that trust is what makes the App Store valuable for us developers. App Review teams handle hundreds of thousands of submissions a week; making their job easier makes ours easier too.
Better to be on the right side of the filter.
I've been building and shipping apps since the App Store was born, for myself, for startups, and for brands with flagship stores on Fifth Avenue, Bond Street or Rodeo Drive. If you're preparing a tricky first submission, a social app, a subscription model or an app in a regulated field, that's the kind of work I do with BNC Consulting. Drop me a line.
And if you'd rather talk it through with other developers, join the ⌘+F community: we share rejection stories at meetups too, over coffee or dinner.
And finally, a big hug to Raph’, Anders, Erica, Ewelina and all my other friends on the App Review team, who do a particularly tough job. Another one to Martin, Mac, SiQing and the WWDR teams, who often act as the buffer — and to everyone else around the world I know but can’t name here.
Thank you for being there to protect users. That’s the good side of the App Store, too.
— Clément
Official sources (checked November 1, 2026)
- App Review — Apple Developer
- App Review Guidelines (updated October 16, 2026)
- Request an expedited review
- Contact App Review and request a call
- Request an App Review appointment
Data and press
- MobileGamer.biz — review times and the flood of AI-made apps (October 20, 2026, with Apple's figures)
- 9to5Mac — 84% surge in new apps
- TweakTown — 560,000 new apps in H1 2026
- RevenueCat — State of Subscription Apps 2026
- iPhoneSoft — AppReviewTimes shuts down (March 2019, in French)
- Apple — Strengthening App Review Guidelines against nonconsensual intimate imagery and bait-and-switch apps (October 16, 2026)
- Phillip Shoemaker — Apple approved the fix. Then it called the developer a liar. (October 30, 2026)
- 9to5Mac — new rules against nudification and bait-and-switch apps
As usual, this article was written by hand in French. The English translation and illustrations were created with OpenAI's tools.