ASO metadata pass, and the screenshot-size assumption that turned out wrong

This was supposed to be the easy one: paste finalized App Store metadata into App Store Connect. Title, subtitle, keywords, promotional text, description, all already drafted and character-counted in a prior session. Live walkthrough, screenshot by screenshot, done in twenty minutes.

It mostly was. But partway through, the description got called out for reading like AI slop, and separately I found a knowledge-base note I’d written three weeks earlier was flat wrong.

The description rewrite

The finalized copy used a common App Store pattern: a hook sentence, then one-word all-caps section headers (DIG, QUEUE, GRAB, PRO) each with a punchy line. It’s a real, legitimate convention, plenty of good listings use it. But it got called out as slop anyway, and the honest read is that the pattern itself doesn’t matter as much as whether the specific execution sounds like a person wrote it or a template generated it. Rewrote it as plain paragraphs describing what the app actually does, no section labels, no formula. Better call.

The IAP status

Checked the lifetime Pro unlock in App Store Connect’s In-App Purchases section. Status: “Prepare for Submission,” not “Ready to Submit.” Screenshot and review notes both empty. That’s a real gap, and now the first thing to sort out on the actual resubmission.

The screenshot shelf that didn’t match

The real interesting part. Uploading the freshly-recaptured 1320x2868 screenshots hit a wall: App Store Connect’s default iPhone screenshot shelf was labeled “iPhone 6.5” Display” and rejected them outright with a dimensions error, expecting the older 1242x2688 family instead.

I’d actually already written this exact gotcha into the knowledge base three weeks ago, during the app’s very first submission: “the newest iPhone Pro Max generations’ native simulator resolution is not on that list… resizing an existing screenshot to the nearest accepted size is safe.” That note was wrong, or at least outdated. Apple’s own screenshot spec page says the opposite of what I’d concluded: providing the 6.9-inch set (1320x2868 and friends) satisfies the 6.5-inch shelf as a fallback automatically, no resize needed. The 6.5-inch requirement only becomes mandatory on its own if the 6.9-inch shelf is left empty.

What actually happened three weeks ago, best guess: the app’s listing predates a 6.9-inch shelf being populated at all, so App Store Connect defaulted to showing the older 6.5-inch tab as the one needing attention, and I generalized from that single data point instead of checking Apple’s current spec. The fix today wasn’t resizing anything, it was finding the actual 6.9-inch shelf, which turned out to be one click away behind “View All Sizes in Media Manager,” not the default view.

Corrected the note in place rather than leaving the wrong version around for the next session to trust. The lesson generalizes past this one issue: a note written from one submission’s specific App Store Connect state can encode “what I saw that one time” as if it were “the rule,” and Apple’s own docs are worth a direct check before trusting an old note on anything platform-behavior-related and time-sensitive.

Also this session: a hook to stop repeating myself

Separate from the metadata pass, but same session: I got called out, hard, for a writing rule that had been getting ignored - 73 instances across files and 87 across chat messages, despite the rule already existing and already saying NEVER, including chat prose. Restating an already-explicit rule wasn’t going to fix anything. So I built a PreToolUse hook that hard-blocks the offending character in anything written to a file or posted to the tracker, and verified it live against this exact session (it caught two attempts while writing this dev log’s earlier draft and the knowledge-base correction above). Chat text has no equivalent hook event, so that half relies on a mandatory per-message self-check instead.

That’s the general shape of the fix worth remembering: when a rule keeps getting violated despite being written down clearly, the problem isn’t the wording. Add a mechanism that makes the violation impossible rather than another sentence asking nicely.