Five Pre-Submission Checks That Help a Solo App Pass Review

Reviewers touch your weakest state first

You finish a build, feel ready, then a rejection arrives with a guideline number and no apology. SameQ launched on the App Store on September 24, 2026, after five App Store reviews and four rejections. App Store and Google Play reviewers test onboarding, edge cases, permissions, payments, and unclear behavior. An app that only works on the happy path will fail review.

Apple's App Store review is more manual and experience-focused, while Google Play review is more policy-driven and system-based. By April 2026, Apple seemed to be using automation for some app reviews and approvals. A machine may approve some apps, but it will not rescue a broken onboarding state. You need a short, repeatable pass before submission.

Keita Nakagawa's SameQ had its first commit on August 17, 2026, and by launch contained 197 commits, 23 sprints, 23 Supabase migrations, about 15,600 lines of Swift, and 53 test files. A solo app can carry many moving parts and still fail on a small state. The archived binary is the contract. If it is stale, the reviewer sees the old bug. A few minutes making the archive explicit can save the most expensive kind of waiting.

Five checks keep the archive honest

Each check targets a rejection reason that can cost days, not a new ritual.

• Verify the archive's commit. Confirm the archived build matches the branch you just tested, and that the onboarding fix is present in the binary. SameQ's first App Store build, 1.0 (1), was rejected under Guideline 2.1(a) because the archived binary predated a fix for a session-expired onboarding bug.
• Design for the emptiest day. Open the main screen with no answers, no network, and a stale session. SameQ added a self-healing Postgres function called ensure_official_answers() that inserts operator answers when a day's question has none.
• Ship the full compliance checklist in one build. Confirm privacy, anonymous sign-in, and report/block controls are all in the same binary. SameQ translates answers using Apple's on-device Translation framework, and post bodies are not sent to a translation server. SameQ allows anonymous accounts without requiring an email address or phone number. A SameQ update moved Report and Block controls directly below each answer with a visible label and icon.
• Write review notes from the code. List changed screens, permissions, and data flows from the submitted diff. The notes should describe the submitted build, not the next sprint.
• Test on a real device in a non-native language. Set the device language to a language you do not write in and run onboarding. Locale problems can stay invisible unless tested in the exact international context, because real devices and browsers handle fonts, input methods, locale settings, and rendering differently.

The audit is cheap because it targets the places where a solo developer saves the most time. A full QA suite is not required before the first submission. The audit catches the states a reviewer is likely to touch first, and it makes any rejection easier to answer by pointing to exact build behavior instead of guessing. That protects your calendar, which is the real asset.

A repeatable submission protects your hours

A solo developer's margin is measured in hours, not just revenue. A rejection can cost waiting, re-archiving, and explaining. The five checks turn that cost into a short routine.

Automated testing is faster, more repeatable, and generally gives more actionable feedback earlier in the development process. The last hour before submission is still human. It is the hour where you start walking the reviewer's path. Do that, and review stops eating your hours.

If coding agents write the code quickly, the reviewer still walks the app. Keep the submission small enough that a rejection does not become a rebuild.