I got it working and hopefully this will help someone else. And maybe someone who understands more about this can fill in some details as to why this is happening. In this particular case, image classification was occurring from a live camera view whenever a photo was taken. It was happening on its own task. The rate limit appears to have occurred in ModelManagerServices (subsystem com.apple.modelmanager, category IPC) and then passed up. It would happen consistently in this portion of the app after processing several photos (I had originally thought it was around 20, but it was usually closer to 12-18, depending on the device). After you hit the limit in this part of the app, you would continue to get the rate limit error from then on every time it tried to analyze the image, even if you went away to another section of then came back to it later or just waited a while. The only way to get it working again was to kill the app and re-launch. However, there are other parts of the app that use the same code for analyzing images and none of them exhibited this problem. In fact, you could hit the rate limit in the camera view, go to another section and processing a bunch of images from files, and the app would truck along fine, calling the same image classification code. Go back to the camera view and you'd get the rate limit immediately. I tried everything I could think of, including enforcing long pauses between photos, tearing down the AVCapture session after each was taken and then standing it back up again after the photo was analyzed, scaling the images even smaller, lowering the priority of the task, and a host of other things. Nothing worked. Then finally, I tried presenting the UI that shows during the analysis (and thus calls the analysis code) as its own modal sheet (the camera view itself being one) and it worked. I don't know why this works, but I'm not getting the rate limit anymore.

One thing to note: This does not seem to happen in the Catalyst version of the app running on macOS 27 Beta 6. Just on iOS.

The problem seems to be fixed now.

I should add that I have another machine with Xcode 27 Beta 4 (running macOS 27 Beta 4) that I just tried and it works fine uploading a build to TestFlight. Unfortunately the call signature of one the APIs I'm using changed under Beta 5 (PrivateCloudComputerLanguageModel.supportsLocale(_:) so that's what's making this so urgent.

Here's the feedback number for any Apple people who may see this: FB24262057

Oops. I should have mentioned that I did file a feedback on this: FB23378161 if you can pass it on, that would be great! Thank you.

These restrictions really need to be rethought. They exclude a lot of developers that have a long history on the App Store based on success that happened a long time ago. These are some of the App Store's biggest, longest-term supporters. The restrictions are so arbitrary and, honestly, disrespectful to 3rd party developers.

This is still broken in 26.1 Beta 3. Is there anyway to find out if it will be fixed by the time 26.1 releases?

I duped this one as well (FB20547079 for iPadOS 26, FB20376452 for macCatalyst 26.1, and FB20376479 for iOS 26.1). The problem still exists in beta 2.

Is anyone else running into an issue with SpeechAnalyzer not releasing properly in iOS 26 Beta 4? You can test this with the speech to text sample app by create a story and recording some speech multiple times. On the third story I'm getting a "Maximum number of recognizers reached" error when trying to record. I'm seeing this behavior in our own app too on the third attempt at using speech to text in the app. Feedback filed for this: FB19003031

This is fixed in beta 3.

Same. Code that was working in Beta 1 now produces this error in Beta 2. Hopefully someone from Apple is watching this. I know, I know, "File a feedback!", but after years of them being ignored, it's not worth the time that could better be spent elsewhere.

If anyone wants to dup it, I created Feedback FB15838445 and Apple is responding to it, asking how I used the feature. Fingers crossed they reinstate it.

I filed a feedback (FB14293963) on issue with the Mac and tab bars, complete with a sample app to reproduce the problem, in mid July. After hearing nothing for a while (feigned surprise), I contacted DTS. They told me they were aware of the issue and keep watching my feedback on the problem. That it still hasn't been addressed or responded to makes me think Apple just doesn't care. The entire feedback system is fundamentally broken is so many ways. The past few years it seems like a complete in time. Next year, I don't think I'll bother filing anything.

I went over everything again and noticed that my developer Team ID was prepended to the app's bundle id for the denial entry in swcutil_show.txt. The documentation (https://developer.apple.com/documentation/xcode/supporting-associated-domains) says the appIDs entry should be in the form of .. I'd assumed Application Identifier Prefix was the Apple ID of the app as I've seen these used interchangeably before. Anyway, I added the Team ID as a prefix and all is working. Not sure if this is an error in the documentation or if app's Apple ID is used in production. As a hedge I added both variants (prefixed by Team ID and prefixed by App ID) to the appIDs entry.