Using the tab key to change from editing the multiline text field to the single line text field also causes the window to close so using the mouse is not required to reproduce the bug.

Archiving works. It's when I attempt to submit it to be notarized that it complains about the hardened runtime not being enabled (though it is enabled in my Xcode project but for some reason it must not be enabling it on the embedded executables, which are inside an embedded framework). Haven't had time to retry yet but I assume if I manually do it from the command line it'll work. Will report back when I have a little more time to try.

So I tested converting the AVAudioPCMBuffer I have (which is AVAudioPCMFormatInt16) to a new AVAudioPCMFormatFloat32 and AVAudioEngine plays the float32 pcm buffer. I assumed it was valid to pass in a PCM buffer in other formats (being that -connect:to:format: has a format parameter). Can't seem to get it to play without using float32 format. I think I'll open a new thread asking about this since your question was related but different.

So to play on AVAudioEngine you have to use the same format returned by mainMixerNode.inputFormatForBus? If I have an audio buffer already constructed in with format AVAudioPCMFormatInt16 I can't schedule it on AVAudioEngine?

This particularly app (just for me) embeds the Java runtime. The java runtime is contained within a framework of mine. Xcode complains that the hardened runtime isn't enabled for these prebuilt executables. Is there a way to have Xcode GUI handle this when I archive or do I have use the command line?

Workaround that worked for me: Select one of the apps that is shown in the list (any one). From the details page this app click the down chevron next to the app title and change the app to the app you actually want to update.

Yea I can't update my app. App Store Connect is only showing me a partial list of my apps.

Hm. Maybe it was the Mac App Store version of that same app I was thinking of (that didn't have the Hardened runtime enabled). I know it used to be optional in and outside MAS I guess it changed at some point.

I feel your pain; I've been in the same boat for like two months. They also never responded to my bug report so who knows. It seems to be better on 17.2.1 (but I haven't tested it enough to say confidently that it is fixed). See threads: https://developer.apple.com/forums/thread/737685 https://developer.apple.com/forums/thread/730639?answerId=765237022#765237022 https://developer.apple.com/forums/thread/738048?answerId=768059022 Been working on my own synthesizer for awhile now.

@And0Austria Thanks for sharing that info. I'll have to give AVSpeechSynthesizer another try on iOS 17.2 now and see. It would be nice (if they did fix it) if they included that information in the release notes and/or updated some of our bug reports but if it's fixed that'll be good enough....

I made a post about this a couple of months ago: https://developer.apple.com/forums/thread/738814 Had to disable Picture in Picture as a workaround. On Mac Catalyst the way PIP was implemented (if it ever worked) was kind of pointless IMO. It should pop out into a separate standalone window on a Mac but I think you could only drag it around inside the window where the WKWebView was.

For whatever reason I'm not getting e-mail notifications when people reply in this thread even though I'm "following it." Weird. I'm a little confused by all the manually downloading voice stuff. I don't particularly care that much that speech synthesis isn't working in the simulator (although it would be nice if it did...like it use to). I noticed, on device, that speech synthesis just randomly seems to stop working since the release of iOS 17. Incorrect behavior includes: -Jumping around to random ranges of the speech string at random points. -Speech synthesis simply stops speaking at certain points of some speech strings. When synthesizing short amounts of text (a couple of words) it usually "works" but the inconsistent behavior seems to match the idea that there are possibly memory management issues going on under the covers. I haven't checked on iOS 17.2 to see if it's fixed. Nothing in the release notes say anything about it. The API is basically unusable. My TSI got closed with a no workaround available message and my bug report has not received a reply. Sooo....they seem to be in no rush to fix it. I was going to release my app in just a few days before they broke it and put me on hold. Investigating alternatives. Feels like I got burned. I imagine all the devs who already have a released app using AVSpeechSynthesizer must feel really burned.

Good question. You are far from the only one who has this concern. Many developers prefer the "old way" of making apps and find SwiftUI to be limiting, hidden behind a wall of "magic" Apple controls. We have to inherit all their bugs. In AppKit/UIKit we do too but we have a much greater chance at implementing our own workarounds. I think most developers, even the ones who like SwiftUI at least want the option to be able to drop into the lower-level APIs SwiftUI is wrapping. For example in most cases on iOS SwiftUI seems to rely on UIKit like SwiftData is built on top of CoreData (I could be wrong on some of those details, anyone out there feel free to fact check me if I am). This doesn't appear to be the direction Apple is heading in (giving developers the choice). Feels like Apple is trying to force this on us instead of letting the framework speak for itself. I'm getting tired of the way they are bullying developers. They are flexing their power a little too much for my liking. They want to treat us like babies. Don't you worry your little head about what's going on under the covers. Here's SwiftUI peasant...you can use that... what's underneath it...well that's not for you. I also understand that Xcode is a very complex piece of code and that maintaining and evolving some tools (as IBDesignable) requires effort I don't think they've touched IBDesignables in years (could be wrong). It's been frozen in time, for a long time. Good thing about that is you don't get new bugs when they stop touching things.

So I modified the .dylib and changed the LC_BUILD_VERSION's platform to 6 (signifies Mac Catalyst see <mach-o/loader.h>). I also discovered this post from Quinn https://developer.apple.com/forums/thread/659964 and discovered that I could have done this with vtool as well.

This stackoverflow post has a useful answer: https://stackoverflow.com/questions/1085137/how-do-i-determine-the-target-architecture-of-static-library-a-on-mac-os-x