A sandbox tester is a fake Apple Account you make yourself, and time runs faster inside it.

What is a sandbox tester account, exactly?

It is an Apple Account that only exists inside your developer account. You give it a name, an email address, a password and a storefront, and that is the whole account. Apple is blunt about the limits: these accounts are valid for testing only and cannot be used to sign in to or make purchases on the App Store. So the thing you just created looks like a customer to your code and looks like nothing at all to the actual store.

The scope is narrower than most people assume. Apple's StoreKit article, Testing Apple In-App Purchases with sandbox, carries an Important note saying a Sandbox Apple Account only works for testing in-app purchases in apps that belong to the same Apple Developer Program account you used to create it, and telling you not to use one in another developer's app. If you are testing a client app, the tester has to be made inside the client's account. Your own will not work, and the failure looks like a product request returning nothing.

The ceiling is 10,000 accounts, which Apple states on its own help page and which nobody reaches. The real limit is email addresses, because the address has to be one that has never been registered as an Apple Account and has never bought iTunes or App Store content. Apple offers a way around that in the same breath. If your mail provider supports plus addressing, you can hang subaddresses off one real inbox, and Apple's own example is billjames2 plus UK, billjames2 plus US and billjames2 plus JP at icloud.com. Mail to all three lands in the base inbox. One address, one tester per storefront.

There is also a sibling concept worth not confusing it with. StoreKit Testing in Xcode is a local environment that needs no connection to App Store servers at all, and Apple suggests it for testing before you have configured products in App Store Connect or when you have no network. The sandbox is the opposite trade: real product data, real App Store Server Notifications, the App Store Server API on its sandbox URLs, and a round trip to Apple every time.

Apple, App Store Connect Help, Create a Sandbox Apple Account, read 21 October 2026

How does Apple document creating one?

The path is short. Select Users and Access at the top of the page, click Sandbox in the top navigation, then click the add button. The first time, that button reads Create Test Accounts instead. Enter a first and last name, an email address, a password, and an App Store country or region, then click Create. Apple notes that sandbox accounts need strong passwords in the same way standard accounts do, and that recommendations appear if yours falls short. You need to be the Account Holder, an Admin, an App Manager or a Developer.

One line in the middle of that list is the one to slow down for. Apple says that once you create a tester, you cannot edit the name, the email or the password. Not renamed later, not corrected. A typo in the email address means a dead account and a burnt address, and the address is burnt properly: Apple states that a deleted sandbox tester's account and email can no longer be used as an App Store Connect user, to test in the sandbox environment, or to make purchases on the iTunes Store or App Store. Pick the address with more care than the password.

The storefront choice is the one you can take back. Each account is associated with one of the 175 App Store storefronts, and Apple says you can edit a tester's country or region at any time to test another storefront with the same account, rather than creating a new tester. The catch is on the device: after you change it, the tester has to sign out and sign back in before the new storefront takes effect. The same account can therefore walk through several currencies in an afternoon, which is the only sane way to check that your prices and your tax category behave.

Four things have to exist before any of this works, and Apple lists them as prerequisites rather than steps. An active Apple Developer Program membership. A Paid Applications Agreement signed by your Account Holder. Product information set up in App Store Connect, with at minimum a reference name, a product ID, a localized name and a price. And Developer Mode enabled on each test device. Miss the agreement and your products will not come back from a product request, which reads as a code bug for about a day.

Signing in differs by build type, and Apple separates the two. For a development-signed app on iOS or iPadOS, the sandbox account appears under Settings, Developer after the first time you attempt a purchase on that device, and you do not have to sign out of your own Apple Account. When you sign in, the text about the environment being Sandbox appears, which Apple describes as the confirmation that you are connected to the test environment. If that text is missing, you are in production. On macOS the account appears in App Store Settings after your first purchase attempt instead.

How is subscription timing different in the sandbox?

Subscriptions renew at an accelerated rate, and the rate is a setting on each tester rather than a fixed property of the environment. Apple's documented default is a speed equalization of one month to five minutes. The full default row, as published on App Store Connect Help and read on 21 October 2026: one week renews after three minutes, one month after five, two months after ten, three months after fifteen, six months after thirty, and one year after one hour.

That table is the one everybody repeats, and the documentation agrees with it. Worth saying plainly, because the usual outcome of checking a number like this is that it moved. What the repeated version leaves out is that it is one of four options. App Store Connect offers renewal every three minutes, every five minutes as the default, every thirty minutes, and every hour, and the slower settings stretch everything with them. On the hourly setting a monthly subscription takes an hour and a yearly one takes twelve.

The renewal rate also decides two things that have nothing to do with renewals. Apple states that the subscription renewal rate determines the length of Billing Retry and the Billing Grace Period for that tester. On the default setting, Billing Retry runs for ten minutes at every duration, and the Billing Grace Period is three minutes for a weekly subscription and five minutes for everything longer. Move the tester to the hourly setting and a monthly subscription's grace period becomes two hours. If you are testing what your app shows a customer whose card has failed, that is the dial you are actually turning.

Renewals stop. Apple documents that a sandbox subscription automatically renews up to 12 times, and that auto-renewal turns off on the thirteenth renewal attempt. On the default five minute speed, a monthly product gives you a full lifecycle in about an hour, then lapses for good. To run the same test again you clear the account's purchase history, which Apple says deletes every past sandbox purchase for that tester, cannot be reversed, and leaves the account eligible for introductory offers once more. Sign out and back in afterwards, because the device keeps a cached copy.

One behaviour here looks like a defect and is not. Apple warns that the accelerated expiration and renewal rates make it possible for a subscription to expire before the system tries to renew it, which leaves a short lapse in the subscription period. Apple then says those lapses are possible in production, and to verify that your app handles them. So a subscriber who briefly reads as expired is a scenario to handle rather than a sandbox artefact. The step-by-step pass through each purchase type sits in the in app purchase sandbox testing walkthrough.

Apple, App Store Connect Help, Manage Sandbox Apple Account settings, read 21 October 2026

Why does a TestFlight build need extra steps?

Because a TestFlight build is already in the sandbox and still ignores your sandbox tester. Apple's StoreKit article states that apps downloaded from TestFlight always run in the sandbox environment, then adds the part that catches people: to reach the sandbox controls you have to sign out of your production Apple Account in Media and Purchases and sign in with a Sandbox Apple Account under Developer settings. Until you do, purchases get attributed to your own account and the renewal rate and purchase history controls are not there.

Apple's six steps, in order. Download the beta from TestFlight, which needs a production Apple Account. Open Settings and select your Apple Account. Select Media and Purchases. Choose Sign Out from the pop-up menu. Open Settings again and select Developer, which only appears once Developer Mode is on. Scroll to the bottom and select Sign In under Sandbox Apple Account. Sign back in to Media and Purchases later and TestFlight purchases go back to being attributed to your own account.

Read the warning Apple attaches to step four before you do it on your own phone. Signing out of Media and Purchases can remove your access to purchased content in production apps on that device, and Apple suggests a dedicated testing device for exactly this. On a personal phone that means your music, your books and anything else bought with that account going quiet for the length of the test session. It comes back when you sign in again. It is still a bad hour to be on call.

One more delay is documented and saves a lot of staring. Apple notes that changes you make to product metadata in App Store Connect can take up to one hour to appear in the sandbox environment. A price edit or a new product that has not shown up yet is usually that, rather than anything you wrote. The same article lists which sandbox settings live where: creating and deleting accounts, test families and storefront changes are App Store Connect only, while the renewal rate, interrupted purchases and clearing purchase history can be done from either side. Win-back offer sheets are the one setting that exists only on the device.

The Android half of this job is arranged differently, and knowing that stops you looking for a sandbox that does not exist. Google handles test purchases through license testers and a release track rather than through fake accounts, so the mechanics of google play closed testing are where the equivalent work happens.

What does a passing sandbox test not prove?

That anyone will pay. The sandbox proves the plumbing: a product request returns your products, a purchase completes, a receipt validates, your server gets the notification, a renewal arrives and a lapse is handled. All of that is worth having before you charge a stranger. None of it is evidence about price, about the words on your paywall, or about whether the offer makes sense. Clearing the purchase history even restores introductory offer eligibility, so the test is endlessly repeatable in a way a real customer never is.

It also will not catch the failure modes that only exist in production. Real cards get declined for reasons Apple cannot simulate, which is why the interrupted purchase setting exists at all. Apple lets you force that path with a per-tester checkbox, and describes an interrupted purchase as one where the customer has to do something outside your app first, such as agreeing to updated terms or replacing an expired payment method. Turn it on, see what your app shows, turn it off. Apple notes the interruption keeps happening until you deselect it or the tester agrees to the terms on the device.

Family Sharing is the other thing worth testing here rather than discovering later. App Store Connect lets you build a Sandbox Test Family, with an organizer and up to five members, once you have at least two sandbox accounts. Every member has to be in the same country or region as the organizer, and an account can only belong to one test family. If a shareable subscription is part of your offer, this is the only way to see a shared entitlement arrive in your code before a real family does it.

For the question the sandbox cannot answer, you need live traffic and a control group. On the Apple side that means a price change and patience. On the Android side there is a built-in tool for it, and play store listing experiments is where you test the pitch rather than the payment. Keep the two kinds of testing separate in your head. One tells you the code works. The other tells you the offer does.