App Store Machinery

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.

Why this pack

**The five traps this pack pre-solves:**

• **JWS chain verification** — the deprecated `verifyReceipt` endpoint is the path of least resistance for an agent that hasn't been told otherwise; this pack pins local `SignedDataVerifier` verification and greps the repo for banned legacy symbols in preflight.
• **4040010 sandbox routing** — TestFlight/sandbox transactions returning "TransactionIdNotFound" from the *production* Server API is an undocumented gap; this pack hardcodes production-first, retry-on-4040010-against-sandbox routing so it isn't rediscovered by trial and error.
• **Paid-agreement empty products** — `Product.products(for:)` silently returns an empty array until the Paid Applications agreement, banking, and tax forms are complete in App Store Connect — nothing in Xcode tells you why. The onboarding calls this out as the single most common "products won't load" cause before you burn hours debugging code that was never broken.
• **Privacy-manifest reason codes** — required-reason API declarations (like `CA92.1` for `UserDefaults`) sit in a long enum buried in Apple's docs; this pack pre-fills the manifest and lints it in preflight.
• **Review-rejection preflight** — guidelines 2.1, 3.1.1, 3.1.2, 5.1.2, and export compliance are all things Xcode lets you submit and Apple rejects 2–3 days later; the preflight lane statically catches what's checkable before you burn a review cycle finding out.

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.

Verified against

• claude-opus-5
• claude-sonnet-5
• claude-haiku-4-5

Supported stacks

• swiftui-storekit2-node

  xcode	26.6
  ios-sdk	26.5
  swift	6.3
  swift-tools-version	6.2
  min-ios-deployment	17.0
  fastlane	2.237.0
  ruby	3.4.10
  node	24.18.1
  @apple/app-store-server-library	3.1.0
  jsonwebtoken	9.0.2

Estimated buyer token cost

730,000 tokens for one build pass (estimate, not a guarantee).