R.GOLKHANDANI
Home / Blog / Posts / Before the First Upload
online--:--:--

Reza Golkhandani // Senior Software Engineer | Backend platforms

From Empty Folder to App Review in Two Weeks: The Release Playbook

iOS | App Store | Release engineering

01

From Empty Folder to App Review in Two Weeks: The Release Playbook

The goal

My studio ships small iOS apps, and the goal for the third one was to go from an empty folder to a build in App Review in two weeks with no surprises. The first two had each taught a lesson the hard way: a name reserved by an unpublished record, a bundle identifier burned by a test install, a validation failure over a permission string for a feature the app did not have. The playbook that came out of them is now the studio's release train.

The approach

Make every decision that becomes permanent at the first upload deliberately, before it. Audit against what the build links, not what the app does. Copy a proven skeleton rather than writing one.

What I built

  • Naming first. Check the store search, then create the store record early and let it be the final arbiter, with a second name ready. Store name and home-screen name are separate.
  • Bundle id before any install. Registered in the developer portal first, because a free-provisioned install claims an id permanently.
  • Usage strings per linked plugin. A file picker that bundles an image picker needs camera and photo strings. The audit is a list of plugins, not features.
  • A copied skeleton. Export options, privacy manifest, encryption declaration, localization setup, icon rendering, and a build-status script, copied from the last app and renamed.
  • Legal hygiene. No links to real store products in sample data, no personal data anywhere in the bundle, a privacy page that describes what the app actually does.
  • Compile-time flags. Unfinished integrations tree-shake out of the release build, so review sees only what is ready.
  • Field limits written down. The sixty-four pending notification cap, time-zone travel, and background work that finishes on next foreground each have a standard mitigation in the playbook.

The result

The third app went from empty folder to a build in review in under two weeks, with no rename and no validation failure. The fourth followed the same path. The playbook has not needed a new entry in three releases, which is how you know a checklist is finished.

Takeaways

  • A few store decisions are free only until the first upload. Make them on purpose, before it.
  • Validation checks what you link, not what you use.
  • Write the checklist the day you pay for the lesson.
02

Connect with Me