@DTS Engineer Some more feedbacks: FB23249963 (Git delete file) FB23251693 (Markdown copy text from list) FB23252112 (Markdown switch between modes cursor position) FB23252478 (Run destination Mac icon) FB23252647 (Diagnostics window)

@DTS Engineer Quinn spot on!! Thanks a ton for that clarification! I was breaking my head over it.

@DTS Engineer Thanks a lot Quinn, fingers crossed hope it gets fixed. @DTS Engineer on a completely different note would you know of any documentation for these predefined messages? Like for example the following doesn't even compile is this me using the API incorrectly or a another bug? Code (doesn't compile): let m2 = NotificationCenter.default.messages( of: UIDevice.self, for: .batteryStateDidChange ) Error: No exact matches in call to instance method 'messages'

@b.n.ch @jpires Can you check the following: Open Xcode 27 > Settings > Components See if iOS 27.0 beta is installed. If it is not installed you can tap on the Get button to get it.

@DTS Engineer thanks a lot for looking into them, I have filed some more. Xcode Playground Feedbacks FB23190489 (print statements) FB23198044 (help popup) Other Xcode Feedbacks FB23198291 (Clear recents)

@fahad-sh Thanks a lot filing the Feedback, yes it would be great to have all Apple solution. I agree it feels a bit odd to have end to end sync with cloudkit out of the box and then have your server just to initiate push notifications. On a different note, something to keep in mind: Based on the latest WidgetKit Foundations, frequent reloads when the app is in foreground might be throttled. If data is changed It is preferred to reload timeline when app goes to background / is not the active app. I think it is to save battery life. Another problem / Proposal Since all timeline reloads are budgeted, so right now we have to reload all timelines belonging to a certain widget kind. It would be nice for Apple to provide an option (API) only to reload certain widgets based on certain parameter configuration values, so that we don't need to reload all timeline for widget kind. Hopefully that would result consuming less of the widget reloaded and less of the quota and better battery life

@DTS Engineer I really don't have the luxury / ability to install macOS 27 beta, I am sorry The feedback has enough information for the Xcode team to verify if the bug is fixed on macOS 27 beta I hope Apple's relevant team can verify this and confirm. I am just raising these issues, hoping they get fixed before the final release Please make the relevant team aware of it, thanks During the interaction with the Apple Engineers in the group discussion, was asked to raise feedbacks so that the team could look into it so would be great if you can pass it on to the relevant team, thanks!

@Frameworks Engineer @simonbs For widget push update to work you need your own server which needs to initiate this push notification, which will send to APNS (Apple Push Notification Server) Then APNS will send to the relevant devices Your server can't send a push notification for every data change, somehow you need to have a way to collate because it is budgeted Questions For this to even work in your case, How does you need to configure the server? (because your data is stored in CloudKit)? How will your server be aware of any data changes, should the app send HTTP request to your server then your server initiates the push notification? Or can you do this even without a server by the app directly talking to APNS (I don't think it is possible)? My understanding (please confirm / clarify) To keep widget data up to date: I feel it needs to be a combination of all 4 TimelineReloadPolicy When your app is open it can reload timelines When your app is open and data changes on a different device then observe cloudkit sync notifications and reload timeline Widget Push Updates - needs your own server with some logic on your end, where your server think enough data has changed over time to initiate a push notification and your app needs to handle this. 1, 2, and 3 are can be entirely done on the app side. 4 needs server side work and app work.

@DTS Engineer Sorry couldn't edit the previous post to add this one: FB23150779 (Remove bookmark)

@DTS Engineer, I have filed some more bugs, please have a look, thanks! Xcode - Markdown Feedbacks: FB23145660 (Xcode crash - table deletion) FB23144227 (Table column copy) FB23144606 (Code formatting in same line) FB23144989 (Table column word wrap) FB23145786 (table column leading and trailing space) FB23145488 (Insert table) FB23145909 (Table cell right click) FB23146021 (Table width)

Thanks for looking into it, appreciate it. No I only tested on macOS 26.5.1 (25F80).

I am no expert so take it with a pinch of salt. I don't have a solution when the app is closed. What will not work: ResultsObserver or any of the SwiftUI's @State etc will not work in widgets because this is loaded from a timeline and this is all synchronized to disk, so no way for the widget to react when underlying data changes, that is what makes widgets so efficient. Best I can come up with (it is not ideal): When you open the app observe for core-data sync notifications and reload relevant widgets. Worst case set a timeline refresh policy to a date that is 1 hour from the current time, so that the user has at least the data that is updated 1 hour ago. Summary I don't know how to reload when deviceA updates and deviceB's app is closed If you come up with a solution would love to know

Thanks a lot @DTS Engineer Ziqiao Chen The only trouble I have is that a view's initializer could called multiple times when the parent view's state changes, so would the query be re-evaluated every time the initializer is run?

Thanks a lot @Frameworks Engineer Feedback: FB23078234 This includes diagnostics from the device Sample project Screen recordings It would be great if it is looked into as this hampers testing

@DTS Engineer Thanks a lot Quinn! Feedback: FB23077783 Not sure it is just my preference, so could be a bit subjective.