ETag cache folder created in Documents directory instead of Caches on macOS

[FelixLisczyk]

Describe the bug

Some of my users have reported a new folder appearing in their Documents directory on macOS: <bundleID>.revenuecat.etags

This seems to be caused by PR #5917, which moved ETag storage from UserDefaults to file-based caching. The issue is that SynchronizedLargeItemCache uses createDocumentDirectoryIfNeeded instead of createCacheDirectoryIfNeeded, so the cache ends up in Documents rather than Library/Caches.

Two questions:

1. Is this folder safe for users to delete?
2. Should this be using the Caches directory instead?

Platform

macOS

SDK version

5.51.1

SDK integration method

Swift Package Manager

StoreKit version

StoreKit 2

OS version

macOS 26.2

Xcode version

26.2

Device and/or simulator

Device

Environment

Production

How widespread is the issue

All macOS users on 5.51.1 or later see this folder

[RCGitBot]

👀 We've just linked this issue to our internal tracker and notified the team. Thank you for reporting, we're checking this out!

[rickvdl]

Hi @FelixLisczyk, thanks for reporting, we'll look into this and get back to you shortly!

[rickvdl]

Hi @FelixLisczyk, we're working on a fix for this. Just to confirm, is your app sandboxed or non-sandboxed?

Regarding your questions:

1. Although it's safe to delete these files, they will be recreated by the SDK until we've released a new version of the SDK that changes this behavior. Also please not that this may increase loading times for things like offerings and paywalls temporarily.
2. This is most likely what we'll end up doing indeed.

I'll let you know as soon as we have an updated SDK version with a fix available. Thanks!

[FelixLisczyk]

Thanks for the update! My app is sandboxed, and the files are created in ~/Documents/<appName>/<bundleID>.revenuecat.etags.

[JayShortway]

Hi @FelixLisczyk, just a quick question: are you seeing this issue with the app linked in your GitHub bio? Thanks!

[FelixLisczyk]

Hi @FelixLisczyk, just a quick question: are you seeing this issue with the app linked in your GitHub bio? Thanks!

Yes, SnipNotes is my note-taking app for iOS, macOS, and Apple Watch. It's only available on the (Mac) App Store and uses the RevenueCat SDK for purchases.

[rickvdl]

Thanks for confirming @FelixLisczyk!

We're working on making sure these files are written to the appropriate cache directory instead. In the meantime I'd still like to understand how the files were created in ~/Documents.

We're currently using FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first in order to get the URL to the documents directory. But in our testing we have never seen this return ~/Documents for sandboxed macOS apps (always ~/Library/Containers/{bundle_id}/Data/Documents/ ) because of sandboxing.

Is your app requesting read/write permission to the ~/Documents folder in any way? Or alternatively, could it be that the files are stored in the Documents folder on iOS, and showing up on the mac through iCloud or when connected through Finder?

Thanks!

[FelixLisczyk]

Yes, I access the user's documents directory in my codebase. I think I could remove it since it's only used to check and clean up some files that were stored there incorrectly a long time ago.

I see two instances of RevenueCat-related files in my Documents folder:

• ~/Documents/SnipNotes which contains a de.lisczyk.felix.SnipNotes.revenuecat.etags subfolder and a RevenueCat subfolder. When I right-click on the folder, I see that the actual storage location is in ~/Library/Containers. I suppose Finder displays it in my Documents folder simply for convenience. I have a similar folder for OmniFocus.
• ~/Documents/de.lisczyk.felix.SnipNotes.revenuecat.etags. This folder is stored physically in ~/Documents.

[rickvdl]

Thanks for the additional details @FelixLisczyk, really helpful! Two more questions (if you don't mind). I'd be curious to know how you're writing to the user's documents directory, does that require user-interaction? And also it would be really helpful if you could try to see what this code returns when you're running your macOS app:

FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)

Some context: it's likely that a feature / functionality of your app gains access to ~/Documents, which causes the API above to return it to the SDK, but we have yet to find out how that's possible in a sandboxed macOS app (this is just for our understanding, like I said we're already working on moving it to the right caches folder).

Thanks again!

[FelixLisczyk]

I was using the documents directory to extract an archive file containing release notes for a dialog that appears on app launch. I quickly moved it to a temporary folder and added a cleanup step. This logic runs non-interactively on the first launch of a new update.

I think I've found the reason for the RevenueCat folder stored in my documents directory. I'm running my app locally in dev mode without the sandbox, which allows me to use features like hot reloading. This causes the app to write directly to my documents. When I run the App Store version, I only see the 'SnipNotes' folder in my documents directory, which is physically stored in ~/Library/Containers. That's also what my customers have reported.

When I run your code snippet with the sandbox enabled, I get the expected path: file:///Users/felix/Library/Containers/de.lisczyk.felix.SnipNotes/Data/Documents/

[rickvdl]

Thanks so much for the additional information @FelixLisczyk! That explains the difference 😁.

I'll let you know as soon as the fix is available.

Thanks again!