Apple rejected both of my first submissions.

This note paraphrases the App Review messages. Submission identifiers, reviewer correspondence, and account details are intentionally omitted.

I submitted two different iPhone apps on the same day. ReturnProof Inventory records QR-based equipment checkout and return inspections. Wayfarer is an anonymous photo-letter experience in which a story travels from city to city. The next morning, both app versions were marked Rejected under Guideline 2.1 — App Completeness.

The wording that mattered was “Information Needed — New App Submission.” Apple said the developer account had limited App Review history and asked for more information before it could complete the reviews. It did not identify a reproducible crash or a specific broken feature.

What Apple asked me to provide

1. A screen recording from a physical device on the latest operating system, beginning at launch and showing the normal end-to-end flow.
2. The app’s purpose, target audience, problem, and user value.
3. Setup and access instructions, including demo credentials or sample files when needed.
4. A list of external services, tools, and platforms used by the core experience.
5. An explanation of regional differences, or confirmation that the same features work in every region.
6. Authorization material if the product belongs to a regulated industry or uses protected third-party content.
7. An overview of the in-app purchase and exact directions to reach the purchase flow.

The recording also needs to demonstrate account creation and deletion, user-content reporting and blocking, and paid features whenever those flows exist. Apple asked for the same information in both the reply and the persistent App Review Notes field.

What was actually rejected

What I got wrong

I treated a successful archive, upload, metadata pass, and simulator QA as if they added up to a review-ready submission. They did not. For a new developer account, the reviewer also needs a compact evidence package that makes the product understandable without reverse-engineering it.

The simultaneous submissions made this obvious. Two unrelated apps received nearly identical requests one minute apart. That strongly suggests an account-history verification gate rather than two independently discovered defects.

Update: the physical-device workflow works

I connected the submitted Wayfarer build to an iPhone 16 Pro running iOS 26.6.1, then added a deliberately paced, test-only App Review walkthrough. It demonstrates the primary send-and-receive experience, content reporting, author blocking, the one-time ad-removal purchase location, and the account-deletion confirmation. The complete 86-second walkthrough passed on the physical phone with no test failures.

One practical failure was useful too: QuickTime initially selected the iPhone as a Continuity Camera while iPhone Mirroring was also trying to connect, which produced a camera-in-use conflict. Those are camera and mirroring sessions, not the same thing as an on-device screen recording. I closed both sessions and kept the verified UI automation as the repeatable script for a native iPhone screen recording.

The resubmission checklist

• Run the exact submitted build on a supported physical iPhone.
• Record launch, the primary workflow, privacy and safety controls, ad display, purchase, and purchase restoration.
• State clearly which data stays on-device and which third-party services receive data.
• Explain who the app is for and why public App Store distribution is appropriate.
• Put stable test instructions in App Review Notes, not only in a one-time message.
• Verify that the first in-app purchase is included with the app version.

Getting a build into App Store Connect was an engineering milestone. Getting a stranger at Apple to understand and verify it is a separate product task. The rejection made that boundary visible.