A Claude Code Skill for Paywalls: The Config That Survived Two Rejections

A paywall is the one screen in a subscription app that can fail in two directions at once. It can convert at nearly zero because a placement never fires, or it can keep the app out of the store entirely because a pattern the optimization blogs call canonical is a rejection trigger. Both failures are quiet. Neither one shows up in a crash log, and neither one is the kind of thing a general-purpose "build me a paywall" prompt knows to look for — because the rules that matter here aren't in the SwiftUI documentation, they're in App Review's guidelines and in whatever the last reviewer decided. A paywall skill for Claude Code is a fixed standard the agent applies instead of re-deriving one per app. This page is about the one AgentSource ships for the job — the iOS Paywall Playbook, $9 — and it carries a captured field report: real output from a documented audit, readable before you pay.

What the skill actually encodes

A skill is a plain-markdown SKILL.md package — a folder of instructions the agent loads and follows, nothing to compile, no SDK to install. This one holds four things that are tedious to remember and expensive to forget:

• The four-placement set. Onboarding, session-start, action-gated, and win-back, each with its trigger and its frequency cap. Most apps ship one of the four and wonder where the revenue went.
• Honest pricing presentation. The per-week math, a correctly computed savings badge, and the rule that the billed amount is the conspicuous element with the trial stated subordinately — which is also what keeps you clear of a misleading-pricing read under Guideline 3.1.2.
• StoreKit 2 patterns, copy-paste. Session-start placement, cancel detection, verified-transaction unlock. Plain StoreKit 2 and SwiftUI — no RevenueCat, no Superwall, no paywall vendor of any kind required.
• A compliance reference with two real rejections in it. Plus the full 12-item Guideline 3.1.2 disclosure checklist, including the subtle miss that bounces apps: legal links that technically exist but render too small and too gray for a reviewer to find.

The part that was paid for in rejections

Two patterns that paywall-optimization writing treats as standard practice got a real app in this portfolio rejected.

The first was the on-paywall free-trial toggle — Guideline 3.1.2(c). The second is the one worth reading twice: a post-cancel recovery sheet, auto-presented when the user dismissed the native purchase sheet. It was fully disclosed — price, auto-renewal terms, legal links, all present — and that is precisely why the team believed it was safe. A sibling app's rejection under Guideline 5.6 proved otherwise. The lesson written into the skill is a single sentence: the trigger is the violation, and disclosure does not cure it. The reviewer's own language is quoted in the compliance reference alongside the replacement that got the resubmission through.

That's the difference between a playbook and a listicle. A listicle tells you what tends to convert. This one also tells you which of those things will get you bounced, because somebody already ate the bounce.

The field report: four gaps and a badge that read "SAVE 0%"

The proof isn't the feature list — it's the captured run. The field report on the product page is the playbook's audit pass against a shipped contract-review app in the same factory, and it's the actual output, not a summary of it.

Placement coverage. Onboarding was present. Session-start was missing entirely — rg 'scenePhase|sessionPaywall' returned zero hits, which the skill flags as the most common gap of the four. Action-gated was partial: hard gates existed on export and compare, but there was no free first taste of the core feature, so it was changed to one free scan before the gate with the paywall copy updated to say so. Win-back offers weren't configured at all, flagged as an App Store Connect task rather than a code change.

Compliance. The post-cancel sheet described above was found and removed; cancel now returns to the same paywall with nothing popped. The trial toggle was already absent. Billed-amount conspicuousness passed.

Pricing presentation. The savings badge was computed in Decimal and rendered "SAVE 0%" at runtime. This is the finding worth dwelling on: the mock and screenshot modes hid it completely, and it only surfaced on a live simulator run of the real paywall. A reviewer of the code would have seen a correct-looking formula. The loss-aversion anchor — a bare struck-through price — was relabeled "at weekly rate" under the honest-label rule, and the CTA moved from "7-Days free" to "1-Week free" so it reads as one unit of the billing period rather than a countdown.

Four placement and compliance gaps plus two pricing-presentation bugs, found and fixed in one audit pass, on an app that already looked finished. Re-audited across subsequent builds: zero drift.

Where it sits in the shipping sequence

A paywall audit is not the last gate, and it isn't the first one either. Two skills bracket it:

• Deep QA Audit Loop ($9) runs before. It's a loop with hard exit conditions — it stops at zero critical bugs, not after a set number of rounds — and its own field report is a >= dailyTarget comparison that fired a 365-day "PERFECT" streak for a brand-new user across 13 call sites. Fix the app before you audit the thing selling it.
• App Review Pre-Submit Checklist ($9) runs after, as the final gate before archive and upload. Every check in it exists because a real submission failed.

Buy the set: the App Store Kit

Individually those three are $9 each. The App Store Kit issues all three for $29, alongside the keyword engine, the screenshot playbook, and the review-response engine — six skills covering build-complete through live, converting, and reviewed. If you're heading into a submission, that's the set that covers the whole arc rather than one screen of it.

One honest limit, stated plainly: the playbook can fix a configuration, and it cannot make people want your product. The published benchmarks it carries are reference points to judge your numbers against, not a promise about them. What it does catch reliably is the mechanical zero — the placement that never fires, the badge rendering 0%, the pattern that kept the app out of the store in the first place. That's the failure worth $9 to rule out. Read the full field report first, then decide.