I was alerted to the fact that when you search with a plain string in the spotlight popup the search is run as: kind:Documents spotlighttest So the new question: Where is it determined what file types are considered documents? Seems like one way to allow this would be to inherit from the right UTI type, but I don't see any "document" UTI types. Any ideas?

Another clue, kind:HTML isn't the real difference, instead it's the fact that any text recognized as a metadata search takes a different path, and that path includes the .html files. For example: spotlighttest OR cantfindthis Will also correctly include .html files. It's just when you type "spotlighttest" that .html files are not included in results.

Do you get different results if the "Websites" item in Settings > Spotlight is on or off? Alas no. Also it's not just .html, but other file formats as well. For example .opml files have similar behavior.

A clue! If you search the spotlight popup with the following text: kind:HTML AND "spotlighttest" Then you will get the .html files shown. Yeah! But I don't understand why this is necessary for .html files and not for many other files types.

Did you ever find fix or workaround for this?

@SilverMarcs I'm on macOS 14 and I am seeing the same problem. No animation when .listStyle(.sidebar). Your suggesting does fix the problem though, if I change to any other list style then animations work again.

Thanks for your reply and sorry that I didn't reply sooner. I don't think that is really a bug because CloudKit was designed to synchronize only when it determines appropriate. I think from end users experience perspective it would definitely be considered a bug. Please see this movie that I've made showing users experience: https://vimeo.com/957328976 https://github.com/jessegrosjean/sample-cloudkit-sync-engine (my code) To me it feels broken. Especially since changes are able to go from macOS to iOS fast... it's just changes from iOS to macOS that don't refresh until Mac app goes into background. In the production environment, that may not be a real issue, because people typically don't put their devices side by side to see the synchronization. While it's maybe true that users don't use Mac and iPhone at same time, there are two times when I expect this bug would be particularly problematic: Sync is often buggy and users don't trust it. So when they first get an app they will test to see if this app can actually sync well. And they do this by opening up the same document on two computer and expect consistent results. CloudKit supports data sharing with other users. Sometimes both users are editing data at same time. It will be very weird if one user (on iOS) is seeing macOS changes almost instantly, while the macOS user is seeing no changes from the iOS user.

Odd... for and hour or so all my examples started to work. Sync was fast in both directions, but then it reverted to previous behavior... changes from Mac to iOS are fast... changes from iOS to Mac don't show until put Mac app in background and reactive. Sometimes even that doesn't work and I need to restart Mac app to see changes. I find it very odd that even when the Mac version fails to see changes... if I add an item in the Mac version it still instantly shows up on iOS version.

After two days if trying all the CloudKit demo apps that I could find and seeing same behavior... things just started to work. Now I see instant updates in both directions: edit on iPhone > see on Mac edit on Mac > see on iPhone My test apps are all using different containers, but I'm doing the testing using the same user account. If anyone has insite into this change in behavior please let me know.

Machine restart seems to have fixed. Grrrrg. Wish I had tried that sooner!

Thanks for your response. It inspired me to start over and create a demo project so that I could give you a simple example of exactly what was happening... and of course the demo project is working fine... dmgs are created and notarized by the post archive script without requiring that Xcode has full disk access. I'm now in slow process of trying to figure what in the world is different between my real project and demo. Will report back when I figure more what is going on. What is /Volumes/Bike in this context? I'm pretty sure it's something that hdiutil create is doing. My guess (without much actual knowledge) is that: My post archive script has access to /tmp, because it's able to create file/directories there hdiutil create creates an empty Bike.dmg file (I see this temporary show in the finder) hdiutil create then mounts that Bike.dmg file as Volumes/Bike When hdiutil create tries to copy content to that volume it fails because my script doesn't have access to that mounted volume?

I have verified that this problem does not happen on 14.2, but does happen on 14.3. Here's a full demo project for testing: https://github.com/jessegrosjean/AppIntentsDemo Please let me know if you find a workaround for Xcode 14.3.

I didn't get any feedback on this, I don't think it's possible. I think only option is to allow user to select any row from any document for "after row", then maybe throw a runtime error if the "after row" isn't part of the document that the row is being added to.

I've made progress on getting NSTextCheckingClient to work. Still not sure that my Implementation is right, but at least some things work. Would be great to get some expert eyes on this code so there will be a good Swift implementation of NSTextInputClient and NSTextCheckingClient for developers to find.

I'm seeing this is NOT a good pattern. Found a case where layer.mySublayer.presentation()! in context of init(layer: Any). With that said I still am not quite sure what the correct behavior should be... does it make sense for the presentation layer to hold references to model layers? So for example replace the above with: override init(layer: Any) {         let layer = layer as! MyLayer         mySublayer = layer.mySublayer         super.init(layer: layer) }