I submitted FB5703360 in 2019 (which was created radar). Since then I've also reported these for legacyScreenSavers: FB12086240 which deals with ScreenSaverViews not being removed, so they hang around and keep running. FB13362403 which deals with legacyScreenSaver continuing to run even after it is supposedly stopped (this might be because of FB12086240). FB13444225 which deals with legacyScreenSaver making multiple views when it shouldn't. Do you suggest that I add a 2nd bug report requesting a new app extension technology API?

I went ahead and submitted FB17280866. I came here first to just see if I was trying to do something that UITextView is not capable of doing.

I have a pared down project I can post, however I found one thing, and I'm not sure if it's supposed to work this way or not. I'm guessing not. I'd expect this to work, and it does: Load the text view from storyboard. Editing is not active. Change the smartQuotesType (or any other attr). Activate editing. The correct setting of smartQuotesType is used. I'd expect this to work too, but it does not: Load the text view from storyboard. Editing is not active. Activate editing. Change the smartQuotesType (or any other attr). Typing will use the value it was set to prior to activating editing. I'd expect this to work in both cases, but only the first works: Load the text view from storyboard. Editing is not active. Change the smartQuotesType (or any other attr). Activate editing. The correct setting of smartQuotesType is used. Change the smartQuotesType (or any other attr). Typing will still use the value it was changed to prior to activating editing. If changing the attributes should work in all cases above, let me know and I'll post the project.

Ah, thanks for that bit of info. I hadn't seen the comment feature before and figured it was a new way of replying to a specific reply. Odd. So I'll add it to my ever-growing pile of unresolved bugs. Neato.

BTW, the review team wouldn't let me use the entitlement, even though it's the only way I've found to workaround the bug, so I disabled the feature to open the Spotlight window for now. Hopefully this will be fixed toot sweet so I can enable it again.

Although the web page for Code-level Support Request has a blurb that says DTS will be answering questions directly in these forums between May 30 through June 17, and "will not be reviewing private support requests". So does that mean I can submit a request, but it will be ignored until June 18?

That was next on my list, if nobody had an answer for me here. I've also reported this as a bug.

Any luck?

It's also not clear how to call the selectors that are passed in to methods like: canCloseDocumentWithDelegate:(id)delegate shouldCloseSelector:(nullable SEL)shouldCloseSelector contextInfo:(nullable void *)contextInfo; shouldCloseWindowController:(NSWindowController *)windowController delegate:(nullable id)delegate shouldCloseSelector:(nullable SEL)shouldCloseSelector contextInfo:(nullable void *)contextInfo; I'd love to see actual working examples of those methods.

Any chance the 2 settings in Sound & Haptics->Keyboard Feedback for Sound and Haptics are available to keyboard extensions?

OMG, user error, but one that Apple could prevent. I revisited the docs for keyboard extensions and found it right in the first paragraph: Custom keyboards operate in a sandboxed environment running in an isolated process. This sandbox’s default configuration disallows access to the network and prevents writing to the containing app’s shared group containers (reading is permitted). Open access lets you do things like store keyboard configuration, perform more complex analysis on text the user typed, or provide advanced features that require server support. But Apple could help developers by mentioning RequestsOpenAccess in the error message instead of being somewhat cryptic about it.

That's too bad. I'll submit a bug.

Nobody?