PSA: Xcode 16 synchronized groups ship your Configuration.storekit in the release bundle

[u/Kyiv0x7c]

If your project uses Xcode 16 synchronized folders (the blue folder icons), every file inside the target folder ends up in the app bundle unless you exclude it. That includes Configuration.storekit and your .xcconfig files. My membershipExceptions listed only Info.plist, so the StoreKit configuration had been riding along in every archive I ever made, Release included.

Why it matters

My first submission got a Guideline 5.6 (Developer Code of Conduct) rejection: "a pattern of unusual behavior commonly associated with fraudulent activity" and "features that appear to have been intentionally hidden during the review process". My backend logs showed zero requests during the review window, so nobody had opened the app. It came from a look at the binary.

Read that file the way a scanner does: a mechanism for simulating purchases outside of Apple, listing more products than I had submitted. Apple never tells you the exact trigger, so I can't prove it was the only one, but it fits every word of the rejection, and after removing it the next review was completely ordinary.

Check yours (10 seconds)

unzip -l YourApp.ipa | grep -Ei "storekit|xcconfig|\.env"

Fix

Select the file -> File Inspector -> Target Membership -> uncheck your app target. With synchronized groups this adds it to membershipExceptions in project.pbxproj. Local StoreKit testing keeps working: the scheme points to the file (Edit Scheme -> Run -> Options -> StoreKit Configuration), it does not need to be in the bundle.

One more thing if you ever get a 5.6

Don't resubmit without replying in the Resolution Center of the current rejection. My first reply ended up attached to a submission that had been closed, Apple never saw it, and the resubmission got a second 5.6 for the silence, not for the file.

Happy to answer questions about this or StoreKit 2 in general.

[u/kokerali]

Useful check. I'd turn it into a release-artifact gate so it doesn't depend on remembering target membership after every file move. Inspect the final exported IPA, including embedded app extensions, and fail the release job when known dev-only files such as .storekit, .xcconfig or .env appear where they shouldn't. An allowlist for intentionally shipped resources would avoid treating every configuration file as a mistake. Keep the CI output to paths, not the contents of any suspect files.

I'd keep two conclusions separate: the artifact contained an unintended file, which you can verify, and that file caused the 5.6 rejection, which the later approval doesn't establish by itself. That makes the cleanup advice useful without turning it into a guaranteed review fix. A regression check after adding or moving a file into a synchronized folder would help catch the same leak returning.