Thank you for your response. The thread I saw about NSFetch being broken in iOS 18 was this one wherein you are the engineer that states that NSFetch is broken back in Sep/Nov 2024 time frame. No Bug Report # was referenced in that thread but perhaps this link will help you find it. This was the first thing I saw when I started researching what might be going on with my App: NSFetch Broken Discussion I don't think our issue is users disabling iCloud right before App launch, unless iOS 18 is somehow doing that during update to OS or App? I didn't think the container moved when you set cloudKitContainerOptions=nil. I thought the store stayed pretty much where it was on the device? But I would like to try your suggestion relative to downloading the store and seeing if data is in it but NSFetch Returns nothing. I am not clear on how to do that. How do we get the store and check if the "store has data" without doing an NSFetch? I was not able to find a way to do this and if the problem is with NSFetch then we are sort of in a Catch 22. Any thoughts or suggestions? I saw your other discussion a few days ago relative to giving users an In-App way to turn on/off Cloudkit. However, another Apple Engineer a while back (see link to forum thread below) stated it was ok to do this by setting cloudKitContainerOptions=nil and that it was relatively harmless?! Has something changed? Based on that forum discussion we implemented what you see in our code. So far it has proved harmless as far as we know and never have we seen any harmful results from it. Here is that thread: OK to diasble/enable iCloud Forum Discussion In past Apple recommended we ask permission to use iCloud. This was quite a few years back. Has this recommendation changed? Given all the users that lose their data because they do not turn it on and then delete the app without a backup and lose the data container, we are thinking to NOT ask and just always enable it. But there are a lot of issues with that. What do we do when the user disables it from iCloud Settings? Of for users that have a full iCloud, typically choked with pictures? Or for users that have a real issue with iCloud (a lot of those in Europe for some reason). But even if I disregarded all that I am not really sure how to transition to this, I guess we could just hide the switch and enable it for all but what happens when their iCloud is full.

Thanks for your response. I will have to see if I can get my hands on a container from a device having the issue and before they start messing with it by saving new data. Is there a way to get the container from a device NOT having Xcode or Development tools if they can connect to a Mac? The issue is definitely real for a small percentage of devices that are mostly overseas in Spain or Italy. Not sure why that is a factor but most are not in USA and not english speaking? I see from Firebase analytics that there are already over 10,000 user running the update on iOS 18 and having the latest build. We are getting a steady stream of 2 or 3 complaints a day. Many of whom DO NOT use iCloud which is also weird. A few using iCloud but most are NOT. Any thoughts on why that might be?

Ziqiao are you aware of any behavioral changes in iOS 18 that causes an NSPersistentCloudKitContainer to delete data? In past we were told it could be used in all cases with history on, even if user was not allowing cloudkit. This was true until iOS 18 it seems now if that initializes and user is not using iCloud would it delete data. I thought I was seeing people talking about that and that it does that for security. if That is true that is a huge damn change and which Apple should tell people about?!

Well something changed since we switched to iOS 18 SDK and it definitely did not work this way in earlier versions of iOS. At some point after iOS 15 SDK something changed and the "cleaning" process you mentioned is literally wiping users data and if it was never in iCloud in the first place it is totally gone now?! We have always used an NSPersistentCloudKitContainer since we first implemented it years back regardless of if the person enabled iCloud (in our App or not). This was based on statements Apple Engineers made in the past that you could always use NSPersistentCloudKitContainer since it was subclass of nspersistentcontainer and with History on but options set to nil for NOT ALLOWED. But now it seems that users running iOS 18 and who did not allow us to use iCloud (are getting data wiped). It is not clear if they are entirely logged out of iCloud or just have iCloud Drive off or what, but something is different in iOS 18. I really need a way to zero in on what is going on. This is one of those catch 22 situations where by the time we see the issue the data is gone and we do not know what transpired to delete it or if anything actually changed and instead it was some kid of change of behvaior change in iCloud.

This issue is still ongoing. Thus far we have not been able to figure out what is going on but have reduced complaints quite a bit by rolling back to minimum OS / Devkit of iOS 17. So it is some kind of bug or behavioral issue with iOS 18 SDK. We cannot find a pattern to it other than that most users are in Europe and are not using iCloud to backup. This means we are using the NSPersistentCloudKitContainer regardless of if users enable or do not enable iCloud usage. This might be the root so if anyone is aware of what might have changed in iOS 18 that would do this PLEASE let me know. We have also now default always enable iCloud usage without asking if we find an account present. They can turn it off (with big warnings) if they want but we no longer ask on launch. Also we will investigate not always using NSPersistentCloudKitContainer if iCloud is not used.

Thank you for your response. We figured out how to solve the issue and no longer need the UIDesignRequiresCompatibility flag. Our fix works for both macOS 26 and 15.6. It may help others to know that mainly the problem seems to relate to what I guess is an ambiguous layout for UIKit. We fixed it by simply ensuring that in every place where we saw layout issues on macOS 26 the controls in either the vertical or horizontal direction were tied at both ends to the container, so this broke: "H:|-[startLabel(40)]-[startDateTime]-[ephType]" and this fixed it: "H:|-[startLabel(40)]-[startDateTime]-[ephType]-|" Note that the control on the right is tied to the right edge of the container. It was working on earlier version of macOS because we sized the parent container to be wide enough. The same type of things solves the same issues in the vertical direction.

One additional point in some cases we also needed to set: myNSButton.imagePosition = .imageOnly In places where we used only a button without a label (because the buttons position made function obvious) if .imagePosition = .imageOnly was set to something other than .imageOnly, the button would disappear.

Same issue for me as well and my ability to test on a real device is totally blocked and has been actually since some time back in Nov.! Xcode 26.3 iOS 26.3.1 watchOS 26.3 Watch was paired to Xcode but would never connect due to the same "tunneling" errors mentioned by others. After unpairing via Xcode Devices and Simulators the watch cannot be repaired even though I have unpaired and repaired it with iPhone and unpaired and repaired the iPhone to Xcode. NOTHING will cause Xcode to find the watch again. Damn it Apple this crap has been an ongoing issue since Xcode 26.0 How do you have 3 dot releases and not fix something like this?! Might have gotten the watch re-connected via another suggestion in higher up in this thread to connect mack to iPhone via Hotspot. I can see the watch again in Devices and Organizers, but the setup is taking foreeeeeevvverrr so not sure what happen when I switch the mac back to regular wifi.