“missing package product”

Hi Kevin, Thank you for the detailed guidance. As you suggested, I have filed a bug report via Feedback Assistant regarding the migration path from legacy KEXT power management to DriverKit. I have included our legacy initialization logic and the specific technical contradictions we encountered during the transition. Feedback ID: FB22320055 Regarding your comment on calling super: You were absolutely correct. Failing to invoke super::SetPowerState(powerFlags, SUPERDISPATCH) was indeed the cause of the missed RPC ACK, which triggered the 21-second watchdog panic. Implementing that call as the final step in my SetPowerState_Impl has resolved the immediate panic issue. We have since stabilized the driver's lifecycle and deactivation logic. We would greatly appreciate it if you could follow up on the Feedback report to help clarify the canonical resource management boundaries for complex storage drivers in DriverKit. Best Regards, Charles

Hello, the Product ID should be unique at the developer account level. For your use case, use a different Product ID when creating products for the “App B (production)” app if you have already used them in App A (staging).

Holy hell you saved my life. Being going in circles 3 times with App Store Connect team. They have completely NO idea what to look for, and also completely missed this. Thank you thank you for posting!

There is potentially one detail I jumped over that is relevant — are you expecting clients of your library to build from source, or to consume a pre-compiled library? I had assumed it was a pre-compiled library based on the .a file mention. I think that's accurate, but it would be good to confirm that. If the library is intended to be a pre-compiled asset, then what you'd deliver to the client is an XCFramework. This is meant to be a single container that has everything a library client needs — copies of a built binary for each platform and simulator your library supports, plus the header files. While you can hand your clients the XCFramework so they can drag-and-drop it in their Xcode project, one nice vehicle you can use for distribution is a Swift package, which will point to a compressed (zipped) copy of the XCFramework, along with a checksum for verifying its integrity. This way, it's easy to ship updates of the library to your clients. Distributing binary frameworks as Swift packages h

Hi, Thank you for the follow-up and for confirming the AASA multi-App ID support, that is a useful detail. Just to make sure we fully understand the recommendation: are you suggesting we add the testing platform's Team ID + Bundle ID to our AASA file so that their re-signed build is also a trusted app for our domain? If so, we want to understand the security implications of listing a third-party signing identity in our AASA file before going down that path. Regarding TestFlight, we are already using it for manual pre-release testing and it works well for that purpose. Our challenge is specifically with automated UI testing in a cloud device farm, where TestFlight distribution is not part of the workflow. We also wanted to ask about a hybrid distribution approach we are considering, and whether it is permitted under Apple's terms: Use the Apple Developer Enterprise Program to distribute the app internally to our cloud-based testing infrastructure, allowing their re-signing process to work under an Enterprise p

Thank you for the quick response and for the clarification on how iOS enforces AASA validation, that context is very helpful. To answer your question: our cloud-based device testing environment is a third-party device farm that runs automated UI tests against real iOS devices hosted in their infrastructure, BrowserStack. In order to install our app on their devices, their platform re-signs the app using their own provisioning profile, which is where the Associated Domains entitlement is lost. We fully understand that this is a security boundary by design, we are not looking to bypass AASA validation in production. Our concern is specifically scoped to pre-production testing: we need a way to validate our authentication flow end-to-end (including the Universal Link redirect back into the app) in an automated, cloud-hosted environment before shipping to production. Given your confirmation that there is no native provisioning flag to accommodate this, we have a follow-up quest

Thanks for the detailed response! To answer your questions: OAuth - I don't see a pattern other than time. It seems to lose the OAuth token 2 or 3 times per day. It also doesn't seem to depend on idle time. I can be in the middle of working and it will lose the token. Yes, especially since thinking can go off the rails or go into a nearly-endless loop, this serves as a way to monitor and guide agent progress. I did file a feedback on all the issues, btw! (FB22310171 on the whole set of issues, and I also just filed FB22316631 per your request on this specific one.) Next time this occurs, I will attach it to the Feedback report. No, I have never downloaded or setup Codex. I especially want to highlight the additional bug I reported in my Feedback report but did not post here -- the agent will take action even if I specifically tell it to ask for approval before proceding. This is concerning because there is now some internal state where the agent believes it has gotten permission even though

There are no guarantees that SLC events will arrive simultaneously for different apps. First of all, the SLC is a relative distance service. When the app started the request will matter. Then how quickly they have processed the previous event and returned would matter. The load of the app on the main thread (which is the thread these events are delivered by default) will effect how fast the events are delivered to the callback function. And last but not least, the delivery of events to an app is controlled by the system and it will decide when an app, which is already not running in the foreground (at least one of them will be in the background), will receive these events. If the apps are terminated (as opposed to just being suspended in the background), further throttles will apply. In summary, you cannot rely on two apps receiving the events at the same moment. If they do, you should consider those as happy coincidences, and not something to rely on in production.