@DD21 Did you end up finding a solution? I'm using NSPersistentCloudKitContainer to have CloudKit + Core Data and I'm observing the same issue. I have saved ~6000K items in Core Data, which some of them have images. The local size for the sum of the images is around 76 MB, but if you check it on iPhone > Settings > Apple ID > iCloud > Manage Storage, it shows up as ~760 MB, which is the 10x increase in size that you reported a year ago. This seems to be a bug on the whatever's in charge of calculating the size for iCloud assets, because when I delete my app from my device and let it download all the information stored on iCloud again, it finishes the download extremely fast (I'm assuming because it's only downloading 76MB). If it were downloading 760MB, it would take much longer knowing my network connection speed. Now, if this bug actually affects user's iCloud quota (which it seems that it does), it is a large scale issue that might be impacting millions of users. Users might have much more iCloud storage space than they think because of this. cc // @eskimo

@exCore Yes, it did lag, even when running from the App Store. And you're right, the .filter { _ in true } is uneeded, I just left it there by mistake because my original code was using @FetchRequest to get the data from Core Data instead of in memory, and it's needed in that case. I haven't tried the .animation(nil, value: searchQuery), I will and I'll report back, thanks for the tip. What did work for me, in case that anyone is reading this, is actually putting an .id(searchQuery) on the List itself. That way, every time that the searchQuery changes, the List is thrown away and recreated to avoid the diffing process.

This is insane. I've been investigating this issue and I can reproduce it 100% of the time on my end. I have two methods in my code that I've added to debug this issue, one to calculate the size of the thumbnails and another one to delete them. Here are both of them: func allThumbnailsSize() -> String { let items = (try? self.container.viewContext.fetch(CDItem.fetchRequest())) ?? [] let size = items.reduce(0, { $0 + ($1.metadataThumbnail?.count ?? 0) }) let formatter = ByteCountFormatter() formatter.formattingContext = .middleOfSentence return formatter.string(fromByteCount: Int64(size)) } func deleteAllThumbnails() { let items = (try? self.container.viewContext.fetch(CDItem.fetchRequest())) ?? [] items.forEach { $0.metadataThumbnail = nil } self.saveIfNeeded() } And here's the property in the model: Here's a screenshot that clearly shows the problem, and how simply nullifying the property that is of type Binary Data in Core Data reduces the size ~10x on iCloud. Capture of the size in the settings of my app. The size is calculated using allThumbnailsSize() shown above. Capture of the size reported on iCloud for Abyss, my app. (Ignore the other Abyss record with 80.9MB, it's another iCloud Container for a migration) Capture of the size after tapping the Delete Thumbnails button. That button simply calls deleteAllThumbnails(). Capture of the size reported on iCloud for Abyss after a few minutes to let it sync. As shown on the images, the iCloud size is totally wrong. And it's not an issue on the iPhone only, checking the size on iCloud on my Mac, also reported 782.2 MB used. For apple folks, I've opened a feedback: FB9770168

I've been digging deeper on this issue because it's affecting my app, and the problem is clearly and issue calculating the size on iCloud. The information that I'm adding now it's already on the FB9770168, but I'm posting it anyway here so non-Apple employees can see the findings. Size reported on my app's settings by calling allThumbnailsSize() shown above. Size reported for iCloud Storage Size reported by iPhone Storage (from the 216.6 MB, you'd have to subtract ~100MB from another database that I have on the app.) iCloud size reported for the same app on my Mac: As you can see, even if the 216.6 MB were true (which they are not, explained above), the iCloud size it totally wrong. I even went a step further and decided to perform a test to see how much data was being downloaded from iCloud. What I did is delete the app from my device, reset the network statistics, let it download all the information from iCloud, and check the statistics again. As shown on the images, if the iCloud size was correct, the download of all my data should have consumed ~757.1 MB. What it actually consumed is just ~78 MB, which is basically the size of the images reported in my app's settings + metadata of the object (small strings + bools)

A few hours after posting this it got resolved itself. I did ask for an Expedited App Review, maybe there was something off on their end and whoever's in charge of expediting the reviews managed to fix it. Thanks to whoever did it!

I've been digging how to implement this manually and seems that AppDelegate.applicationShouldHandleReopen(_:hasVisibleWindows:) would've done the trick, but even if you implement the @NSApplicationDelegateAdaptor(AppDelegate.self) var appDelegate, that method is never called. Found another example of the same issue online: https://www.reddit.com/r/SwiftUI/comments/u5srtt/applicationshouldhandlereopen_is_not_called_in

I've found a hack since AppDelegate.applicationShouldHandleReopen(_:hasVisibleWindows:) is not called as explained in the comment above. Apparently AppDelegate.applicationWillBecomeActive(_:) is called when you click on the Dock app icon if the window is miniaturized, so inside that method simply add this and seems to be working as expected (macOS 12.4): func applicationWillBecomeActive(_ notification: Notification) {     (notification.object as? NSApplication)?.windows.first?.makeKeyAndOrderFront(self) }

Apparently this has been removed on purpose, which I don't understand why because I use it very often. https://developer.apple.com/documentation/xcode-release-notes/xcode-14-release-notes

I'm having the same issue in the work project, but on personal projects Xcode works fine (same machine). I'm sure that there's some configuration issue somewhere making this trip (we use Cocoapods with ~20 dependencies on the work project). I haven't been able to find exactly what's going on, any tips are much appreciated!

Same, would love to be able to do this!

I would love to be able to do this automatically!

Looks like the issue is happening after the build finishes and the artifacts need to be uploaded:

I saw on the Fastlane docs that they mention a daily 150 binary limit, but we're definitely very far from that → https://docs.fastlane.tools/actions/deliver/#limit Does anybody know if it's recently been lowered to ~20 or something like that?

After half a day working, we've seeing that this is intermittent. We've changed nothing and some builds succeed and some fail. Looks like a check on AppStoreConnect somehow is flaky, hopefully it'll be fixed soon. For now we're just re-triggering the builds that fail and they end up succeeding at some point.

This seems to have resolved itself.