TL;DR

A StoreKit test purchase on a physical device can succeed and verify while Transaction.currentEntitlements comes back empty right after. First find out whether StoreKit returned nothing or your code dropped the result: count every result before you verify it. If the count is zero, delete the app from the device, reinstall it from Xcode and buy again. In the one case tested here, on one iPhone, that cleared it.

for await result in Transaction.currentEntitlements {
    entitlementCount += 1
    guard let transaction = try? checkVerified(result) else {
        continue
    }
    // ...
}
// The app's log line also prints the Pro state after this count.
print("StoreManager: Entitlements refreshed - \(entitlementCount) from StoreKit")

I hit this while preparing a release of a small iPhone app I’m building, which sells one non-consumable Pro upgrade. The purchase sheet said “You’re all set”, and the app stayed locked. This page covers how I separated StoreKit from my own code, what turned out not to matter, and the reinstall that fixed it.

Purchase succeeds, but the upgrade stays locked

On a physical iPhone launched from Xcode with a StoreKit configuration file, the symptoms, in the order they appear:

1. The purchase sheet said “You’re all set”, and the app logged a verified, unrevoked transaction.
2. The entitlement refresh straight after it found nothing.
3. Xcode’s transaction manager, under Debug > StoreKit > Manage Transactions, listed the purchase.
4. Restore Purchases reported no previous purchases.
5. Buying again failed with ASDServerErrorDomain 2010.

The two log lines from steps 1 and 2:

StoreManager: Purchase verified - <product-id>, revoked: false
StoreManager: Entitlements refreshed - 0 from StoreKit, Pro: false

I don’t know what ASDServerErrorDomain 2010 means. I couldn’t find it in Apple’s documentation, so treat it as a symptom here, not a diagnosis.

Count entitlements before you verify them

An empty entitlement list can come from two places: StoreKit emitted nothing, or your code discarded what it emitted. A loop that only counts the transactions it keeps can’t tell those apart. A failed verification, a revocation check or a product ID filter all look the same as an empty sequence.

Count each result as it arrives, before any check, as in the code in the answer. In that code, checkVerified is the app’s own verification helper, not a StoreKit API. If that count is zero, the sequence itself was empty and your filtering isn’t the cause. Mine was zero.

The product type matters too, because currentEntitlements doesn’t include every product type. Apple’s currentEntitlements reference (opens in a new tab) says it emits “a transaction for each non-consumable Apple In-App Purchase” and leaves out consumables and refunded or revoked products. Check the product’s type in the .storekit file. Mine was NonConsumable, so it should have appeared.

Placeholder team ID wasn’t the cause

The .storekit file was an older one, written by hand. Its _developerTeamID was the placeholder YOUR_TEAM_ID, and its product and app IDs didn’t match App Store Connect. Sync with App Store Connect failed with “Could not sign in”, even though Xcode was signed in to an Admin account.

That looked like the cause, and fixing it was still worth doing. Apple’s StoreKit testing setup guide (opens in a new tab) has you pick the team and app when you create a synced configuration file. To sync a converted file again, it says to create a new synced file. I replaced the hand-written file with a new synced one. It wasn’t enough on its own. A purchase made after the swap still left the entitlement count at zero.

Entitlement count by environment

Each run used the same build of the app:

The Simulator result alone didn’t separate the device from the OS version, because the Simulator ran an older iOS. The sandbox row answers a narrower question. On iOS 27, against the App Store sandbox, a fresh install logged Entitlements refreshed - 1 from StoreKit, Pro: true. Because that install was fresh too, it doesn’t show whether the sandbox would have returned the entitlement on the install that returned zero. It shows only that a sandbox purchase unlocks on a clean install, in one run.

Delete the app and test again

The last row of the table is the fix. On the one iPhone and iOS build tested, the empty result behaved like test state stored on the device: it survived replacing the configuration file, and deleting the app cleared it. I captured only the before and after, so what that state was, what put it there, and why replacing the file didn’t reset it are unknown.

To clear it:

1. On the iPhone, delete the app.
2. In Xcode, run the scheme that has the StoreKit configuration selected.
3. In the app, tap Restore Purchases before buying anything. With nothing bought, it reports no previous purchases.
4. Buy the product again.

Check the console. A purchase that unlocks logs a verified transaction followed by a count of one:

StoreManager: Purchase verified - <product-id>, revoked: false
StoreManager: Entitlements refreshed - 1 from StoreKit, Pro: true

Resets that don’t reach the device

xcrun simctl erase all erases every simulator. It doesn’t touch a physical device. For a device, Apple’s guide to testing in-app purchases in Xcode (opens in a new tab) resets a test by deleting the transaction under Debug > StoreKit > Manage Transactions. Whether that reset clears the same state isn’t recorded here; deleting the app is what cleared it.

TL;DR

Xcode keeps simulator devices, simulator runtimes and DeviceSupport (debug symbols copied from your physical devices) in three separate places, and one du total hides which is big. Measure each on its own. Skip du on /Library/Developer/CoreSimulator/Volumes: it walks into the mounted runtime images and reports their unpacked contents, not the disk they use.

Delete only what no test target or connected device uses:

• A simulator device: xcrun simctl delete <UDID>.
• A simulator runtime: xcrun simctl runtime delete, with --dry-run first.
• A DeviceSupport folder: move it to the Trash.

Compare Container Free Space before and after. A deleted runtime can leave the list and still hold its space, so reread later.

$ du -sh ~/Library/Developer/CoreSimulator/Devices
$ xcrun simctl runtime list
$ du -sh /System/Library/AssetsV2/com_apple_MobileAsset_*SimulatorRuntime
$ du -sh ~/Library/Developer/Xcode/*DeviceSupport
$ diskutil info / | grep "Container Free Space"

A du of the home folder, as in What’s Taking Up All the Space on My Developer Mac?, shows two of Xcode’s three places. The third, simulator runtimes, lives outside the home folder. To get a real before-and-after without touching anything I use, I installed a watchOS 27.0 runtime for this page and removed it again. This is part of a series on cleaning up a developer Mac’s disk, and each part stands alone.

Check how much space simulators and DeviceSupport use

Xcode keeps simulator devices, simulator runtimes and DeviceSupport in three places, and each holds something different:

Record the free space first, so you can check the result later:

$ diskutil info / | grep "Container Free Space"

Then measure the folders. These commands only read:

$ du -sh ~/Library/Developer/CoreSimulator/Devices
$ du -sh ~/Library/Developer/Xcode/*DeviceSupport
$ du -sh ~/Library/Developer/Xcode/DerivedData ~/Library/Developer/Xcode/Archives

du -h and simctl print binary units, so every G they print on this page is GiB; diskutil prints decimal GB. On my Mac, devices were 44 GiB, iOS DeviceSupport 35 GiB and tvOS DeviceSupport 6.6 GiB. DerivedData was 0B and Archives 10M, so those weren’t the problem here; check yours, because on a Mac that builds a lot they can be. The runtimes totaled 22.3G by simctl’s count, which the next section shows how to read. Devices, both DeviceSupport folders and runtimes came to about 108 GiB.

Find where simulator runtimes live and size them

Runtimes are disk images, and macOS mounts them read-only. List them:

$ xcrun simctl runtime list

== Disk Images ==
-- iOS --
iOS 27.0 (24A434) - <runtime-id> (Ready)
iOS 26.5 (23F77) - <runtime-id> (Ready)
-- tvOS --
tvOS 27.0 (24J360) - <runtime-id> (Ready)
tvOS 26.5 (23L470) - <runtime-id> (Ready)

Total Disk Images: 4 (22.3G)

Run it again with -v for each image’s details. The -v output adds a Last Used At line per image. It also gives an Image Path under /System/Library/AssetsV2/com_apple_MobileAsset_*SimulatorRuntime/ and a Mount Path: under /Library/Developer/CoreSimulator/Volumes/ for the iOS and tvOS images here, and under /private/var/run/com.apple.security.cryptexd/mnt/ for the watchOS one. The image path is where the bytes are, so size the runtime images there:

$ du -sh /System/Library/AssetsV2/com_apple_MobileAsset_*SimulatorRuntime

Here that printed 15G for the iOS runtime images and 6.9G for the tvOS ones. These figures are rounded and come from a different tool than the 22.3G total above. Because the images live outside your home folder, a du of ~ never counts them.

Do not run du on a mount path. du -sh /Library/Developer/CoreSimulator/Volumes printed 48G on this Mac, but that isn’t disk use. du walks into each mounted image and counts its unpacked contents, which are already counted in the runtime images. Adding it to the totals counts the runtimes twice, and then some.

Delete simulator devices you no longer use

List the devices, grouped by runtime:

$ xcrun simctl list devices

I had 27: 11 each on iOS 26.5 and iOS 27.0, 3 on tvOS 26.5 and 2 on tvOS 27.0. A device is worth keeping if you run a test or a preview on it. To see which ones are large, size each device folder; the folder name is the device’s UDID, which the list prints in parentheses:

$ du -sh ~/Library/Developer/CoreSimulator/Devices/* | sort -hr | head

By runtime, the iOS 26.5 devices took 19.9 GiB, iOS 27.0 19.1 GiB, tvOS 26.5 3.6 GiB and tvOS 27.0 1.3 GiB. The largest single device was 5.0 GiB. For scale, one watchOS device I booted for about 80 seconds grew from 8 KiB to 546 MiB. If you no longer test on a runtime, its devices are the candidates, and so is the runtime itself.

Deleting a device removes its installed apps and data. Two commands delete devices. xcrun simctl delete <UDID> removes the devices you name. Use the UDID, not the name, because the same device name appears under every runtime. There’s no undo, so copy out any test data you want first. xcrun simctl delete unavailable removes devices that the current Xcode SDK doesn’t support, according to xcrun simctl help delete. Check what it would remove before you run it:

$ xcrun simctl list devices unavailable

== Devices ==
-- iOS 26.5 --
-- iOS 27.0 --
-- tvOS 26.5 --
-- tvOS 27.0 --

If every group is empty, as here, delete unavailable removes nothing.

Delete simulator runtimes you no longer use

A runtime is in use if a test target needs that OS version or a device you keep still runs on it. Last Used At in xcrun simctl runtime list -v shows when each image was last used.

xcrun simctl runtime delete removes one. It takes an identifier from the list, or a filter: --notUsedSinceDays <days>, --unusable or --outdated. Add --dry-run and it prints what it would delete and deletes nothing:

$ xcrun simctl runtime delete --notUsedSinceDays 90 --dry-run

When the dry run lists what you expect, run the same command without --dry-run, or pass an identifier from xcrun simctl runtime list to remove a single image. Read the whole dry-run list first: a filter can match several runtimes, and each one is a multi-GB download if you need that OS version again. xcrun simctl help runtime says the delete shuts down any booted simulators and unmounts the image first. In my run, a tvOS simulator booted on a different runtime stayed booted, so I can’t say which ones it stops. Shut down any simulator holding state you care about first.

$ xcrun simctl runtime delete <identifier>

Use this command, not rm. The images are mounted and managed by the system, so they aren’t folders to remove by hand. To get a runtime back, run xcodebuild -downloadPlatform <iOS|watchOS|tvOS|visionOS>, as in Apple’s Installing additional simulator runtimes (opens in a new tab).

Why a deleted simulator runtime can keep its disk space

A runtime can leave xcrun simctl runtime list while its image stays mounted and keeps its space. Do not read the runtime list as proof you got the space back. Check that the image has left mount and that Container Free Space has risen, and if it hasn’t, reread it later and after a restart.

The watchOS 27.0 runtime I installed for this page was a 3.83 GB download; xcrun simctl runtime list -v sized it at 3.6G (GiB), and it cut Container Free Space from 83.9 GB to 80.1 GB. After a dry run that named only that runtime, xcrun simctl runtime delete <identifier> took it off the list within five minutes, but Container Free Space didn’t rise by those 3.8 GB in the next 21 minutes. The backing folder under /System/Library/AssetsV2 still measured 3,736,360 KiB (3.56 GiB), and the image was still in mount, held by a SimLaunchHost.arm64 process that had a library from it mapped. xcrun simctl shutdown all didn’t release it. Stopping that process left nothing holding the image, but the image stayed mounted and the space stayed in use for the nine minutes I watched. I didn’t test a restart, unmounting the image or restarting the CoreSimulator service, so I can’t say what finally frees it.

Delete DeviceSupport folders you no longer need

DeviceSupport holds debug symbols copied from physical devices you connected. Each folder is named for the device model, the OS version and the build, and there’s one per combination. My iOS DeviceSupport had six folders, at 5.4G to 6.6G each, and tvOS DeviceSupport had two, at 3.4G and 3.2G.

$ ls ~/Library/Developer/Xcode/iOS\ DeviceSupport

<model> 26.6 (<build>)
<model> 27.0 (<build>)

A folder is needed while a connected device still runs that OS version, or while you still read crash reports from that version. Xcode uses these symbols to name the system framework frames in a report, and Apple’s crash report documentation (opens in a new tab) says to download the device symbols for the report’s OS version if it can’t. List your connected and paired devices from the terminal, then check each one’s OS version on the device itself:

$ xcrun devicectl list devices

Any folder for a version no device runs now, and that no crash report you still read comes from, is a candidate. If every device you connect is on 27, that’s the five iOS 26.x folders (28.1 GiB) and both tvOS 26.6 folders (6.6 GiB). I kept all of mine, because I still need 26.x.

simctl doesn’t manage these; they’re plain folders. Move the one you chose to the Trash in Finder, which leaves you an undo, and empty the Trash after you confirm Xcode still works. Once it’s gone, a crash report from a device you no longer have can’t be symbolicated from it. I haven’t tested what Xcode does the next time you connect a device whose folder you removed, so remove one and check before you clear several.

Check how much space you got back

Run the same command you started with:

$ diskutil info / | grep "Container Free Space"

Mine read 83.9 GB before the watchOS run. Other work on the Mac moves this figure by up to about 1 GB with no action of yours, so a change under that is noise. Reread after a restart if a runtime delete hasn’t returned its space. Do not expect the change to match the du totals. Only the container’s figure says what the Mac got back.

Do this with a coding agent

Paste this prompt into your own local coding agent. It measures and recommends, and it removes nothing until you say what to remove:

Measure Xcode's disk use on this Mac. Report only; delete nothing until I
name what to remove.

1. Run diskutil info / and record Container Free Space.
2. Measure three places separately: simulator devices
   (~/Library/Developer/CoreSimulator/Devices), simulator runtimes, and
   DeviceSupport (~/Library/Developer/Xcode/*DeviceSupport). For runtimes,
   use xcrun simctl runtime list -v and measure each runtime image
   under /System/Library/AssetsV2. Do not run du on
   /Library/Developer/CoreSimulator/Volumes; it walks into the mounted
   images and overstates the size.
3. For devices, list them with xcrun simctl list devices, group them by
   runtime and report the size of each group. Also run
   xcrun simctl list devices unavailable.
4. List my connected devices (xcrun devicectl list devices) and ask me for
   the OS version of each; do not infer it. Also report which OS versions my test targets and deployment targets
   need, from the projects I name or from the project files you can find.
5. Recommend removal candidates with a reason for each: devices and runtimes
   no target uses, and DeviceSupport folders for OS versions no connected
   device runs. Ask me whether I still read crash reports from those
   versions, because Xcode needs the folder to symbolicate them. For devices and runtimes, give the simctl command (xcrun
   simctl delete <UDID>, or xcrun simctl runtime delete <identifier> after
   the same command with --dry-run). For DeviceSupport folders, name the
   folder; there is no Apple removal command, and Xcode's behaviour when
   that device reconnects is untested, so propose one folder first. Warn me
   that deleting a device removes its apps and data, and that runtime
   deletion can shut down booted simulators.
6. After a runtime deletion, expect the space to come back late or not
   until a restart: reread Container Free Space more than once, and check
   whether the image is still mounted (mount | grep -i <platform>).
7. Note that a du total is not what deleting frees; only the change in
   Container Free Space is.

Then stop and wait. After I name what to remove, run only those removals,
one at a time, with --dry-run first for runtimes, and stop if any output is
not what you expected. Then read Container Free Space again and report the
difference.

Common failures

du reports the CoreSimulator/Volumes folder as larger than the runtimes

du followed the mounts into the runtime images and counted their contents. Measure the runtime images under /System/Library/AssetsV2 instead, as in the section on where simulator runtimes live.

Runtime deleted but the space didn’t come back

xcrun simctl runtime list no longer shows the runtime, yet Container Free Space hasn’t risen and the folder under /System/Library/AssetsV2 is the same size. The image can stay mounted while a SimLaunchHost process has a file from it open. Check with mount | grep -i <platform> and lsof +D <mount path>. In my run, shutting down all simulators and stopping that process still didn’t free it, and I didn’t test a restart. See the section on why a deleted runtime can keep its disk space.