“missing package product”

I am developing a library called MemoryCryptor for macOS. Its purpose is to protect sensitive data of the calling process (including launchd daemons), e.g. user passwords and other secrets, from being written to disk or read directly by debuggers or malware. So, the first thing I need to clarify here is what you're threat model is and to what degree you're willing to trust the operating system itself. The problem here is that there's a spectrum of trust that runs from: If you trust the operating system, then the solution is fairly simple. As described here, if a process has Get task allow set to false, then the system will not allow any process to retrieve that processes task port. Without that port, there's no way for an app to gain access to another apps process, solving the issue. Are many other mechanism at work that reenforce and/or prevent other attack vectors, but the general answer here is that that standard system configuration makes ensures that one process cannot read the memory of another process

Is it only with objC code or Swift as well ? Xcode 26.5: In new iOS storyboard project I can connect IBOutlets from the Assistant editor in Swift...looks fixed there. Connection bubbles show. But in Objective-C the connection bubbles are completely gone from source files so in ObjC the problem is not fixed, actually worse. You can connect from the Connections Inspector though, but Xcode won't display connection status in ObjC source. So for me, because I still use ObjC the problem is worse. Hope that's not intentional. That would be very very negative evolution. You mean typing xibs by hand doesn't make you more productive!? 😂

Not AI, but just someone who missed that part of your post. I'm glad you've already found a workaround. I can't speak to what a real fix for this would look like, but your theories sound reasonable and I'll make sure to pass those along to the relevant teams! Thanks for reporting and using Previews!

Your collectionBehavior is close — canJoinAllApplications is the right option for spanning other apps' Spaces — but two other pieces are missing for floating above full-screen apps: 1. Accessory activation policy. macOS doesn't layer regular foreground apps above other apps' full-screen Spaces. Overlay utilities like DropOver use NSApplicationActivationPolicyAccessory, which removes the Dock icon and app menu bar (most overlay utilities add a menu bar status item in their place) and lets the app's windows appear above full-screen content from other apps. In your app delegate's applicationDidFinishLaunching: NSApp.setActivationPolicy(.accessory) 2. NSPanel with .nonactivatingPanel. An NSWindow activates its app when ordered front, which can cause a full-screen app to exit its Space. An NSPanel with the .nonactivatingPanel style mask doesn't. Full panel setup: let panel = NSPanel( contentRect: NSRect(x: 200, y: 200, width: 260, height: 140), styleMask: [.nonactivatingPanel, .titled, .closable], backing

It depends what you mean by “production”. Ad hoc is still distribution signing, so it can share production-like pieces such as the Apple Distribution certificate and production APNs environment. But it does not use the same App Store/TestFlight provisioning profile class. In our Bitrise setup, ad hoc export uses distribution_method: ad-hoc, while TestFlight/App Store export uses distribution_method: app-store. Bitrise and Apple docs both say ad hoc export uses an Ad Hoc provisioning profile tied to registered device UDIDs; App Store/TestFlight export uses an App Store Connect provisioning profile. So ad hoc working is encouraging, but it does not prove AppStore installs are safe.

Ad hoc working is encouraging at least, doesn't that use the production version of the provisioning profile?

Ahhhhh this is one of those brain loops I go on every few years. Right after posting I re-remembered at least part of the potential answer when I go down this route: There is at least one (potential) improvement in the XPC case, because while the XPC service might be running with elevated privileges/entitlements it might not expose full access to those. I.e. imagine an XPC service that gets installed as a system daemon to idk… delete another user's account, say. So it exposes an interface with one method, which takes the unfortunate user's name as a string and does the deed via its own root-esque privileges. Now, if the main app is compromised the damage is at least somewhat contained. Barring a further vulnerability in the XPC daemon it can only delete user accounts. Not that that's great, but at least it can't also delete applications (barring path traversal bugs…) or reconfigure printers or install its own persistent privileged daemons…. exploit vulnerability in main process arbitrary execution there pick

Hello App Review Team, We respectfully ask for your assistance regarding our app review status. Our submission was re-submitted on April 29, 2026, and it has now been waiting for review for more than 12 days without any update or response. This situation is now seriously impacting our planned product launch, business operations, and partner commitments. We sincerely ask if the App Review Team could please help: Review the current submission status Escalate the case internally if possible Help move the review process forward Reference Information: Case Number: 102877213113 Submission ID: 68850cef-1651-40c8-b717-7916b679a467 We would greatly appreciate any assistance or update regarding this matter. Thank you very much.

For storefronts configured to use EU External Purchase, could you please clarify whether it is acceptable to use Product.products(for:) solely to retrieve localized product metadata for display(without offering or initiating any IAP purchase flow)?