Hi there Quinn "The Eskimo" @DTS Engineer, As an Apple device administrator currently testing Platform SSO at our company with Microsoft Entra and the Company Portal app, I was wondering where the icon comes from that is shown in Notification Center, and in the SSO Registration popup. The only "major" identity providers with robust support for Mac PSSO right now are Okta and Microsoft. I've dug through the Company Portal app bundle and I found AppIcon.icns, but I can't find any references to setting the icon in Apple's developer documentation (I even went through the Extensible SSO section page by page). Could you perhaps point me in the right direction? Is there any way to set a custom logo today? Finally, have you seen any feedback where customers (not developers, but businesses implementing Platform SSO) are asking for the ability to customize the logo displayed to their end user? Thanks!

I am testing a Vision Pro for work, and I did not see the beta updates when signed into this Apple ID. I have a paid developer account. What I had to do as a workaround was sign into a different Apple ID: specifically, a managed Apple ID owned by my organization. I happen to be a top level administrator in our Apple Business Manager instance, so I used that one. When I sign in using that Apple ID on the Vision Pro, suddenly I can enable the beta updates for the visionOS and enroll in the "Appleseed" beta program. I updated the headset to vOS 1.2 beta 2, then signed out of that Managed Apple ID. I signed back in using my personal Apple ID. Now, in Software Update, I am still able to receive updates. The "Appleseed" beta has a warning triangle because it isn't available to my standard developer account, so I switched to the Developer beta (not the Public beta). vOS 1.2 beta 3 is available, but it warns me that the Apple ID cannot participate in this beta program (or something to that effect). Paid developers should not have to do anything special on the headset or in their accounts to see the betas within vOS' software update pane. In my case, my iPhones and Macs signed into this Apple ID can all see the option to enable beta updates.

Bumping this thread to the top of the list. I am testing a Vision Pro for work, and I did not see the beta updates when signed into this Apple ID. I have a paid developer account. What I had to do as a workaround was sign into a different Apple ID: specifically, a managed Apple ID owned by my organization. I happen to be a top level administrator in our Apple Business Manager instance, so I used that one. When I sign in using that Apple ID on the Vision Pro, suddenly I can enable the beta updates for the visionOS and enroll in the "Appleseed" beta program. I updated the headset to vOS 1.2 beta 2, then signed out of that Managed Apple ID. I signed back in using my personal Apple ID. Now, in Software Update, I am still able to receive updates. The "Appleseed" beta has a warning triangle because it isn't available to my standard developer account, so I switched to the Developer beta (not the Public beta). vOS 1.2 beta 3 is available, but it warns me that the Apple ID cannot participate in this beta program (or something to that effect). Paid developers should not have to do anything special on the headset or in their accounts to see the betas within vOS' software update pane. In my case, my iPhones and Macs signed into this Apple ID can all see the option to enable beta updates.

@asmbaty : this Apple we're talking about here. You should just expect that frameworks will be exposed to future changes without warning.

A fellow Mac sysadmin working at a company with a large population of Mac users opened a ticket with Zoom, Inc., about this issue. Zoom responded today with this: "We've asked our product team for an update, and they said that fixing this issue involves several modules in the Zoom client. We aim to address [the changes to ScreenCaptureKit] in Zoom client version 6.0.0. Currently, we are on version 5.17.7, so it seems to be about 4 release cycles away. We usually publish a new client version every 1 to 2 weeks." Take that in for a second: The de facto king of screen-sharing software says that they need 4-8 eight weeks (aka 2-4 Agile sprints) to incorporate this new framework. And Zoom is one of the more NIMBLE software developers in this space. I can't imagine how long it's going to take Cisco, Microsoft, BlueJeans, Teradici, Teamviewer, and countless others to refactor their app to ScreenCaptureKit. This is why Apple needs to publish deadlines and give their developers heads-up before displaying confusing and alarming messages on customers' screens, as they did in the 14.4 betas.

I googled the error and found this thread. Thank you for posting it. There's a reddit post that links here, too. I am experiencing this issue on a 2018 MacBook Pro (T2, Intel Core i7) running macOS 12.6 Monterey. The Mac needs to be running continuously for a LONG time before the issue starts to occur. My Mac's uptime is about 75 days right now. All applications using audio are affected when the default device is the external USB adapter. The issue goes away immediately if I switch to something else, like the internal speakers. Examples of aberrant behavior: Teams hangs for 30 seconds while starting a call and becomes unresponsive Videos in Safari will freeze, then "catch up", then freeze, and repeat every 3-5 seconds. Apple Music plays for about 3 seconds then goes silent. I am using a CalDigit TS3+ docking station and the USB device in question is a simple headset/mic adapter branded UGREEN. I bought it from Amazon. According to Audio MIDI Setup, my present audio configuration for the USB device is 16bit, 2 channel, 48kHz. So far I have tried: Killing the coreaudiod service Quitting / relaunching the affected apps Unplugging / reconnecting the USB device Plugging the USB device directly into the Mac (bypassing the hub) Changing the sample rate from 48kHz to 44kHz. None of these actions improved the behavior. I made an interesting discovery: every time I killed coreaudiod, my primary external monitor went blank for about two seconds. The primary monitor is a Dell 4K connected via the CalDigit TS3+ hub's DisplayPort output. My secondary external monitor, however, did not go blank when killing coreaudiod. That monitor is also DisplayPort, but connected via a Thunderbolt > DisplayPort adapter on the CalDigit TS3+. I can repeat this behavior with coreaudiod ad nauseam and have been gathering a sysdiagnose as I write this. The USB audio device in question is an inexpensive UGREEN branded headset/mic adapter that I bought from Amazon. According to System Profiler, the vendor ID is Realtek Semiconductor (0x0bda) and the Product ID is 0x4809. What are your USB audio device's vendor and product IDs? Have we found any in common? There's a slightly different yet similar error when recording or monitoring audio, even if you're just watching the Input tab in System Preferences: 2023-01-09 15:24:56.298594-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (CoreAudio)  index: 49, start: 0x1768beb4151d25, duration: 0x5d6, fault address: 0x7fd07175c000, fault pc: 0x7ff80f17f28f, faulting TID: 0x3ee1bb9, fault type: 0x9, PID: 0x296ea4 2023-01-09 15:24:56.298625-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (CoreAudio)  index: 50, start: 0x1768beb55a781e, duration: 0x178b, fault address: 0x7fd07173b000, fault pc: 0x7ff80f17f28f, faulting TID: 0x3ee1bb9, fault type: 0x9, PID: 0x296ea4 2023-01-09 15:24:56.298648-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (CoreAudio)  index: 51, start: 0x1768beb55a9515, duration: 0x6d6, fault address: 0x7fd07174c000, fault pc: 0x7ff80f17f28f, faulting TID: 0x3ee1bb9, fault type: 0x9, PID: 0x296ea4 [...repeated several times...] 2023-01-09 15:24:56.300733-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (CoreAudio)  Audio IO Overload thread: 3ee24c4 inputs: '<private>' outputs: '<private>' cause: 'Unknown' prewarming: no recovering: no 2023-01-09 15:24:56.301066-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (libAudioStatistics.dylib) [com.apple.coreaudio:carc]      CAReportingClient.mm:508   message {     "HAL_client_IO_duration" = 100285;     HostApplicationDisplayID = "com.apple.systempreferences";     cause = PageFaultsOffIOThread;     deadline = 48268;     "input_device_source_list" = Unknown;     "input_device_transport_list" = USB;     "input_device_uid_list" = "AppleUSBAudioEngine:Generic:USB Audio:00:1";     "io_buffer_size" = 512;     "io_cycle" = 413;     "io_cycle_budget" = 5222463225846134107;     "io_page_faults" = 0;     "is_prewarming" = 0;     "is_recovering" = 0;     "issue_type" = overload;     lateness = 38718;     "other_active_clients" = "[ { HostApplicationDisplayID_other_client: com.apple.systempreferences, sample_rate_other_client: 0.000008, io_buffer_size_other_client: 512 } ]";     "other_page_faults" = 52;     "output_device_source_list" = "";     "output_device_transport_list" = "";     "output_device_uid_list" = "";     "safety_violation" = 0;     "sample_rate" = 48000;     "scheduler_latency" = 54208;     "smallest_buffer_frame_size": <decode: missing data> Since this is my work laptop, I filed a case with AppleCare for Enterprise and included a sysdiagnose after the problem was occurring, and also another taken while reproducing the issue, so that the diagnostics will capture memory footprints, spindumps, etc., of the affected process. I'm hoping we all get to the bottom of this soon. What about Ventura? Has anyone with this issue seen an improvement there?

In addition to my request about whether you filed feedback... you should know that the '--restart' option does not work on Macs with Apple Silicon. Apple doesn't let 'root' do this for some godforsaken reason, even though forcing a machine to install updates signed by Apple poses absolutely no security risk to the user. And before someone says 'on Apple Silicon, it requires a volume owner to enter their password to approve the updates' — I'm well aware of the mechanics and how it is connected to iOS, where the user enters their passcode to allow updates to install when the device is idle. The question is... WHY was this security mechanism implemented on the Mac, and why can't root trigger the update cycle anymore. It added a lot of management headache for little tangible benefit to administrators.

Obligatory : "Did you file feedback with Apple?" Seriously, though, can you share the FB # and have you received any response from Apple about this? One of the default settings in Jamf is to simply run softwareupdate to check for available updates, not even to enforce them. This check triggers the User Notification. And the problems seem to have started with Big Sur.