We received the same email today. Ideas/suspicions: If you use RevenueCat, you know that they had a major two hour long outage on Friday February 10th. Any customers who made purchases during that period were unable to unlock content after paying. The issue was resolved, but any affected customers will need to manually Restore Purchases. Perhaps Apple's systems detected this as a form of "payment fraud". A nefarious competitor is attempting sabotage your apps by buying fake reviews. Would be easy to detect if you notice an unusually high amount of new reviews for your apps. If so, disclose this to Apple immediately. An unusual spike in downloads may have triggered this. Other: We investigated the email headers, and it looks like a legitimate email from Apple. But we can't be certain it's not phising, so do not share any sensitive information. Besides the "Please address this issue promptly", there isn't much of a call to action. We reviewed our apps, analytics, reviews, etc and responded with our findings to show everything is in order. I'm not sure what going to happen next, but others have said Apple attempts to schedule a phone call to discuss the matter further. In any case, I will update this thread as new information comes in. Please share updates here as well. Thank you

We still have not received a response to the email we sent. Is there any improvement in your situation? Nothing on our side either.

Update We finally received a response. They thanked us for taking a look and reporting our findings (we found no unusual data). They also said to continue monitoring our apps and report any abnormal data in the future quickly via "Sign in to App Store Connect account > Contact Us > Report a Concern > Report a Fraud Concern". One last note I'll add is that they reiterated that manipulation of user reviews is against the PLA. I imagine this is what triggered the email for us, but I'm not sure why as we didn't find any abnormal rate of reviews. Anyhow, I recommend forwarding all App Store reviews to Slack/Telegram and keeping an eye on them.

For anyone using IGListKit: The issue is exactly as stated: a cell or supplementaryView is being dequeued more than once which results in a crash on iOS 18. I found the issue in one of our ListSectionController objects. final class MySectionController: ListSectionController { // ... override func cellForItem(at index: Int) -> UICollectionViewCell { guard let cell = collectionContext?.dequeueReusableCell(of: MyCell.self, for: self, at: index) as? MyCell else { return UICollectionViewCell() } // ... return cell } } // ... elsewhere: let sourceView = cellForItem(at: 0) That last line mistakenly calls cellForItem on the section controller instead of the collectionContext. To fix: let sourceView = collectionContext?.cellForItem(at: 0, sectionController: self)

This is an old thread, but updating for anybody who comes across it. This is a bug in PHPhotoLibrary. In our app, a small subset of users' devices saw success in PHPhotoLibrary.performChanges but the operation did not work (zero assets were saved). We could not reproduce it no matter what we tried. Finally, we did manage to reproduce by changing the Photo Library Access setting. Our test devices' Photo Library permission was "Add Only" (default requirement in our app). Changing the permission to "Limited Access" did the trick. We reproduced the same result (iOS 18.5): let urls = [URL]() // empty array to trigger error PHPhotoLibrary.shared().performChanges({ for url in urls { let req = PHAssetCreationRequest.forAsset() req.addResource(with: .photo, fileURL: url, options: nil) } }) { success, error in print(success) // true } When "Add Only" is selected, success is false. I've filed a bug report with Apple.