I've got a working sample app with a Control Center widget that writes something to UserDefaults and then opens the containing app. See here.

It's also worth noting that the LaunchAppIntent as shown in that documentation page does nothing.

I've filed this as FB13888167, as requested in a WWDC 2024 lab. I was given a couple of workarounds, but they aren't working super well for me yet: Put the action validation and routing further up the responder chain, like the scene delegate. But even if my scene delegate inherits from UIResponder, it's not automatically in the responder chain. Even with tricks to insert it in the chain, I can't (yet) get it to work. Set an explicit target on the toolbar items. But I have menu items too, and the menu items might be handled by different floating windows in my app, and I'd rather not have to re-set the targets on all those menu items every time the active window changes.

As requested in a WWDC 2024 Swift lab, I've filed FB13848771 for ergonomic improvements here.

The underlying issue in Sonoma is fixed as of 14.4. For affected OS versions, I was able to work around the issue by delaying 2 seconds from the last keypress to kicking off the parse operation in the background.

It turns out that if I hide the window title and then add the .flexibleSpace (NSToolbarFlexibleSpaceItemIdentifier) item, I can get one or more toolbar items to show up on the leading edge. I don't actually need the window title in my app, so that solves my issue.

I had this issue too, and found that contentMarginsDisabled() also doesn't work in the preview (even with the newer syntax) if: Your widgets are exposed in a WidgetBundle and the one you're previewing isn't in the bundle Your widget definition's kind property isn't unique

This is still an issue on Sonoma 14.2.

Based in part on this thread, I've implemented symbolication of these diagnostic reports in a python script: https://github.com/OliveTreeBible/MXSymbolicate

Clarification: the url property on the objects in refs are just NSURL, nothing fancy.

There's an API for this in iOS 17 and later! ImageAnalysisInteraction.selectedText. https://developer.apple.com/documentation/visionkit/imageanalysisinteraction/4176689-selectedtext

Hello! Thanks for the reply. Just using insertText on UIKeyInput doesn't quite work for me, because I need to insert attributed strings. My full use case is implementing bulleted and numbered lists without using NSTextList (because I have to support OS versions before support for that), and selecting multiple lines and doing things like changing the indent level or removing list styling. The user taps one button and I have to add/remove/change list prefixes and change paragraph style attributes, and I want that to be undoable in one step. I have it set up so I can make those changes and undo and then replay it as I wish, but when I do it erases the undo manager stack.

I've posted sample code here: https://github.com/tomhamming/TextViewUndo

I spent a day experimenting with 0xdead100c issues in my app, and managed to figure out a couple of things by trial and error: It's triggered not only by holding a SQLite transaction during suspension, but also by holding an un-finalized prepared statement during suspension. So if you cache prepared statements, you need to flush and disable the cache when the app is suspended. You can reproduce it in debug on a device. It shows up in the console log as "Message from debugger: Terminated due to signal 9" I've filed FB12161496 for more clarity in documentation and tooling around this issue.

I realized that 0xdead100c only happens when dealing with files in a shared folder like an App Group container. The reason I never saw it was that the variant of my app I use from TestFlight doesn't use an App Group folder. The users who were reporting the issue are on a variant of the app that does use App Groups. With a build that uses App Groups, I was able to reproduce what appears to be 0xdead100c in debug on a device by either beginning a transaction or preparing and not finalizing a statement on a SQLite database before suspending the app. I've filed FB12161496 for more clarity in the tooling around this issue.