Multiseat Purchases Are Already On: Decide Whether to Keep Them Before October 22

Move entitlement checks into one place

When I moved from the old SKPayment API to StoreKit 2, I realized my "may this user use the paid feature?" logic was scattered across screens. Since Volume Purchasing is stated to require StoreKit 2, this is a good moment to gather that logic in one spot.

The code below is a minimal form that returns only the currently valid entitlement, without depending on who bought it.

import StoreKit
 
enum Access: Equatable {
    case none
    case active(productID: String, ownership: Transaction.OwnershipType, expires: Date?)
}
 
struct EntitlementResolver {
    let proProductIDs: Set<String>
 
    func current() async -> Access {
        var best: Access = .none
        for await result in Transaction.currentEntitlements {
            // Never base paid features on a transaction that fails verification
            guard case .verified(let tx) = result else { continue }
            guard proProductIDs.contains(tx.productID) else { continue }
            // Skip refunded/revoked and expired transactions
            guard tx.revocationDate == nil else { continue }
            if let exp = tx.expirationDate, exp < Date.now { continue }
            best = .active(productID: tx.productID,
                           ownership: tx.ownershipType,
                           expires: tx.expirationDate)
        }
        return best
    }
}

Why write it this way: when the single source of truth is Transaction.currentEntitlements, details about who bought it can't leak into your view code. I read ownershipType and keep it, but never branch on it. If I later decide that family-shared access should be treated differently, there's exactly one place to change.

The listener side belongs in one place too.

func startListening(onChange: @escaping @Sendable () async -> Void) -> Task<Void, Never> {
    Task.detached {
        for await update in Transaction.updates {
            if case .verified(let tx) = update {
                await tx.finish()
                await onChange()
            }
        }
    }
}

Transaction.updates also delivers purchases and expirations that happened while the app was closed. Without it, a change made on another device won't show up until the next time the screen opens.

Check both settings with StoreKit Test

Once you've decided, verify behavior on your own machine. Load a StoreKit configuration file into a test, and you can reproduce a purchase and an expiry.

import StoreKitTest
import XCTest
 
final class EntitlementTests: XCTestCase {
    var session: SKTestSession!
 
    override func setUpWithError() throws {
        session = try SKTestSession(configurationFileNamed: "Products")
        session.resetToDefaultState()
        session.clearTransactions()
        session.disableDialogs = true
    }
 
    func testActiveAfterPurchase() async throws {
        _ = try await session.buyProduct(productIdentifier: "pro.monthly")
        let access = await EntitlementResolver(proProductIDs: ["pro.monthly"]).current()
        guard case .active = access else { return XCTFail("No entitlement right after purchase") }
    }
 
    func testNoneAfterExpire() async throws {
        _ = try await session.buyProduct(productIdentifier: "pro.monthly")
        try session.expireSubscription(productIdentifier: "pro.monthly")
        let access = await EntitlementResolver(proProductIDs: ["pro.monthly"]).current()
        XCTAssertEqual(access, .none)
    }
}

What this checks is only the promise that holds no matter who buys: active right after purchase, inactive after expiry. Please don't expect it to reproduce behavior specific to bulk purchases. Parts of Apple's new purchase types stay invisible, even in the sandbox, until they actually go live. I don't fill that gap with guesses. I plan to revise my decision after looking at real transactions following October 22.

Running the four questions on two typical shapes

Abstract rules are hard to apply, so here are two shapes that come up often in indie apps. Look only at the direction of each answer.

The right-hand column was the counterintuitive one. It's tempting to keep it because bulk demand seems plausible, but if question 3 stays at "no," every sale only adds to your inbox. So I keep it on and set the review date early. Capacity to absorb the demand matters before demand itself does.

Turning things off has a trap too. It feels safe, but if entitlement checks are still scattered, flipping the setting back later produces screen-by-screen inconsistencies. Consolidate the checks first, then decide. Getting that order right was the shortest path through this work.

Leave the decision on one page

A few months from now, you won't remember why a setting is what it is. So I keep one record per subscription.

# decisions/multiseat-2026-10.yaml
decided_on: 2026-10-01
review_on: 2026-11-15          # the day I look at real transactions again
products:
  - id: pro.monthly
    multiseat: off             # on / off
    reasons:
      q1_value_is_personal: true
      q2_price_works_per_seat: unknown
      q3_support_capacity: false
      q4_entitlement_code_ready: true   # consolidated in EntitlementResolver
    note: "Q2 is unknown, so I leaned toward off. Re-decide on the review date."

Allowing unknown is the most important part of this record. If you write a doubt down as "no," the thing you need to verify on the review date disappears.

The trap is stating more than you've confirmed

Last, three things I keep in mind.

• Don't stretch Apple's wording into your own claims. "On by default," "can be disabled or controlled by channel," "StoreKit 2 as the prerequisite." That's the extent of what I could confirm. Billing and refund details I'll add once Apple's documentation grows.
• Even if you turn it off, keep the app-side path intact. If entitlement logic lives in one place, changing the setting needs no app update. Being able to change your mind later makes it easier to decide now.
• If your app came from Rork, check which layer handles billing. A native Swift app generated by Rork Max uses StoreKit 2 directly. If you route purchases through a third-party billing service, check that service's readiness as well.

One next step

Today, open just one subscription in App Store Connect and look at what the multiseat field says. Then answer the four questions with yes, no, or I don't know. That alone turns October 22 from a day you scramble into a day you review.

As an indie developer, I'll start writing this record with the smallest of my subscriptions first.