A Summary of the WWDC25 Group Lab

The removal of Launchpad from macOS has cost me a huge amount of wasted time. It is quite baffling why Apple's engineering team thought this was necessary. There is no scenario in which Apple's few predefined categories could possibly ever address the long tail of real world application categories and user workflows. This is a point I make in depth below. Also, I am now encountering a bug preventing me from searching for apps by name, even if I could remember the name of my 250+ native and web apps, so I have no other choice but to scroll through over 250 icons to find the app I'm looking for. I honestly do not understand what the rationale was for this change by Apple. Vital functionality that I relied on with minute-to-minute frequency was replaced with a fundamentally broken one that costs me minutes where it previously took seconds to find apps. In fact it should be obvious that predefined app categories could not possibly address real world use cases and and that forcing users into them would break more

Hi Chase, I am delighted to hear that you are interested in joining us in the future. I had a similar dream at your age, and it appears that if you continue to pursue your goals, success will eventually come your way. To get started, I recommend learning about coding and installing Xcode on your computer. Additionally, there are numerous videos from WWDC that provide up-to-date information on the subject. I wish you the best of luck in your endeavors. WWDC Videos: https://developer.apple.com/wwdc25/ Albert Pascual
  Worldwide Developer Relations.

Let me start with the comparison here: Similar performance issues were reported in the past by a former Mercurial maintainer: https://gregoryszorc.com/blog/2018/10/29/global-kernel-locks-in-apfs/. Unfortunately, there are some fairly significant flaws in the analysis there. Picking one of his data points: $ time ./slow-readdir.py -l 12 ~/src/firefox ran 12 walks across 12 processes in 172.209s real 2m52.470s user 1m54.053s sys 23m42.808s Based on his overall article, I believe he thinks that test took ~23m when in fact it took ~3m. That is, the actual test time was: ...in 172.209s -> ~2.52 -> real 2m52.470s In general, that's what real means in most time tests -> how long did this test actually take. In terms of the difference in system time, that appears to have been due to an accounting issue in the kernel. Per the investigation that was done on the bug, this particular test script ended up having multiple threads blocked in the kernel (waiting on work to complete) and the kernel included those tim

@Enzagi thanks for filing FB19889436. I checked on the status of your bug repot and it is in the process of being routed to the engineering team. I added some notes in there asking for it to be routed to a specific group.

We are working on a general USB device management solution on macOS for enterprise security. Our goal is to enforce policy-based restrictions on USB devices, such as: For USB storage devices: block mount, read, or write access. For other peripherals (e.g., USB headsets or microphones, Raspberry Pi, etc.): block usage entirely. We know in the past, kernel extensions would be the way to go, but as kext has been deprecated. And DriverKit is the new advertised framework. At first, DriverKit looked like the right direction. However, after reviewing the documentation more closely, we noticed that using DriverKit for USB requires specific entitlements: DriverKit USB Transport – VendorID DriverKit USB Transport – VendorID and ProductID This raises a challenge: if our solution is meant to cover all types of USB devices, we would theoretically need entitlements for every VendorID/ProductID in existence. My questions are: Is DriverKit actually the right framework for this kind of general-purpose USB device control? No.

Correct as you said for the first one I can get around, post which I am able to move app owned by user sagarpurohit to trash. But for the ones owned by root is where I get permission issue even though I am member of admin. sagarpurohit@Sagars-MacBook-Pro ~ % dscl . -read /Groups/admin GroupMembership GroupMembership: root sagarpurohit _mbsetupuser sagarpurohit@Sagars-MacBook-Pro ~ % ls -la /Applications drwxrwxr-x@ 5 root wheel 160 30 Aug 11:03 Adobe Acrobat DC drwxrwxr-x@ 3 root wheel 96 15 Jul 12:01 BBEdit.app drwxr-xr-x@ 3 sagarpurohit admin 96 14 Sep 13:03 Brave Browser.app drwxr-xr-x@ 3 sagarpurohit staff 96 10 Jul 18:02 Cursor.app drwxrwxr-x@ 3 sagarpurohit admin 96 18 Sep 11:03 Firefox.app drwxr-xr-x@ 3 root wheel 96 15 Jul 12:03 Speedtest.app drwxr-xr-x@ 3 root wheel 96 28 Aug 22:49 zoom.us.app I went through the links you shared but doesn't seem to be any solution there as I have access to directory for both read and write but this is more of who owns the app. I was trying to change the user

I have very similar issue, but also would like to group by campaign's in the detailed data.

Thank you for taking the time to reply 🙏 I have already submitted a bug report via Feedback Assistant (FB20267035), but so far I haven’t received any follow-up. I also wanted to mention that on both Reddit and the GameSir Discord, many other users have confirmed experiencing the exact same issue with wired Switch Pro controllers (and GameSir X5 Lite). So it definitely seems to be affecting a larger group of users, not just me. Hopefully this additional context can help prioritize the fix. Thanks again!

OK. Lemme start you out with a couple of links: On File System Permissions explains the different subsystems that all contribute to file system permissions on macOS. BSD Privilege Escalation on macOS describes the various ways to escalate privileges on macOS. In this case you’re dealing with two types of file system permissions: App Sandbox BSD You can get around the first with the coöperation of the user, that is, by having them select the relevant directory in an open or save panel. The issue you’re bumping into in the second. Consider the permissions on the Applications folder: % ls -ld /Applications drwxrwxr-x 89 root admin 2848 Sep 17 14:06 /Applications To remove application you need to be able to write to this directory. But you can only do that if you’re running as a user in the admin group. The directory is read-only for standard users. To get around this you need to escalate privileges. However, the App Review Guidelines specifically proscribe that (clause 2.4.5(v)) I’m only aware of one ex