Build App Store Machinery on swiftui-storekit2-node

Getting in-app purchases right on the App Store means passing cryptographic verification you can't eyeball, routing around an undocumented sandbox error code, and clearing five rejection guidelines that Xcode will happily let you submit anyway — most of which surface days later as a review rejection, not a build error. This pack turns an existing SwiftUI app into one that sells subscriptions and a lifetime unlock correctly the first time: a StoreKit 2 paywall, a server that is the actual source of truth for who's entitled to what, a non-interactive fastlane pipeline, and a preflight that catches the top rejection causes before Apple does. The receipt requires the JWS chain-verification logic to be proven cryptographically correct against a locally-signed, Apple-format test chain before this pack ships — not just "the code compiled."

Example use cases

• **An indie SwiftUI habit-tracker adding its first paywall** — the developer has never touched StoreKit; this pack adds monthly/annual subscriptions plus a lifetime unlock without them learning JWS verification or App Store Server Notifications from scratch.
• **A freemium PDF-scanner app adding a lifetime-unlock tier alongside an existing subscription** — the non-consumable path (offer + entitlement math + preflight checks) is already wired in, not bolted on after the fact.
• **A solo developer who shipped their own StoreKit 2 code and keeps getting rejected on 3.1.2 / 5.1.2-style guidelines** — the review-rejection preflight and pre-filled privacy manifest target exactly the guidelines that generic StoreKit tutorials skip.
• **A small agency delivering IAP for a client app that needs audit-ready entitlements** — server-authoritative state driven by Notifications V2 (not "unlock on the client and hope"), so entitlement survives app deletion, refunds, and billing-grace renewals.

Scale envelope

This pack ships shipping machinery, not a serving system — the numbers below are about the entitlements server, not app-store-wide traffic. Derived from the shipped architecture, not aspiration — and labeled as engineering estimates, since none of this is load-tested at this pack's price point.

• **Entitlements store (subscriber ceiling):** the server is a single Node process backed by `node:sqlite` on one Railway volume — no clustering, no read replica. SQLite serializes writes through one process, but comfortably absorbs this write rate as the sole writer — this server writes roughly once per verified transaction and once per notification — order of a handful of rows per subscriber per *month* (a renewal, occasionally a grace-period bump). That comfortably covers an app in the range of **roughly 25,000–50,000 active subscribers** on a single small Railway instance before instance-level limits (not subscriber count) become the constraint.
• **First ceiling:** not subscriber count — it's concurrency and durability. One Node process is a single point of failure with no horizontal scaling; a burst of many simultaneous purchases (a launch spike, a price-drop promo) serializes through `node:sqlite`'s single-writer lock instead of parallelizing; and one Railway volume is your entire durability story until you back it up.
• **App Store Server Notification volume:** notifications fire once per subscription lifecycle event, not per app session — a monthly subscriber generates roughly 12 renewal notifications a year (annual: 1), plus one-off `SUBSCRIBED` / `EXPIRED` / `REFUND` / `GRACE_PERIOD` events. At 25,000 monthly-heavy subscribers that's on the order of **800–1,000 notifications/day** — well inside the under-5-second response budget Apple requires, for a server this small.
• **Upgrade path:** `server/src/store.js` is the only file that talks to the database (every read and write in the pack routes through it) — swapping it for a Postgres-backed implementation when you outgrow single-instance SQLite is a contained, single-file change, not a rewrite of the JWS verification or notification-handling logic. `ARCHITECTURE.md` documents the adjacent `node:sqlite` → `better-sqlite3` driver swap as the escape hatch for the (cosmetic) experimental-warning issue; moving to Postgres for horizontal scale is the natural next step through that same seam.

**What it costs to skip the pack (modelled, not measured):** building this rig yourself the way most people actually work — one agent on a top-tier model, no cheap-tier routing, no parallel subagents, no prompt-caching discipline — models out at roughly **$90–370 in API tokens, likely around $185**. That's this pack's own measured build volume repriced at Opus-class rates, multiplied by an exploration factor for the five traps above and the 15 pinned decisions behind them; the pack-guided build itself measured ≈$7 of tokens per verification run (August 2026 rates), because tasks route down to cheaper tiers. Honest reading: at the likely figure that clears the $129 price, but at the low end it doesn't — treat the token math as break-even. The number tokens can't price is the rejection round-trip: every wrong guess here costs a multi-day App Review cycle, not an API call.

What you get

**Features**

• StoreKit 2 purchase layer (`PurchaseKit` Swift package): monthly + annual subscriptions and a lifetime unlock, `appAccountToken` user linking, transaction-updates listener, restore, offer-code redemption
• Server-side validation service (Node 24.18.1, SQLite, ~zero deps): local JWS signature + certificate-chain verification, App Store Server Notifications V2 with idempotent handling, server-authoritative entitlements API, production→sandbox routing
• fastlane pipeline: `preflight` / `beta` (TestFlight) / `release` lanes, App Store Connect API-key auth, cloud signing, no interactive prompts
• Pre-filled privacy manifest (`PrivacyInfo.xcprivacy`) and StoreKit configuration file for local testing
• Review-rejection preflight: the top App Review rejection causes as automated checks + a short human checklist
• One-command acceptance: `verify.sh` proves the build, including signature verification against locally signed Apple-format test data

**Screens / surfaces**

• Paywall screen (`SubscriptionStoreView`-based: plans, prices, restore, redeem code, Terms + Privacy links)
• Offer-code redemption sheet (system)
• Server endpoints: `POST /verify`, `POST /notifications`, `GET /entitlements/:token`, `GET /healthz`
• UI is native SwiftUI using Apple's own store components — no web design system needed (shadcn/Tailwind n/a for this pack)

**Build budget**

• Expected: **2–3 sessions on a $20/mo plan** (Claude Pro or equivalent — Pro's binding constraint is prompt volume inside its 5-hour rolling window and weekly cap, not raw tokens; Anthropic doesn't publish an exact token-per-window figure, so treat the session count as an expectation, not a guarantee). Session 1: prompts/01-build (three parallel lanes, tasks routed cheap/standard per TASKS.md; only one task needs the `capable` tier). Session 2: prompts/02-verify fix loop. Optional session 3: prompts/03-ship TestFlight run. Plan on **~730k fresh tokens** (input + output, measured) for one build pass — the receipt separately reports **~11.4M tokens of total billed input** (95% of it cache reads, billed at roughly a tenth of fresh-input price) and a measured cost of **$7.18 per verification run**, the most reliable of the three numbers.

swiftui-storekit2-node versions lock