How to Test RevenueCat iOS Subscriptions Locally? 2026 Remote Mac Workflow

Symptom → quickest fix: RevenueCat subscription results differ between test runs → use Test Store for app logic, an Xcode StoreKit configuration for local StoreKit behavior, and Apple Sandbox for platform purchase verification.

Use this workflow if you are integrating RevenueCat and need to validate subscription purchase states, entitlement access, or a remote Xcode setup. Passing one environment is not evidence that the other environments passed.

Who should read this:
If you have just connected RevenueCat and need to verify a paywall or entitlement, start with the environment map and Test Store checks.
If you need to reproduce purchase behavior in Simulator or run Xcode remotely, focus on the configuration and repeatability sections.
If release readiness is the goal, use the Apple Sandbox stage as a separate acceptance gate.

Choose the test environment by the claim you need to prove

Treat the environments as different test instruments, not interchangeable purchase modes. RevenueCat Test Store checks your app’s integration and state handling; an Xcode StoreKit configuration helps exercise local StoreKit transactions; Apple Sandbox checks the Apple platform purchase path. Apple’s guidance on testing throughout development with Xcode and Sandbox separates these stages.

RevenueCat explains the Test Store’s intended use. Its Apple App Store testing guidance also distinguishes Apple platform testing from local StoreKit testing. Keep the acceptance claim narrow: “the app handled this test transaction” is not the same as “the release purchase chain is ready.”

Prepare the project before the first purchase

Start by making the product mapping explicit. In RevenueCat, check that the product identifier, offering, package, and entitlement used by the app line up with the product setup you intend to test. RevenueCat’s iOS product and entitlement setup guide describes the relationship between store products and entitlements.

Use identifiers that reveal the environment without exposing credentials. For example, write placeholders such as <APP_USER_ID>, <PRODUCT_ID>, <ENTITLEMENT_ID>, and <PUBLIC_SDK_KEY> in your test notes. Do not paste a working credential into a shared ticket, screenshot, or sample project.

RevenueCat’s SDK configuration guide distinguishes the public SDK key used by the app from secret credentials intended for server-side use. Confirm that the app target receives the correct public key for the project and environment; keep secret keys out of the client bundle. See RevenueCat’s SDK configuration instructions before changing the app’s initialization code.

Before launching Xcode, check these items:

• The app’s bundle identifier and RevenueCat project are the ones you meant to test.
• The product identifiers in the app and RevenueCat configuration match exactly.
• The active build configuration loads the intended public SDK key.
• The signed-in app user identifier is known, or you have deliberately chosen the anonymous-user path.
• You have recorded which Scheme and StoreKit configuration are active.

This preparation saves time because a “purchase succeeded but no entitlement appeared” result can come from mismatched product mapping, an unexpected user identity, or the wrong SDK key—not only from a broken purchase screen.

Run the first purchase against Test Store

Use Test Store first when your immediate question is whether the app responds correctly to purchase states. It is a fast way to check the integration without claiming that Apple’s Sandbox has been validated. RevenueCat documents Test Store as its own testing environment, with behavior and setup distinct from Apple’s store path.

Build a small acceptance sequence around what your app must do:

• Load the intended offering and display the expected package.
• Start a purchase and handle a successful result.
• Confirm that the returned CustomerInfo reflects the expected entitlement.
• Confirm that gated content becomes available only when the entitlement is active.
• Exercise cancellation or failure handling, and verify that the app shows a recoverable state rather than granting access.

After each run, inspect both the UI and the state your app uses to make access decisions. A success animation alone is not acceptance. Record the user identifier, product identifier, environment, purchase result, and entitlement state, using placeholders or redacted values in shared logs.

Keep Test Store configuration out of release builds. In Xcode, make the test setting visible in a dedicated configuration or Scheme, and verify the active SDK key before archiving. Do not infer that a successful Test Store transaction proves Apple Sandbox credentials, Apple product metadata, or platform transaction handling are correct.

Add a local StoreKit configuration for repeatable Simulator runs

When you need local control over StoreKit products and transactions, associate a StoreKit configuration file with a dedicated Xcode Scheme. Apple’s instructions for setting up StoreKit testing in Xcode describe the Xcode setup. RevenueCat also provides guidance for Apple and local StoreKit testing.

Make the local file and RevenueCat project agree on the product identifiers that the app requests. If those values diverge, the test may fail before it reaches the code path you wanted to validate. Use the same product naming in your notes, but keep configuration and credentials separated by build environment.

A local StoreKit configuration is not an App Store Connect product record. Apple’s StoreKit testing documentation describes local testing as an Xcode development capability; do not treat a product in the local file as proof that the corresponding platform product is configured or ready for release.

Also keep the scope of a passing test precise. A local purchase can help you test transaction handling and app state changes, but it does not establish that every refund, cancellation, account, or platform-backend event has been accepted. Use the relevant platform testing stage for claims that depend on Apple’s environment.

FAQ: product setup and environment boundaries

Can Test Store verify the Apple purchase flow?

No. It can help you verify how your app and RevenueCat respond to test purchase states, including whether the expected entitlement is reflected. It does not stand in for an Apple Sandbox transaction. If your release decision depends on Apple’s product setup or platform behavior, run a separate Sandbox check and document that result independently.

Can I test before creating App Store Connect products?

You can use Test Store to exercise app-side integration and entitlement logic before relying on a platform product. That is useful while the app flow is still being built. It does not create an App Store Connect product, confirm storefront details, or remove the need to validate the configured Apple product before release.

How should I attach a StoreKit configuration to the app?

Associate the file with a dedicated Xcode Scheme, then confirm that the Scheme is selected when you run the app. Align the configuration’s product identifiers with the identifiers used by your RevenueCat project and app code. Keep a separate release Scheme or configuration so a local testing setup is not mistaken for production purchase configuration.

Does a remote Simulator run prove release readiness?

It proves only the checks performed in that remote run. You can build and run supported Simulator workflows on a remote Mac, but local StoreKit behavior and Apple Sandbox behavior remain separate acceptance claims. Save the commit, Scheme, active configuration, tester context, and observed entitlement state so another developer can reproduce the same test.

Repeat the same test on a remote Mac

A remote Mac is useful when your development computer cannot run Xcode, when local disk or compute resources are constrained, or when you want the test environment separated from your daily machine. It does not remove the need to make the Scheme, simulator runtime, credentials, and product configuration explicit.

Use this run sequence:

1. Check out the same commit you tested locally, or record the exact revision used for the remote run.
2. Open the project in the intended Xcode environment and verify the active Scheme before building.
3. Confirm the StoreKit configuration and SDK key selected by that Scheme.
4. Launch the intended Simulator and perform the purchase scenario you are validating.
5. Capture the observed purchase result and entitlement state, then redact user and credential data from logs.
6. Repeat the run after changing environments, keys, or product mappings; do not carry a prior pass forward automatically.

The operational failure points are often outside the purchase code. A remote desktop session may not be attached to the expected GUI session; the selected Simulator may differ from the one in the previous run; or a shell build may use environment values that do not match the Xcode Scheme. Check the visible app state and the build inputs, not just the final process exit status.

For infrastructure decisions, separate the need for an interactive Xcode session from the need for an always-available build host. The trade-offs in bare-metal versus macOS virtualization can help you assess what kind of remote environment fits your test workflow. If you are comparing a dedicated local purchase with temporary access, the Mac mini cost guide provides a separate hardware-cost reference; do not assume a remote setup is automatically cheaper for continuous, long-term use.

Finish with Apple Sandbox before making a release claim

Use Apple Sandbox when you need to check the platform purchase chain with Apple’s test environment. Apple’s Sandbox testing overview describes the platform setup and its testing context. Follow the current Apple and RevenueCat instructions for the account, product, and build configuration used by your project.

Separate purchase-flow acceptance from metadata acceptance. A completed test purchase does not, by itself, confirm that product names, prices, or other storefront details are correct. Review those details against the configured platform product and the release target. Similarly, do not conclude that a Simulator run and a device run cover identical behavior; choose the test target based on the product requirements and the platform path you need to verify.

Before closing the test, record:

• Which environment you used: Test Store, local StoreKit configuration, or Apple Sandbox.
• Which app build, Scheme, and product identifier were involved.
• Which tester or app-user identity was active, with private details removed.
• Whether the purchase completed, was cancelled, or failed.
• Whether CustomerInfo and the expected entitlement matched the app’s access behavior.
• Which checks remain unverified and therefore cannot be included in the release claim.

A simple record prevents a common handoff problem: one developer reports “subscriptions passed,” while another cannot tell whether that meant Test Store, a local StoreKit run, or Apple Sandbox.

Choose local hardware or a remote Mac by how you test

A Mac you already own is usually the simplest option if it has the required Xcode setup, enough available resources, and access to the testing account. Buying a Mac can make sense when you need stable, frequent interactive testing over the long term or require local physical connections. Neither choice is automatically right for a short validation cycle.

A Test Store-only workflow is also not a replacement for a Mac-based Apple development setup: it leaves platform testing undone. A local Mac can be unavailable to teammates, consume storage and compute resources needed by other work, and require you to maintain the test environment yourself. A remote Mac can separate the build and Simulator workload, but it still needs deliberate credential isolation and a reproducible Scheme.

If you need Xcode and Simulator access temporarily, or want to keep subscription testing separate from your everyday machine, compare the available remote Mac options against the tests you must run. Check that the chosen setup supports your intended Xcode workflow before moving credentials or relying on it for acceptance. For a sustained, heavy workload or a test that requires a physical connection your remote setup cannot provide, local hardware may be the better fit.

Decision: Test Store for app logic, local StoreKit configuration for controlled Xcode testing, and Apple Sandbox for platform verification. Use a remote Mac to reproduce the Xcode stages when local capacity is the constraint—but keep each pass scoped to the environment that produced it.