Notes from May 2026: Running a Parallel StoreKit 2 Migration Across Four iOS Wallpaper Apps with Claude Code

Five branch points indie developers will hit on the StoreKit 2 migration

The Apple docs are clean enough on the move from StoreKit to StoreKit 2, but handling four titles at once exposed a different shape of difficulty. Here are the five branch points I actually hit.

1. Server-side or client-side receipt validation?

Transaction.currentEntitlements lets you stay fully client-side. But if you take subscription abuse seriously, you want server validation. I unified all four titles on a server path backed by App Store Server API, exposing a new endpoint on api.dolice.asia. The client still reads Transaction.currentEntitlements as a fallback, and only falls back to the server verdict when the two disagree.

2. When to subscribe to Transaction.updates

If you don't subscribe to Transaction.updates in the very first Task after launch, you'll miss the completion event when a user comes in from an App Store promotional offer. I asked Claude Code to set the subscription up inside @main, and the first draft put it inside App.init synchronously - shaving about 200 ms off the cold start in the wrong direction. It took an explicit "use a detached background task" prompt to fix it.

3. Caching Product.products(for:)

Product.products(for:) has internal caching, but calling it on every screen open still spins forever when the device is offline. I now persist the most recent Product.id and displayPrice in UserDefaults and return the cached price when the network is unavailable. Claude Code's first stab tried to Codable-encode the whole Product, which doesn't compile because Product isn't Codable. Adding that constraint to the prompt up front would have saved a round trip.

4. Price mismatches between TestFlight and production

The displayPrice in sandbox sometimes differs from production. When a user unlocks Pro via an AdMob rewarded ad, you can end up with sandbox showing ¥120 while production shows ¥150, which makes UI copy go strange. Splitting the price label into "server-recommended price" and "StoreKit-supplied displayPrice" let me ship the production review without a single round of feedback on copy.

5. Forgetting to remove the old SKPaymentQueue listeners

This was my biggest stumble. If you keep SKPaymentTransactionObserver while subscribing to Transaction.updates, IAP state notifications fire twice. Four finishTransaction was called twice crashes showed up in TestFlight just before release, caught only at the final staging step. Asking Claude Code to grep for legacy StoreKit traces surfaced 17 spots across the four repos using SKPaymentQueue.default(); I am still working through them one by one.

Pitfalls when delegating the AdMob + entitlement decision

I did not use RevenueCat this round; the stack is Apple-native StoreKit 2 plus a self-hosted server check. AdMob rewarded ads still grant Pro access through a reward_action_count field that has lived in the backend since the very first version. That has to be OR'd with the StoreKit subscription verdict.

@MainActor
final class Entitlement: ObservableObject {
    @Published private(set) var isPro: Bool = false
 
    func refresh() async {
        let subscribed = await checkSubscription()       // From StoreKit 2
        let rewardUnlocked = await checkRewardUnlock()   // From AdMob + server
        let serverGrant = await checkServerEntitlement() // From self-hosted API
        isPro = subscribed || rewardUnlocked || serverGrant
    }
 
    private func checkSubscription() async -> Bool {
        for await result in Transaction.currentEntitlements {
            if case .verified(let tx) = result, tx.productType == .autoRenewable {
                return true
            }
        }
        return false
    }
}

When I asked Claude Code for "a helper that ORs the subscription and reward verdicts", the first version short-circuited - if the subscription returned true it skipped the other checks. In practice you sometimes want to honor the remaining reward window even right after a subscription is canceled, so I want all three signals evaluated every time. It took another prompt round to make that explicit.

Phased rollout schedule

Releasing four titles in lockstep would have been too risky, so I staggered them like this:

1. Day 1: Ukiyo-e Wallpapers (the smallest DAU base) at 1% rollout.
2. Day 3: Bump it to 10%, watch Crashlytics and AdMob reports for 24 hours.
3. Day 4: With Ukiyo-e clean, start Illustration Wallpapers at 1%.
4. Day 7: Ukiyo-e to 100%, Dolice Wallpapers to 1% on the same day.
5. Day 10: Beautiful Wallpapers last at 1%, because it carries the biggest revenue weight.

That order is what caught the Transaction.updates double-fire in Illustration Wallpapers on day 3, and let me fix it before Beautiful Wallpapers ever went live. If I had shipped everything together, a full rollback would have cost roughly two days of ad revenue across the portfolio.

What I gave to Claude Code, and what I clawed back

Looking back at May, the tasks that paid off when handed to Claude Code were:

• Applying the same diff pattern across four repos (the SKPaymentQueue cleanup).
• Cross-checking ATT prompt copy and the privacy manifest for consistency.
• Drafting the first cut of the AdMob + StoreKit entitlement helper.
• Pre-release notes in four languages.

What I had to claw back:

• Japanese copy review (the polite-form drift was hard to spot).
• Reproducing a TestFlight-only crash (the suggested reproduction never actually crashed).
• Phased rollout percentage decisions (suggestions jumped to "go 50%" without considering business days or DAU shape).

What I am trying next

The May sweep landed at a stable rollout across three of four titles, with no major crashes. The next experiment is wiring Claude Code Hooks into a git commit step to auto-check that no SKPaymentQueue traces remain and that Transaction.updates is always being set up under Task.detached.

Parallel work is past the limit of a single pair of hands, but a Mac mini with one developer can carry four titles if you give Claude Code a clear "do not touch" list and a hard ordering. If you run a similar portfolio, I would start by piping just one title through Claude Code for a week and see what the operational friction looks like before scaling up. I am still finding my own footing here, but I hope these notes are useful.