“missing package product”

Sorry, it was a TSI, not a bug report. I replied to the DTS email yesterday with the full spin dump. Ahh, I see it now. So, the first thing I actually did was search for /usr/lib/libEndpointSecurity.dylib (the library link path), which is a convenient way to find all ES clients. What you'll find is that there are two clients— yours and a (presumably unrelated) 3rd party client. That's a critical factor here because it means that there are now two independent entities with veto power over each other's activities, particularly activity that's coming from helper components (not just the direct ES client). That leads to here: There are only 2 other threads in the logs that appear relevant, both from our helper process and both down in APFS. One of them is also stuck inside decmpfs_read_compressed: That's the deadlock. More specifically, looking at your thread's stack when you enter decmpfs_read_compressed, the first thing it does is call decmpfs_lock_compressed_data: (1) *940 decmpfs_read_compressed + 300 (kernel

Since this is a change in behavior between Xcode versions, you absolutely should file this as a bug report. The expression on the line that you cited is really quite something! Make sure to post the FB number here for our reference. Since this is a library you depend on, you should talk to the maintainers to look at breaking that up into smaller statements so that you're able to compile it with Xcode 26.4. If you're using Swift Package Manager to import a library, there is a way you can make local modifications to a package you depend on, which might also be helpful to you here. — Ed Ford,  DTS Engineer

Our IAPs are stuck on In Review and Waiting for Review Waiting for Review: You have submitted your In-App Purchase to be reviewed by Apple. You can make edits to the product while it is in this status. In Review: Your In-App Purchase product is currently being reviewed by Apple. Only edits to the product’s reference name, pricing, and availability can be made when it has this status. This creates a deadlock because we cannot attach them since the section does not show, and the section does not show because they are not Ready to Submit. There is no need since you already submitted them for review. When submitting an In-App Purchase or subscription for the first time, you must submit it with a new app version. If there are multiple In-App Purchases or subscriptions related to that version, submit all of them together. Once App Review approves one or more In-App Purchases or subscriptions for your app, you can submit more In-App Purchases or subscriptions without a new app version. For

@h2oconsulting I can't test it in the sandbox, since the application is not approved. Testing In-App Purchase in the Apple sandbox environment doesn’t require you submit your In-App Purchases for review. For more information, see TN3186: Troubleshooting In-App Purchases availability in the sandbox. When submitting an In-App Purchase or subscription for the first time, you must submit it with a new app version. If there are multiple In-App Purchases or subscriptions related to that version, submit all of them together. Once App Review approves one or more In-App Purchases or subscriptions for your app, you can submit more In-App Purchases or subscriptions without a new app version. For more information about submitting In-App Purchases, see Submit an In-App Purchase. After submitting your In-App Purchases to App Review, they might also be missing or unresponsive during review. The sandbox environment is a test environment for testing the In-App Purchase implementation in your app with real product

The In-App Purchases and Subscriptions section is completely missing from the version page in App Store Connect This section appears when at least one In-App Purchase (consumable, non-consumable, auto-renewable subscription, non-renewing susbcription) has a Ready to Submit status in your portal. If your In-App Purchase doesn't have this status, complete any missing information. For more information, see In-App Purchase statuses. Can IAP products be approved independently without being attached to an app version, given that our app has already been approved multiple times? When submitting an In-App Purchase or subscription for the first time, you must submit it with a new app version. If there are multiple In-App Purchases or subscriptions related to that version, submit all of them together. Once App Review approves one or more In-App Purchases or subscriptions for your app, you can submit more In-App Purchases or subscriptions without a new app version. For more information, see Su

Feedback ID: FB22320055 Perfect, thank you! 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. FYI, DriverKit is supposed to be relatively panic-proof; easy to create panics like this are often caused by overlooking a specific detail of the API requirement, not some larger architectural failure. Implementing that call as the final step in my SetPowerState_Impl has resolved the immediate panic issue. Fabulous! __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Chiming in to say three things: The Oauth token expiration happens to me as well. I can't find an exact pattern, but it seems to happen when I leave Xcode idle for a while. I'll go have lunch, come back, and suddenly I have to sign out and sign back in to Claude Agent. The AI seems to lose itself a lot. It'll begin responding to a prompt, I'll see output in the chat, but then it'll hang at Thinking... for a couple minutes. Suddenly, it'll pick up again and it always starts with: I should resume... or I'll resume..., as if the original session got interrupted. My internet connection is rock-solid; that is NOT the issue. This happens very frequently and it's pretty annoying because it adds minutes of overhead to what should be very quick, easy requests. Unlike Xcode 26.3, version 26.4 now puts much of the AI's thinking into chat bubbles that cut off the text and are not expandable. This is very dumb. I WANT to see what the AI is thinking. Xcode 26.4's UI is actively harmful and in the way. The only bub

It is a mixture of a number of things. After calling contentHandler, the notification starts getting processed, and as far as you are concerned the NSE is done. If there is no memory pressure, and the extension is known to run frequently, the system may not terminate the process, but reuse it by leaving it in memory, and just give it execution time the next time it needs to run. So, the process could stay alive after contentHandler, but it is not guaranteed. It could be terminated right after, or it could be left in memory for one notification, but could end up being terminated after another one. The URLSession task continues to run, because the NSE process is not the one running it, but the system handles the network requests. The request may complete after calling contentHandler, but by the time it does there may be no process to return the results to. So, it is not entirely safe to rely on this assumption, but you could fire-and-forget, as long as you can gracefully handle the situations where the process