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.

I've filed this as Feedback FB10794147.

I'm seeing this too, and I'd love to know if it's expected.

Still missing in beta 3 too.

To clarify my use case: my app is an e-reader app focused on Biblical materials, with a cross-referencing system that can surface content from any downloaded books related to any verse or entity (people, places, things, ideas). There are lots of atlas-like resources with maps of the ancient near east in Biblical times, and it would be amazing to be able to select the name of a city on a map image and feed it into my existing functionality to find content related to that city name - verses, encyclopedia articles, etc. [edit: this should have been a comment, but now I can't find a way to delete this "reply"]