“missing package product”

Hello, Additional information: the same subscription works correctly with StoreKit local testing in Xcode (StoreKit configuration file). The product is returned and the purchase flow behaves as expected. The issue only occurs in the App Store sandbox via TestFlight, where the same product ID returns an empty array. This suggests the implementation is correct and the issue may be related to App Store Connect or sandbox availability. Thank you.

Hello, Thanks for your response and for pointing me to TN3186. I have carefully followed the troubleshooting steps, but the issue still persists. Below is a detailed summary of the current situation. Configuration status: The auto-renewable subscription is fully created in App Store Connect Product ID: sylvoy_sylvoy_premium_v2_monthly Status: “Ready to Submit” Pricing is configured and available across regions The subscription is correctly added to the app version under “In-App Purchases and Subscriptions” StoreKit is properly implemented and getSubscriptions is called with the correct product ID Testing performed: Tested on a physical device (not simulator) Logged in with a Sandbox Apple ID Logged out and re-authenticated the App Store account Reinstalled the app multiple times Waited for propagation delays (over 24 hours) Verified that no StoreKit errors are returned (only an empty product array) Confirmed that bundle ID and product ID match exactly Current behavior: getS

Still have the issue in Xcode 26.4 Release Candidate (17E192). Ignore the package.resolved is not a solution because many people works in the project and we need to work under the same versions and, if one package version changes the team only change that package thanks to the cloud, so we cannot play to what versión cloud will download

OK by this: I tried deleting iOS 18 runtime via Xcode Settings > Components, and even removed iOS 26 runtime then re-downloaded it. But the iOS 18 runtime keeps auto-reappearing right after! I also ran sudo rm -rf against the iOS 18 asset folder, and it just throws a permission error—totally useless. I checked the Info.plist under /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/cc1f035290d244fca4f74d9d243fcd02d2876c27.asset/ and confirmed this folder is exactly the orphaned iOS 18.0 simulator runtime. I’m trying to delete this specific cc1f035290d244fca4f74d9d243fcd02d2876c27.asset folder but hit a wall with system permissions. I found this exact issue is already being discussed in the Apple Developer Forum thread here: Orphaned 9GB Simulator Runtime in /System/Library/AssetsV2 - Cannot Delete (SIP protected). It’s clearly a bug on Apple’s side with MobileAsset lifecycle management—these large orphaned simulator runtime assets get stuck in SIP-protected system directories, and Xcode/simc

My main concern is the lack of visibility. Since appeals to the Board do not appear in the Resolution Center UI, I have no way of knowing if my ticket is actually actively open, in a queue, or if it has been lost due to a system glitch. If you go back to the Contact Us screen, don't you see the ticket numbers for unsolved cases? This way of handling pending cases seems reasonable to me for an annual membership fee of $99.

So it appears to be the same failure we are talking about here: https://developer.apple.com/forums/thread/814076 I just updated that thread, but the bug described there (FB21805212) was fixed in macOS 26.4. Also, to be clear, the bug was specifically in smb, NOT copyfile itself. However... It has data. I can read the filenames when I view it as 'plain text’. The Resource fork is less than 300 bytes, but that is enough for it to cause copyfile to fail. The total file size is ~12kb. That doesn't sound like the bug above. The bug above was caused by the SMBClient incorrectly accounting for large xattr size, which then caused the copy to fail. I don't think it would have happened with small xattrs (certainly not 300 bytes). FYI, the Finder (and other copy engines) work because they're using the ..namedfork accessor, when it ends up going through a totally different code path in smb. Interestingly, .DS_Store causing problems with copying is infamous enough to have a mention on Wikipedia: Yes, but I think that's pr

I decided to just skip it and try the about me app lesson. I think it goes over a lot of the same concepts. I wasn't very lost even though I skipped it. Good luck!