“A Summary of the WWDC25 Group Lab”

[quote='882567022, WangZiYuan, /thread/817264?answerId=882567022#882567022, /profile/WangZiYuan'] But when I disable the content filter, the process does not stop. [/quote] OK. That’s not unexpected, give my understanding of how NE relates to the sysex infrastructure. [quote='882567022, WangZiYuan, /thread/817264?answerId=882567022#882567022, /profile/WangZiYuan'] When I manually kill the original process … the process ID definitely changes, but the issue persists. [/quote] Blat! I was hoping that the bogus state would be stored in the sysex process, and thus this would clear it. Given this finding, the only path forward I see is a bug report. [quote='880612022, kunal_a, /thread/817264?answerId=880612022#880612022, /profile/kunal_a'] I submitted FB19734992 [/quote] Thanks. I can’t go into all the details here, but the executive summary is: For internal reasons, we have an internal bug tracking the fix (r. 172870187). That fix is not in any currently released or seeded version of macOS. Even when that

I’m not aware of any known issue that matches these symptoms. As you’ve noted, iOS is expected to preserve app group containers across OS and app installs. This certainly works for most apps and most users, but that doesn’t preclude there being a bug that causes this problem for some users of some apps. To investigate this we need to see a sysdiagnose log taken immediately after the user notices the problem. That’s gonna be tricky to acquire given that this problem isn’t obviously reproducible. I have a bunch of background on this in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. Key to that process is the ability to quickly and reliably identify that the problem has occurred. If I were in your shoes I’d add specific code for that, code that’s not tied to UserDefaults or Core Data. Both of those are big, complex subsystems, which makes it hard to know whether you’re hitting a problem with that subsystem or something more fundamental. Rather, I recommend that you store this state in fil

I've hit a very similar issue with CoreML model loading hanging on the MLE5ProgramLibrary.lazyInitQueue after OS updates. A few things that helped me work around it: 1. Pre-compile to .mlmodelc instead of loading .mlpackage at runtime The AOT recompilation path (which is what's hanging) gets triggered when the on-device compiled cache is invalidated by the OS update. If you ship a pre-compiled .mlmodelc built with the matching Xcode/SDK version, it often skips recompilation entirely: // Compile once at build time or first launch let compiledURL = try MLModel.compileModel(at: mlpackageURL) // Then load from compiled let model = try MLModel(contentsOf: compiledURL, configuration: config) 2. Load on a background thread with a timeout Since the hang is on a serial dispatch queue and the C++ exception bypasses Swift error handling, wrapping the load in a Task with a timeout at least lets you fail gracefully instead of getting watchdog-killed: let loadTask = Task { try MLModel(contentsOf: modelURL, configuration: c

Thanks for looking into this. Here is a complete summary of our setup and what we have confirmed so far. App configuration: macOS app distributed via Developer ID (PKG installer) — not the Mac App Store Host app runs as a menu bar agent (LSUIElement = YES in Info.plist) NSApplicationActivationPolicy = .accessory The app runs continuously as a login item — it is always alive Network Extension is a System Extension (NEAppProxyProvider), always running alongside the host app What we have implemented: MXMetricManager.shared().addSubscriber(self) is called in applicationDidFinishLaunching in the host app — as early as possible A separate MXMetricManagerSubscriber is registered inside the Network Extension process at tunnel start Both didReceiveMetricPayloads: and didReceiveDiagnosticPayloads: are implemented On startup we also drain pastPayloads and pastDiagnosticPayloads to catch anything queued while the process was not running The subscriber object is kept alive for the full lifetime of both processes

Thanks for bringing this to the forums. [quote='821062021, hsbc-uruguay, /thread/821062, /profile/hsbc-uruguay'] Any improvements or new tools available since the 2022 DTS post? [/quote] I’m glad you asked (-: Recently the App Store Connect folks updated their documentation to describe a technique for transferring app groups between teams. See App Store Connect Help > Transfer an app > Overview of app transfer > Apps using App Groups [1]. Given that, it’s now possible to use an existing technique — using an app group ID as a keychain access group — to preserve keychain access across an app transfer. I’ve just updated App ID Prefix Change and Keychain Access to describe this approach. Now, this is all very ‘bleeding edge’, and thus it’s possible that you might run into snags. However, it’s certainly an option worth exploring. [quote='821062021, hsbc-uruguay, /thread/821062, /profile/hsbc-uruguay'] We just finished an app transfer to our developer account. [/quote] T

localization (titles and descriptions added) Localization for what!? Subscription group? Subscription plans? Perhaps, you don't have a localization insertion for the current sub group?

Thanks for the detailed explanation and tips! Could you please help with two architectural follow-up questions regarding the lifecycle and data flow: Boot-time execution and User Sessions: In Apple's examples, the Network Extension is initially installed and activated via a Container App running within a user session. However, the extension itself runs as root. Assuming the user has approved the extension and the configuration is saved, will macOS automatically bootstrap this Network Extension at boot-time (before any user logs in)? We need to ensure that our global launchd daemon and the Network Extension can establish this App Group-based XPC connection and start filtering traffic regardless of active user sessions. Confirming the IPC Roles: Given your suggestion to set the MachServices property in the launchd daemon, am I correct in assuming the recommended architecture is strictly: Launch Daemon = XPC Listener / Server (handling complex analysis) Network Extension = XPC Client (acting purely as a

Thank you for filing the feedback, @newwbee. We responded to your feedback privately a while ago, but I want to include the response here, too, for anyone else that might have the same question and stumbles upon this. SwiftUI’s Settings scene is designed to help you build a first-class Mac settings experience that follows Apple’s Human Interface Guidelines at https://developer.apple.com/design/human-interface-guidelines/settings#macOS Toolbars within Settings scenes use a style appropriate for a typical macOS settings window, which displays centered tabs to group related settings. (Please refer to Settings windows in apps like Safari and Mail as an example.) People also typically expect macOS application settings to be applied as soon as the setting is changed, without the need for a “Save” button. To create a bespoke settings experience for your app, you can use a regular Window scene, which uses a default toolbar style that you’d be familiar with in an application’s main and document windows. You w