“A Summary of the WWDC25 Group Lab”

And one more little gotcha. I started all of this from a Login Item. But I've seen references to Login Items being frowned upon by Apple, so I wanted to change that to a Launch Agent. Plus, XPC doesn't work with a Login Item. And this is meant for the Mac App Store, so all of it has to be sandboxed. That meant putting the launch agent into an app-like wrapper. XPC doesn't work with a sandboxed launch agent either, in spite of it being in an app group. But that's OK. I configure the launch agent from the database and run it on a calendar interval, which is better regardless. But it looks like I got carried away with sandbox restrictions. I have to give my launch agent the user selected files capability. Otherwise, it can't talk to the ScopedBookmarkAgent at all, even on Sequoia.

There really isn't a better way to trace/debug specific push requests after the fact. If you are generally interested in tracking/confirming the fate of notifications, you can do that via a Notification Service Extension, which will be executed for every visible launch, so you can log your received notifications. This still wouldn't help if the customer disables or otherwise configures your app's notifications to not ever be shown, but would work under normal circumstances like focus modes, sending your notifications to Summaries, and so on.

We could not find the relevant properties in the KEXT's IORegistryExplorer snapshot. Looking at the snapshots you sent, I've listed the configuration of both drivers. Note that the first section lists the properties of the direct driver itself, while the second is the actual IOSCSIPeripheralDeviceType00, the parent IOBlockStorageServices. Here are the two configurations: (1) KEXT configuration: KEXT (subclass of IOSCSIParallelInterfaceController): IOMaximumSegmentAddressableBitCount = 0x20 IOMaximumSegmentCountRead = 0x81 IOMaximumSegmentCountWrite = 0x81 IOMaximumByteCountRead = 0x80000 IOMaximumByteCountWrite = 0x80000 IOMinimumSegmentAlignmentByteCount = 0x4 IOSCSIPeripheralDeviceType00: IOMaximumBlockCountRead = 0x400 IOMaximumBlockCountWrite = 0x400 IOMaximumByteCountWrite = 0x80000 IOMaximumByteCountRead = 0x80000 (2) DEXT Configuration DEXT: IOMaximumSegmentAddressableBitCount = 0x40 IOMaximumSegmentCountRead = 0x81 IOMaximumSegmentCountWrite = 0x81 IOMinimumSegmentAlignmentByteCount = 0 IOSCSIPeripher

That makes sense. I think it's not going to be too bad for customers. The data in the containers is basically transient cache and temp files (another reason why this particular App Store restriction is probably inappropriate in this case). The user's programs are stored in NSDocument bundles wherever they put them on disk (these bundles are used by the IDE via security scoped URLs which we bookmark and pass to the XPC service in the new versions of the app). In all app versions, a customer can wipe the app container, even the group container, and as soon as they restart the IDE it's all recreated and works perfectly. I test this use case regularly and it's bullet proof. Financially, the app uses (very cheap) monthly auto renewing expenses. The app itself is free to download (the auto renewing subscription is required for building programs, and comes with a month free trial) and doesn't have any permanent in-app purchases that people would lose. I can work with the new developer (a good friend), custo

We have found the cause of the issue. Below are our current entitlements: com.apple.developer.endpoint-security.client com.apple.developer.networking.networkextension content-filter-provider-systemextension dns-proxy-systemextension app-proxy-provider-systemextension com.apple.developer.system-extension.install com.apple.security.application-groups $(TeamIdentifierPrefix)xxxxxx com.apple.security.get-task-allow com.apple.security.network.client com.apple.security.cs.allow-unsigned-executable-memory We discovered that com.apple.developer.endpoint-security.client and com.apple.security.cs.allow-unsigned-executable-memory are in conflict. Currently, our approach is to download wasm files from the server to the local machine and load them dynamically at runtime, so we cannot package the wasm files into the Contents/Resources directory inside the app bundle. Could you please advise how to resolve this problem?

Hi Kevin, Thank you again for your guidance. We have an important update based on your advice. Following your suggestion to compare property configurations, we analyzed our KEXT's source code, as we could not find the relevant properties in the KEXT's IORegistryExplorer snapshot. We then attempted to replicate the KEXT's behavior in our DEXT, which has led us to a final, specific contradiction that we hope you can help us resolve. Here is a summary of our findings and final questions: 1 - KEXT Source Code Contains setProperty Calls We discovered that our KEXT's Start() function programmatically sets several IOBlockStorageCharacteristics using setProperty. The key value is: // In KEXT's Start() function: #define MAX_IO_LENGTH (512 * 1024) // 512KB setProperty(kIOMaximumByteCountWriteKey, (UInt64)MAX_IO_LENGTH, 64); // ... plus other similar properties. 2 - DEXT Fails Despite Replicating KEXT's Configuration Based on this finding and your previous advice, we implemented the following in our DEXT: We im

[quote='805890021, carlos4242, /thread/805890, /profile/carlos4242'] what I'm trying to do is transfer my app to another developer [/quote] Right. You’ve misunderstand the relevant bit of App Store Connect > Transfer an app > App transfer criteria. It says: Mac apps that have used the sandbox environment and share the Application Group Container Directory with other Mac apps can't be transferred. That “have used” is important. It doesn’t mean “are currently using” but rather it means “have ever used”. If your Mac app has ever used an app group, you can’t transfer it )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com