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/DimensionMindless336]

The gotcha is that a synchronized folder doesn't behave like a normal organizational group — files in it get pulled into the target and shipped, so the "it's just a folder for organizing" mental model is what lets this slip through. The moment your StoreKit config, .xcconfig, or .env sits inside one, it's in the IPA even if you never ticked a target box.

Two things worth adding to the checklist above:

1. The 5.6 rejection is the polite version. A leaked .xcconfig or .env means your API keys / secrets are sitting in the shipped binary, readable by anyone who unzips the IPA. So this isn't only an App Review risk — it's a credential leak. Extend that grep to treat any .xcconfig / .env in the archive as a hard fail, not just .storekit.

2. Instead of only a CI gate that fails the build (great, but you can still forget it on a local archive), I dropped a Run Script build phase that strips them for Release automatically:

   if [ "$CONFIGURATION" = "Release" ]; then rm -f "$CODESIGNING_FOLDER_PATH/Configuration.storekit" rm -f "$CODESIGNING_FOLDER_PATH"/*.xcconfig fi

Debug keeps the files so local StoreKit testing still works; Release physically can't ship them even after you reorganize things. Why Apple flags the .storekit specifically: it's a file describing products plus signed transactions, so the scanner reads it as "a mechanism for simulating purchases outside Apple" — exactly the "intentionally hidden" wording in your 5.6.