Shipping alone: what to check, what to skip

What you can honestly defer

Localisation, until there is evidence of demand. [Shipping in one language is fine.]

iPad, unless the app is genuinely better on a large screen and you will test it every release. Supporting it badly is worse than not supporting it. iPad and device compatibility.

Android, if you are one person and iOS is where your users are. Two stores is two sets of gates, two release processes and two sets of forms. The Play launch checklist.

Features that add guideline surface you are not ready to support. A social feature brings 1.2's four requirements including blocking, which is a data-model change.

The rule: every capability you add is a permanent obligation, and one person's obligations compound faster than a team's.

The pass, written down once

The point of writing it down is that you stop re-deriving it:

# 1. resolved config, not app.json
npx expo config --type public > /tmp/cfg.json
grep -E 'UsageDescription|bundleIdentifier|version|buildNumber' /tmp/cfg.json

# 2. capabilities you did not ask for
grep -rn 'UsageDescription' ios/*/Info.plist 2>/dev/null
grep -o 'android:name="android.permission.[A-Z_]*"' \
  android/app/build/intermediates/merged_manifests/release/AndroidManifest.xml 2>/dev/null | sort -u

# 3. metadata
grep -rniE 'android|google play|play store' fastlane/metadata src app 2>/dev/null | head
grep -rniE '#1|the best|[0-9,]+\+? (users|downloads)' fastlane/metadata 2>/dev/null | head

# 4. accounts without deletion
grep -rniE 'sign ?up|create account' src app --include=*.tsx | head
grep -rniE 'delete (my )?account' src app --include=*.tsx | head

# 5. secrets that must not ship
grep -rniE 'sk-[a-z0-9]{10}|api[_-]?key\s*[:=]\s*["\x27]' src app app.json 2>/dev/null | head

Then the stranger install, by hand. Automated checks find config problems; a person finds behaviour problems, and doing one without the other leaves half the surface uncovered. What you can check for free.

The mistake that costs the most

Fixing only the thing the rejection named.

A reviewer stops at the first blocking problem. Fix that, resubmit, and you frequently meet the second one, then the third. Each meeting is a full cycle, and for one person a cycle is not just time, it is the loss of momentum on everything else.

Before every resubmission, run the whole pass again, not the item you were told about. After a rejection. · What a rejection actually costs.

What to automate

For one person, automation is worth it where the check is boring and the failure is silent:

The dependency audit, on every install.

The resolved-config diff, so a config plugin adding a permission is visible.

A pre-release checklist in the repo, because the version in your head degrades between releases and you will ship three months apart.

Not the stranger install. That has to be a person, and it has to be a person who will notice that the first screen is blank.

And the part that is not compliance

Shipping alone means every hour spent on process is an hour not spent on the product, which is why the applicability pass matters more than thoroughness.

The goal is not to know the guidelines. It is to know which twelve paragraphs apply to your app, and to check those every time. The first-submission checklist. · Shipping your first update.

shipcheck exists because this pass is mechanical, and mechanical work done by one person before a release is the work most likely to be skipped. What it checks.

Questions and answers