If you are submitting your first or second app from a new developer account, there is a rejection waiting for you that has nothing to do with your code. It arrives as Guideline 2.1 - Information Needed, and it opens with a sentence that confuses everyone who gets it:
“This app has been submitted by a developer account that has a limited App Review history. We need additional information to better understand the app and complete the review.”
Nothing is broken. Apple has not found a bug. You have been handed a questionnaire because they do not know you yet, and the review will not move until you answer it. We got this one last night on a music game, and the useful part was not the questionnaire; it was what we found underneath it while writing the reply.
What the six items are actually asking
Apple lists six things. They read as bureaucracy; they are not. Each one maps to a specific way apps get pulled from the store later, and answering them in that spirit is much faster than answering them literally.
1. A screen recording on a physical device
This is the item people get stuck on, and the requirements are stricter than they look. It must start at launch, show the typical user flow, and include account registration, login and deletion, any user-generated content with its reporting and blocking controls, and accessing paid content or features. A simulator capture will be rejected.
The point is not the video. The point is that Apple wants evidence the app runs on real hardware, because the most common failure from a new account is an app that only ever ran in a simulator. If a section does not apply (no accounts, no user content), say so explicitly in the reply. An unanswered item reads as an evasion.
2. Purpose and target audience
Two sentences on what problem the app solves and who for. The trap is writing marketing copy. A reviewer is deciding whether the app is what it claims and whether a category is right; “a local multiplayer music guessing game for friends in the same room” answers that, “the most fun you will have all night” does not.
3. Setup and access instructions
How to reach the main features, plus credentials for a demo account if there is one. If nothing is gated behind a sign-in, say that in the first line; it removes an entire class of follow-up. Number the steps. A reviewer has minutes, not patience.
4. External services and platforms
Every data provider, authentication service, payment processor and AI service the app relies on to do its job. This is a privacy and a dependency question at once: Apple is checking that your App Privacy answers match reality, and that your core functionality does not sit on something that could vanish. List them as a table, and say plainly what each one stores.
5. Regional differences
Either describe them or state that the app behaves identically everywhere. Incidental variation still counts: if your content comes from an API that returns different results per storefront, that is worth one sentence, because the alternative is a reviewer in another country seeing something you did not describe.
6. Regulated industries and third-party material
The sharpest of the six. If your app touches health, finance, gambling or licensed media, you are being asked to prove you are allowed to. Media apps get caught here constantly: playing music, video or book content you do not own needs an explanation of where it comes from and under what terms.
The trap underneath: a paywall with nothing behind it
Buried in the same rejection is a “Prevent Common Issues” section that most people skim. One line in it matters more than the questionnaire:
“In-App Purchase products should be configured and submitted alongside the app.”
When we checked our own app against that, the in-app purchase list in App Store Connect was empty, while the build shipped a $4.99 unlock screen with Buy and Restore buttons. A reviewer tapping Buy would have hit nothing at all. That is not a 2.1 problem, it is Guideline 3.1.1, and it would have burned the next review cycle on its own.
This is easy to check and easy to miss, because the app builds and runs perfectly without it. The purchase code is written against a product ID; whether that ID exists on Apple's side is a separate piece of state in a separate system. You can query it directly:
GET /v1/apps/{APP_ID}/inAppPurchasesV2If that comes back empty and your app has a paywall, stop and fix it before you reply to anything. A first non-consumable also has to be submitted with a new app version; it will not clear on its own, so it must be attached to the submission rather than created and forgotten.
While you are there, check for product IDs your app no longer sells. Ours still referenced legacy subscription IDs for restore compatibility, for an app that had never shipped, so no legacy purchase could exist. A subscription ID in a build with no configured subscription is another 3.1.1 conversation you do not need.
What the physical-device recording actually takes
If you do not own the device, you rent one. That means a device farm, and it is worth knowing the shape of it before you start.
- Firebase Test Lab does not record video on iOS. Android only. We paid three hours to learn that.
- AWS Device Farm is not on the free plan. It needs a paid support plan, and it is region-locked to us-west-2. Runs cost around a dollar and take twelve to twenty minutes each, which sets the pace of your debugging loop.
- The built-in fuzzer will wreck the take. Device Farm's simplest mode keeps the session alive by tapping randomly, and those taps land on your UI. We have watched it un-tick a EULA checkbox between two steps and then wander into a password reset. If you go that route, the app needs a demo mode that swallows touches and drives itself.
- The alternative is a scripted walkthrough. An Appium test gives you a deliberate recording of the exact binary you submitted, which is better evidence than a demo build. It costs you packaging instead: Device Farm needs custom environment mode with a test spec, and the dependency bundle must be wheels: ship a source tarball and the offline installer tries to build it, fails to find setuptools, and the whole run dies before the app launches.
Whichever way you go, pace the recording. Two seconds of stillness after each tap is the difference between a video a reviewer can follow and a blur they will ask you to redo.
The short version
A 2.1 “Information Needed” rejection is not a setback, it is an introduction. Answer all six items in one reply, put the same answers in the App Review Information notes field so the next submission starts from a known position, and before you send anything, check that every paid feature in your build has a real product behind it.
The questionnaire costs you an afternoon. The empty in-app purchase list costs you a review cycle, and it is the one nobody warns you about.