“missing package product”

I’m working on a product that includes TLS inspection capability. TLS inspection using a local MitM requires installing a trusted root certificate which is then used to create masquerade certificates to intercept and forward TLS traffic through the proxy. For manual installation the end user is required to authenticate as an administrator to modify the trust settings on our internal CA’s root certificate. My question concerns the options for enterprise deployment using an MDM. We want the generated root certificate to be unique to each endpoint so that if a private key is compromised it can’t be used to intercept traffic anywhere else. We can install a “certificate trust” configuration profile from the MDM but this requires a base64 encoded string of the root certificate. In effect the MDM needs to obtain the certificate from the endpoint and then send it back in the form of a configuration profile. I’m not aware that MDMs like Jamf can be configured to do this directly so we’re looking for any other

Hi Apple Developer Community, Since March 16, 2026, our integration with the Apple Ads Campaign Management API (v5) is returning 403 Forbidden on all GET requests to the custom-reports endpoint, while POST requests to create reports continue to work without any issues. Environment API Version: v5 Base URL: https://api.searchads.apple.com/api/v5/ Authentication: OAuth 2.0 (Bearer token — token generation works fine) API User Role: API Account Manager What's broken GET /api/v5/custom-reports/63638557 → 403 Forbidden The response is raw HTML from Apple's gateway, not a JSON API error: 403 Forbidden 403 Forbidden Apple This indicates the request is being blocked at the reverse proxy / infrastructure level and never reaches the API application layer. A proper API-level authorization error would return JSON with messageCode and message fields. What still works POST creates report successfully POST /api/v5/custom-reports → 200 OK Response: { data: { id: 63638557, name: Impression_Share_Report_2026-03-22_daily, s

I encountered an error when trying to rollback context after deleting some model with multiple one-to-many relationships when encountered a problem later in a deleting method and before saving the changes. Something like this: do { // Fetch model modelContext.delete(model) // Do some async work that potentially throws try modelContext.save() } catch { modelContext.rollback() } When relationship is empty - the parent has no children - I can safely delete and rollback with no issues. However, when there is even one child when I call even this code: modelContext.delete(someModel) modelContext.rollback() I'm getting a fatal error: SwiftData/ModelSnapshot.swift:46: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData I use ModelContext from within the ModelActor but using mainContext changes nothing. My ModelContainer is quite simple and problem occurs on both in-memory and persistent storage, with or without CloudKit database being enabled. I can isolate the issue in test e

Precondition: In system settings, scale the pointer size up to the max. Our SCScreenshotManager code currently works in macOS 15 and earlier to capture the cursor at it's larger size, but broke in one of the minor releases of macOS Tahoe. The error it produces now is Failed to start stream due to audio/video capture failure. This only seems to happen with the cursor window, not any others. Another way to get the cursor is with https://developer.apple.com/documentation/appkit/nscursor/currentsystem, but that is now deprecated, which makes me think the capture of the cursor is being blocked deliberately. We see this as a critical loss of functionality for our apps, and could use guidance on what to use instead.

Hi Apple Developer Support, We are reaching out to request guidance on a testing constraint we have encountered related to iOS Universal Links and Associated Domains entitlements. As part of aligning with updated recommendations from our authentication provider, we have transitioned our mobile apps to use HTTPS redirect callbacks (Universal Links) instead of custom URI schemes. This works as expected in production and on real physical devices. However, we are encountering a significant issue in our cloud-based device testing environment. When our testing platform re-signs the app to run it on their infrastructure, the re-signing process strips the Associated Domains entitlement from the app bundle. As a result, iOS no longer honors our Universal Links, which breaks the authentication redirect flow — the callback cannot route back into the app after the user authenticates. We have identified a potential workaround that would involve disabling app re-signing in the testing platform, but this requires p

My team is evaluating an iOS companion app for our own network-connected device, and we want to understand whether the planned architecture would likely create an App Review problem under Guideline 2.5.17. Our situation is: We are building our own device and our own companion app. We do not intend to market the device as a Matter-certified device initially. We do not intend to support Apple Home or broad third-party Matter ecosystem interoperability in the first release. We are under a tight schedule and are considering reusing Matter/CSA-derived libraries, data models, and protocol concepts internally to reduce engineering effort and move faster toward eventual certification. Our current understanding is that there are already many iOS apps that communicate with LAN-connected devices using proprietary protocols, so our initial assumption is that a vendor-specific local-network device workflow should generally be acceptable. The point we are trying to clarify is whether that changes if the implementation unde