Build Repeatable StoreKit Purchase Tests on a Cloud Mac

The hardest in-app purchase failures to reproduce are rarely unresponsive buttons. More often, transaction state leaks between test cases: the first test completes a purchase, and the second test—which is supposed to verify the non-purchased interface—immediately sees an unlocked state. When regression tests run continuously on a cloud Mac, the simulator, StoreKit session, and persistent app data must be isolated together. Otherwise, individual tests will pass while the full suite fails.

Divide test boundaries into three layers

The first layer is a pure business state machine. Feed it states such as “not purchased,” “pending,” “purchased,” “refunded,” and “expired,” then verify feature access and UI state without starting a real transaction. The second layer uses StoreKit Testing to verify product queries, purchase callbacks, transaction listeners, and subscription changes. The third layer is reserved for controlled pre-release acceptance testing of server notifications and production product configuration.

This separation allows most regression testing to run locally while making it clear whether a failure belongs to business logic, the client-side transaction integration, or external configuration. Do not make every UI test begin by tapping the purchase button. State-machine unit tests should make up the majority of the suite, while StoreKit integration tests should cover only critical paths.

StoreKit Testing provides a controllable transaction environment, not a replacement for the production transaction pipeline. A passing test shows that the client behaves correctly for the supplied events; it does not confirm that external configuration has passed acceptance testing.

Create a reviewable product catalog

Create StoreKit/Local.storekit in the project. Its product identifiers must exactly match those used by the code. Define identifiers centrally rather than scattering them across views and tests:

enum ProductID {
    static let proMonthly = "com.example.app.pro.monthly"
    static let proYearly = "com.example.app.pro.yearly"
}

Commit the configuration file to version control, and require code review for changes to test prices, display names, and subscription periods. A common team mistake is to copy an old configuration and update only the display name, leaving the product identifier unchanged. Product queries then return an empty array.

Create a dedicated test Scheme such as StoreKitRegression, and select the same .storekit file in the Scheme’s Run and Test options. Do not depend on a developer’s personal Scheme. xcodebuild can discover the Scheme only when it is shared.

Start every test case with a clean session

Use StoreKitTest to create a test session. In setUp, disable system dialogs and clear transactions. After each test method finishes, also remove any entitlement cache maintained by the app itself.

import XCTest
import StoreKitTest

final class PurchaseRegressionTests: XCTestCase {
    private var session: SKTestSession!

    override func setUpWithError() throws {
        session = try SKTestSession(
            configurationFileNamed: "Local.storekit"
        )
        session.disableDialogs = true
        session.clearTransactions()
        UserDefaults.standard.removeObject(forKey: "cachedEntitlements")
    }

    func testMonthlyPurchaseUnlocksPro() async throws {
        try await session.buyProduct(
            identifier: ProductID.proMonthly
        )
        let unlocked = await EntitlementStore.shared.refresh()
        XCTAssertTrue(unlocked)
    }
}

The transaction listener must start before the purchase begins. If a purchase completes quickly, a listener task started too late may miss the update and cause intermittent timeouts. Refunds, revocations, and subscription expirations should also be triggered explicitly through the session. Then assert the result after refreshing entitlements instead of checking only whether the purchase API returned successfully.

Do not hide race conditions with fixed waits

Task.sleep only postpones a failure; it does not prove that state has been updated. A more reliable design exposes observable state from the entitlement store, lets the test wait for a specific condition, and applies a short timeout. Timeout logs should include at least the product identifier, current entitlements, number of unfinished transactions, and test name, but must not print tokens or complete credentials.

Use a fixed command-line entry point

First, identify the simulator devices installed on the cloud Mac, then configure CI to use a fixed device name. If the image uses different device names, update the pipeline parameters instead of letting the script silently select an arbitrary device.

xcrun simctl list devices available
xcodebuild test \
  -workspace Example.xcworkspace \
  -scheme StoreKitRegression \
  -destination 'platform=iOS Simulator,name=iPhone 16 Pro' \
  -resultBundlePath Artifacts/StoreKitTests.xcresult \
  CODE_SIGNING_ALLOWED=NO

When running simulator tests only, disabling code signing reduces failures unrelated to transaction logic. Clear the results directory before each run or create a separate directory for every job number. Otherwise, an existing xcresult will cause the command to fail immediately.

StoreKit integration tests are generally more stable when run serially. If parallel execution is required, each execution unit needs its own simulator, Derived Data, and results directory. Multiple processes using the same simulator at the same time will contaminate one another’s transaction queues and app data.

Turn failures into actionable evidence

Cover at least six paths: initial purchase, user cancellation, pending purchase, refund, subscription renewal, and subscription expiration. Each path should assert three layers: the state returned by StoreKit, the state of the entitlement store, and the final UI state. Checking only whether button text changed can miss a failure to update entitlements in the background.

Before committing, review the following in order:

1. The .storekit file and shared Scheme are committed to version control.
2. Transactions and the local entitlement cache are cleared before every test case.
3. The transaction listener starts before the purchase action.
4. Tests do not depend on fixed waits or execution order.
5. Every parallel job uses an independent simulator and artifact directory.
6. Failed runs retain xcresult, test logs, and UI attachments.
7. Server notifications and product configuration are verified separately before production release.

When running these workloads on HireVM, first check the currently available configurations in the console, then plan simulator allocation around the number of test shards. In-app purchase tests are usually more sensitive to state isolation than to the duration of a single build. Make one serial pipeline pass repeatedly before introducing concurrency; this keeps troubleshooting costs much lower.

Frequently asked questions