A Summary of the WWDC25 Group Lab

It's quite common for app bundles to be distributed in .zip files, and to be stored on-disk as filesystem-compressed files. However, having them both appears to be an edge case that's broken for at least two major releases! (FB19048357, FB19329524) Let me start with a more basic question, namely, what are you actually trying to do here? The filesystems support for compressed files is a fairly obscure implementation detail that we never formally documented and never intended for widespread use. Note, for example, that its implementation is incompatible with custom icons*. Similarly, support for them in the broader ecosystem is inconsistent, and copying them incorrectly will result in a non-functional file. That isn't an issue for the role the system intended them for**, but it is a problem in broader usage. *Compressed files repurposed the resource forks, while custom file icons use essentially the same resource fork-based architecture that they used on macOS Classic. **Basically, further reducing the size of

I personally find that placing precisely objects is a critical limit (or constraint) with SwiftUI. What I do (sometimes with mixed results) is to group objects in separate Views (red-bordered in the image). It makes it easier to position objects (with HStack / VStack) in each view and then position the views. Hope that helps.

Let me reiterate that, if you want me to see your reply, it’s important that you reply as a reply rather than in the comments. unchecked the Enable Register App Groups for now. I think that’s a reasonable option while you focus on other stuff. However, you do have to be careful here. Specifically, check that your app’s provisioning profile authorises your use of this app group ID. When you set Enable Register App Groups, Xcode does that for you. If you disable Enable Register App Groups, it becomes your responsibility to do it. That’s generally not hard — just enable the App Group capability on your App ID — but it’s important to double that this flows through to final app’s provisioning profile, both in for development and distribution signing. Without that, macOS may end up presenting annoying app group authorisation alerts. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

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.