“missing package product”

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 files that y

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

Has this been an issue for ten years? I am still in a rejection loop, can't see the IAP/Sub section in the version. After creating a new sub product, re-building to change the product code the IAP/Sub section appeared, I linked the sub product to the app, added new build submitted for review and the link went away and of course because the product wasn't approved with the binary the in app purchase can't ever work

Thanks so much for the post, unfortunately the Developer Account team does not monitor the forums. I would recommend you to contact the developer account support at https://developer.apple.com/contact to make sure they are aware of the issue and they can give you an status on your account in case you are missing anything. Thanks Albert 
  Worldwide Developer Relations.

First off, as a general note, I've done my best to answer your questions below, but what I'd actually like to understand is what your larger product goal actually is, independent of any particular technology (like DriverKit). My concern here is that you're focusing on DriverKit because it's one of our more visible technology layers and then asking how it can solve your problem... without ever realizing that there are other API options that would actually be a far better solution. As a concrete example of this, I regularly see questions from developers trying to write DEXTs for vendor-specific USB devices who don't realize that the RIGHT way to work with a vendor-specific USB device on macOS is the IOUSBHost framework. intercept raw HID input reports from an external mouse through any top case–related path in the HID stack. This is the first time I've heard the term top case, but from the general context, I'm going to guess that your goal is to intercept and modify the events 3rd-party HID devices are