We are running into the same issue: everything runs fine under high load for 45s (very deterministically) All threads get bumped from Performance Cores to Efficient Cores for 5-10s All threads come back to Performance Cores. We have a few C++ threads (which we manually mark as .userInteractive using pthread_set_qos_class_self_np) and Swift queues (which when created are marked as qos: .userInteractive). We only seem to get this issue when running on A12 Bionic devices (iPad Min 5th Generation, iPad 8th generation). Looks like the OP also is using an A12 Bionic device (iPhone XR). We don't experience on older chips (A10X) or newer (A14). Any ideas?

@Kmart does that also include using DeviceActivityReport inside a UNNotificationContentExtension?

This is what the resulting UI looks like.

For completeness here's MyStyle Here's `MyStyle()` struct MyStyle: LabelStyle { func makeBody(configuration: Configuration) -> some View { return Label(configuration) .font(.largeTitle) .labelStyle(.) .foregroundColor(.blue) .border(Color.red) } } The code will also fail if just use `.font(.largeTitle)` directly against the `Label(token)`

I can confirm the same behavior. Looks to be a bug in ShieldConfigurationDataSource / ManagedSettingsUI. I'll also submit in Feedback assistant.

I have applied for this for two developer accounts now. One took 31 days and the other took 33 days (was done over a weekend, so it seems to me it's literally just 31 days from the first Monday after submitting). I contacted Apple dev support. Dev Support told me it's another team (Operations?) and they would pass along a request through their supervisor. I received no updates during this period (beyond "still going" when I asked). It didn't seem to help that we had external deadlines communicated. No additional information was requested. So as far as I can tell (and this seems to be the standard experience) it's just 30+ days brake check. Hang in there, good luck.

Any update on this radar? @dev0618 did you ever get a response.

Are there published limits I just found a passing mention in a WWDC22 video that says "up to 50 per process." Would be nice to have that in the docs too.

I have done this for two accounts. 33 and 36 days were how long it took.

There is no work around for this. I've done this twice for two different accounts. The times took 33 and 36 days before the entitlement was granted. All support tickets (including live calls) replied this was not their team so nothing could be done, but they would escalate to that team (we had real world deadlines) but as far as I can tell, that did nothing as we missed both our events. Just replying here that your situation is (relatively) normal and there is simply no work around.

The answer to 1 and 3 are no (as of 17.5.1). The usual apple folks here would say to submit a feature request. I do not know the answer to 2, but would love to know as well.

Hi I can confirm @SigurdL that we cannot connect to the device unless a name is specified in the advertising data. Our set up only specifies bluetoothServiceUUID which should be enough according to documentation. When the device is advertising this UUID (which I can see via other Bluetooth inspectors) AccessorySetupKit CANNOT connect. But if I add back in a name in the advertising data (even if I don't use bluetoothNameSubstring in the descriptor) the device shows up instantly. Documentation should be updated to state that both must be required in advertising data IMHO.

Same here. Our macOS app has been notarizing in under 5mins for 6+ months and now suddenly today notarytool is hanging. I suspect the service is in a hiccup today but it has not yet reached the status page.