d.
Blog

How I pass App Store review on the first try

I have a handful of apps on the App Store, and almost all of them cleared review on the first submission. The one that did not was my only AI chat app. That is not a coincidence, and it is the whole idea behind how I think about review now.

Apple's reviewer is not out to get you

Most rejections are self-inflicted. A screenshot that does not match the app. A privacy policy that claims something the app does not do. A feature the reviewer could not find, so they marked it broken. Every one of those is a reason you handed them. So the goal is not to learn secret rules. It is to hand them fewer reasons.

The lens that changed things for me: every feature you ship is also a liability at review. Add an account and you also add Sign in with Apple, account deletion, and "we could not reach your server during review." Add ads and you add the ATT prompt and a privacy label you have to get exactly right. Add an AI that generates content and you add content moderation. None of these are reasons not to build the feature. They are costs to put on the scale when you decide what goes in version one.

When you have the choice, lean simple for v1

I cannot tell you to build offline with no account. Plenty of apps genuinely need a server and a login, and that is fine. But if you do have the choice, or you are just trying to get a first version out the door, the simpler version sails through. My games have no account and run fully offline, so an entire category of rejections simply never applies to them. The one app that needed an account, a server, and a generative model is exactly the one that got bounced. It was not a worse app. It was a more expensive one to get through review, and I should have planned for that.

Screenshots do not have to be screenshots

You do not have to upload raw in-app captures. Marketing-style images with a phone frame and a headline are fine, as long as the app's real UI is visible inside them. Pure marketing art with no app in it gets flagged for not reflecting the app in use. So: styled, but show the actual thing.

Two boring details that save a resubmission. Get the sizes Apple asks for, and if your app supports iPad, prepare the iPad set too, or you cannot even submit. And build the whole thing as code, not by hand, so when you need the same images at a new size for iPad or Android later, it is one command, not an afternoon in a design tool.

Write the review notes like the reviewer has never seen your app

Because they have not. I put a short note that says what the app is, the main features, and how to reach each one. Then I attach a screen recording of one full user flow in the review attachment field. That one clip kills the most annoying rejection there is: "we were unable to locate" or "could not reproduce." If something is hidden behind a trigger, or it is a purchase flow, show it on video and they never have to go hunting.

Make the metadata true, especially the money parts

The privacy policy has to match what the app actually does. I generate mine from a template, and the one time it nearly bit me was reusing a policy across two games where only one had a subscription. The text claimed an auto-renewing subscription the second game did not have. A policy that does not match the app is a rejection, so I had to catch it. If your app has a subscription, the App Store description itself needs working links to your Terms and your Privacy Policy, and the paywall needs to show the price, the length, and that it renews. Non-consumable purchases need a Restore Purchases button, or you will hear about it.

AI does almost all of this. I just fill in the store

I do about ninety-nine percent of the above with Claude Code and then type things into App Store Connect myself. A few things that make that actually work:

  • Make the asset and metadata generation a pipeline, not a one-off. Re-rendering screenshots for iPad or Android should be re-running a script, not starting over.
  • Use the same identifiers across both platforms. Bundle id and package name the same, and the in-app purchase product ids identical on both stores. One config, far less to port and far less to get wrong.
  • When you ask it to write ASO, feed it two or three real competitors. Otherwise you get generic copy. Give it the market and it grounds the keywords in words people actually search.
  • Let it produce the visuals. It can drive a headless browser to record the real build, or rebuild the screen in HTML and render clean clips and images from that, no device needed.

The one part you cannot hand off is accuracy. AI will happily copy the wrong privacy template or oversell the app in the description, and a metadata mismatch is a rejection just the same as a broken build. The machine does the work. You are the check that what it wrote is true about the actual app.

The whole trick

There is no secret. Review goes smoothly when there is nothing to catch: the screenshots are the app, the policy is the truth, the purchases follow the rules, and the reviewer can see every feature without guessing. Every bit of complexity you add is worth it or it is not, but always remember it is also one more thing that can send you back. For a first version, when you can, give them less.