An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

General: Forums topic: Privacy & Security Forums tag: Privacy Developer > Security — This also covers privacy topics. App privacy details on the App Store UIKit > Protecting the User’s Privacy documentation Bundle Resources > Privacy manifest files documentation TN3181 Debugging an invalid privacy manifest technote TN3182 Adding privacy tracking keys to your privacy manifest technote TN3183 Adding required reason API entries to your privacy manifest technote TN3184 Adding data collection details to your privacy manifest technote TN3179 Understanding local network privacy technote Handling ITMS-91061: Missing privacy manifest forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi, We've implemented age assurance logic in our app using the DeclaredAgeRange framework to comply with regulations in Brazil (Digital ECA, effective March 17, 2026) and Utah (App Store Accountability Act, effective May 6, 2026). Our implementation calls AgeRangeService.shared.isEligibleForAgeFeatures on app launch to determine whether the current user is subject to age assurance requirements, and proceeds to call requestAgeRange(ageGates:) accordingly. However, after monitoring in production since the Brazil enforcement date, we've consistently observed isEligibleForAgeFeatures returning false for users in regulated regions, with no age range data being returned. What we'd like to clarify: Is isEligibleForAgeFeatures currently returning true for users in Brazil in production (not sandbox)? For Utah — given that HB 498 pushed the developer compliance deadline to May 6, 2027, will isEligibleForAgeFeatures reflect the original May 6, 2026 activation date or the revised 2027 date? Is there a known rollout schedule or gradual activation plan for these regions that would explain why the flag remains false even after the legal enforcement dates have passed? We've seen similar reports from other developers on these forums, so it seems this may be a widespread issue rather than an implementation problem on our end. Any official guidance on the current status of the API in regulated regions would be greatly appreciated. Thanks.

My app needs both Accessibility and Input Monitoring permissions. Accessibility works as expected - calling AXIsProcesstrusted() automatically adds the app to System Settings > Privacy & Security > Accessibility, and the user just needs to toggle it on. Input Monitoring doesn't behave the same way. I'm calling CGRequestListenEventAccess() and creating a CGEvent.tapCreate(.listenOnly), but the app doesn't reliably appear in the Input Monitoring list. The user opens the pane and sees nothing to enable. What I've tried: CGRequestListenEventAccess() — shows the system prompt once per install, but doesn't always add the app to the list CGEvet.tapCreate(tsp: .cgSessionEventTap, place: .headInsertEventTap, options: listenOnly, ...) — returns nil before Accessibility is granted; after Accessibility is granted, the tap succeeds but the app still may not appear in the Input Monitoring list Calling both after Accessibility is confirmed, with a delay before opening the Settings pane The flow: User grants Accessibility (app appears automatically via AXIsProcessTrusted()) App creates a listen-only CGEventTap (succeeds) App opens x-apple.systempreferences:com.apple.preferences.security?Privacy_ListenEvent User sees the Input Monitoring pane but the app is not listed Environment: macOS 15, signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable). Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list? Or is there a specific entitlement, Info.plist key, or sequence of calls required on macOS 14+/15 to ensure the app appears?

in iOS26.4, after installing the app for the first time, opening the app and clicking on the UITextField input box will trigger the system to pop up the network permission application interface. This issue did not exist before iOS 26.3, only in iOS 26.4. This is a fatal bug where the network permission request box should not pop up when the developer has not called the network related API.

Hi, I'm the developer of Mail Signature (MAS, bundle ID: de.metaflash.mail-signature), a Mac app that uses iCloud Drive to sync email signatures. On macOS Tahoe, when a user denies the iCloud access permission dialog on first launch, there is absolutely no way to reverse that decision through System Settings. Regression from Sequoia: On Sequoia, after denying iCloud access, the app correctly appears under System Settings → Privacy & Security → Files and Folders where the user can toggle access back on. On Tahoe, the app does not appear anywhere in Privacy & Security after denial – not under Files and Folders, not under Apple ID → iCloud, nowhere. Technical details: Affected TCC services: kTCCServiceUbiquity + kTCCServiceLiverpool tccutil reset Ubiquity alone is insufficient Only tccutil reset All triggers the dialog again This suggests both services need to be reset simultaneously Impact: Normal users are permanently locked out with zero recovery path. The only workaround is Terminal: tccutil reset All de.metaflash.mail-signature ...which is completely inaccessible to average consumers. As a MAS developer we have no way to help users programmatically: exec/child_process → sandbox blocked NSUserUnixTask → designed for user-supplied scripts only, not reliable here Apple Events to Terminal → blocked or App Review risk Feedback submitted: FB22746525 Is anyone else seeing this? Would appreciate dups on the Feedback report. Any workaround suggestions from DTS welcome.

In iOS 18, requesting Contacts access via CNContactStore.requestAccess(for:) triggers a two-stage authorization flow: First stage: the standard "Allow / Don't Allow" alert Second stage: a sheet titled "How do you want to share contacts?" with two options — "Select Contacts" and "Share All [N] Contacts" My question is about the second-stage sheet specifically. It does not appear to have a Cancel or Close button, and swipe-down to dismiss does not work on the devices I've tested (iOS 18.x). If a user reaches this second prompt and decides they don't want to choose either option, how are they expected to dismiss it? Is this intentional behavior?

Hi everyone, We are working on an app that requires access to devices on the local network (Bonjour / LAN discovery + direct socket communication). We are currently struggling with the Local Network privacy permission flow introduced by Apple. From our understanding, there is no dedicated public API to explicitly request Local Network permission or to reliably determine the current authorization state before attempting network activity. We have tried several commonly suggested approaches to trigger the permission dialog, including: Bonjour browsing via NWBrowser Publishing/listening with NetService UDP/TCP socket attempts on local subnet NWConnection / NWListener Triggering discovery after app launch and after foreground transitions We already added the required entries in: NSLocalNetworkUsageDescription NSBonjourServices However, the behavior is inconsistent across devices and OS versions: Sometimes the popup appears immediately Sometimes it never appears Sometimes network operations silently fail without callback clarity In some cases callbacks are delayed or ambiguous Reinstalling/resetting permissions changes behavior unpredictably Our main challenges are: What is currently considered the most reliable Apple-approved method to trigger the Local Network permission prompt? Is there any officially recommended way to determine whether permission is: not determined denied granted Is there any reliable callback or state transition API developers should use? Are there known differences between: NWBrowser NetService BSD sockets NWConnection when it comes to triggering the permission dialog? Are there recommended retry/timing patterns to avoid race conditions during app launch? Is Apple planning to introduce a dedicated authorization API similar to: AVAuthorizationStatus CLAuthorizationStatus PHPhotoLibrary.authorizationStatus() Right now it feels difficult to provide a reliable UX because there is no deterministic way to: proactively request access observe authorization state recover gracefully when the prompt does not appear Any guidance, DTS references, WWDC sessions, or recommended implementation patterns would be greatly appreciated. Thanks!

I have an application that is a VOIP application of sorts that needs access to the microphone. I am using the Mac (Designed for iPad) support to not have to do huge amounts of conditional building and support for all the many iOS specific things my app includes. I never get prompted to allow microphone permissions and I never see my app name appear in Privacy & Security -> Microphone permissions setup. So is it that Mac is just a dead end for any form of an application that needs a microphone and is running under Mac (Designed for iPad) compatibility mode? Why doesn't TCC have some mechanism to notice and grant access to mic use?

Hello Everyone I'm encountering a problem with the Apple Mail Private. I created a website with the possibility to log in with apple account and apple gives the possibility to privatize the mail address with xxxxx@privaterelay. appleid.com but also blocked the mail come from my server. In the log I get the error: relay=smtp3.privaterelay. appleid.com[17.56.9.14]:25, delay=2.4, delays=0.11/0/1.8/0.48, dsn=5.1.1, status=bounced (host smtp3.privaterelay. appleid.com[17.56.9.14] said: 550 5.1.1 mymail@mail. com: unauthorized sender (in reply to RCPT TO command)) How can I fix it ?

Hi everyone, We are investigating a possible iOS permission state issue after a device previously installed our app through TestFlight and later installed the production version from the App Store using the same Bundle ID. Environment: Device: iPhone 15 iOS version: 26.2.1 App distribution history: The app was previously installed through TestFlight and later installed from the App Store Permissions involved: Camera / Photos Issue: When the user opens the App Store version of the app and tries to access a feature that requires Camera or Photos permission, the iOS permission prompt does not appear as expected. Also, the app does not appear under: Settings > Privacy & Security > Camera or: Settings > Privacy & Security > Photos Because of this, the user cannot manually enable the permission. Another user on iOS was able to grant the permissions normally, so the issue appears to be isolated to the device that previously used the TestFlight build. Expected behavior: When the App Store version requests Camera or Photos permission, iOS should display the permission prompt, or the app should appear under Settings > Privacy & Security > Camera/Photos so the user can manage the permission manually. Actual behavior: The permission prompt does not appear, and the app does not appear in the corresponding privacy permission list. Possible cause: It seems like the device may be preserving or reusing a stale privacy permission state from the previous TestFlight installation, since both the TestFlight build and the App Store build use the same Bundle ID. Steps to reproduce: Install the app through TestFlight. Open the app and trigger a Camera/Photos permission request. Grant or deny the permission. Stop testing or remove the TestFlight version. Install the production version from the App Store using the same Bundle ID. Open the App Store version. Trigger the same Camera/Photos permission request flow. Go to Settings > Privacy & Security > Camera/Photos. The app does not appear, or the permission prompt does not behave as expected. Workarounds attempted or suggested: Close and reopen the app. Restart the iPhone. Delete and reinstall the app from the App Store. Stop testing the app from TestFlight. Reset Location & Privacy settings. Question: Has anyone experienced a similar issue where iOS does not show the permission prompt or does not list the app under Privacy & Security after switching from a TestFlight build to the App Store version with the same Bundle ID? Is there a recommended way to fully clear the previous TestFlight permission state, or should this be reported as a possible iOS/TestFlight permission state bug?

Apps that try to access the contents of the pasteboard cause a system prompt to appear asking the user "AppName" would like to paste from "OtherAppName" Do you want to allow this? Don't Allow Paste Allow Paste This prompt does not appear if you implement a UIPasteControl and the user taps it to signal intent to paste, but this control cannot be placed into a UIMenu. I read this could be achieved with UIAction.Identifiers like .paste or .newFromPasteboard but the prompt still appears with the following code. What's the trick? override func viewDidLoad() { super.viewDidLoad() title = "TestPaste" view.backgroundColor = .systemBackground let imageView = UIImageView() imageView.translatesAutoresizingMaskIntoConstraints = false imageView.contentMode = .scaleAspectFit imageView.clipsToBounds = true view.addSubview(imageView) NSLayoutConstraint.activate([ imageView.topAnchor.constraint(equalTo: view.topAnchor), imageView.leadingAnchor.constraint(equalTo: view.leadingAnchor), imageView.trailingAnchor.constraint(equalTo: view.trailingAnchor), imageView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) navigationItem.rightBarButtonItem = UIBarButtonItem(title: "Add", image: UIImage(systemName: "plus"), menu: UIMenu(children: [ UIAction(identifier: .paste) { _ in imageView.image = UIPasteboard.general.image } ])) }

We use TeamCity as our Continuous Integration (CI) solution to build and run automated tests. These are integration tests executed through our 4D application, which is properly code‑signed and notarized. These CI machines are heavily used and build multiple versions per day, making them critical to our development workflow. However, we are experiencing an issue on some machines: after a certain period of time, network communication through our application stops working, while network communication remains fully functional when using third‑party tools (for example, LDAP clients). Based on our investigation, this issue appears to be related to Local Network Privacy management. We have followed the procedure described in Apple’s Technical Note: TN3179: Understanding local network privacy | Apple Developer Documentation to reset network authorizations, but this has not been sufficient to resolve the issue. In addition, our CI environment requires acknowledging a large number of Local Network access permission prompts. Given that these machines build multiple versions per day and are intended to run unattended, this is not practical in an automated CI context. We have around ten Macs dedicated to running these tests, and manually approving these pop‑ups is not a viable solution.

Dear TestFlight Team! I am observing an increasing misuse of TestFlight public and private invites to distribute scam, spam, and potentially malicious builds: I had reported this already in December last year via Feedback assistant, but since the malicious behavior has not stopped, I hope that you can forward my bug reports to the right team: FB21379977, FB21845307 In multiple cases, these builds impersonate well-known apps (e.g. ChatGPT, OpenAI, Meta) by changing the app name and icon after an initial TestFlight approval, misleading users into installing software from unrelated developer accounts. I believe this represents a systemic weakness in the TestFlight review and update flow, enabling targeted phishing or malware distribution outside the App Store review process. My bug reports have attached: TestFlight invitation emails (.eml) Screenshots from TestFlight documenting impersonation behavior ⸻ Steps to reproduce Create a new Apple Developer account. Upload an initial, benign app (e.g. a calculator) as version 1.0.0 and obtain TestFlight approval. Upload a second build: without changing the version number increase build number Change the app name to a well-known product (e.g. “ChatGPT”) Change the app icon to match the impersonated product Invite targeted email addresses to the TestFlight group. Recipients receive an official TestFlight invite and are prompted to install the impersonating app. ⸻ Expected results TestFlight builds that significantly change app identity (name, icon, branding) should: Require additional review, or Be blocked from distribution without re-approval. Developer accounts should not be able to impersonate well-known companies (e.g. “OpenAI Platforms LLC”) without verification. Users should be protected from installing TestFlight builds that materially differ from what was originally reviewed. ⸻ Actual results App name and icon can be changed between TestFlight builds without triggering additional review. TestFlight invites can convincingly impersonate trusted brands. Targeted users may reasonably believe they are installing a legitimate beta. This creates a credible vector for: Phishing (credentials, payment details) Data exfiltration Social engineering attacks I did not install the builds to avoid personal risk, but the attached artifacts should allow Apple’s internal teams to reproduce and analyze the behavior safely. Some more examples:

I was planning to add the Facebook SDK in one of the releases, and I had everything prepared (including changing the privacy policy to state that my app tracks users for advertising). I changed the privacy policy in the App Store connect, thinking that this wouldn't take effect until I sent the app to review. However, after careful consideration, I decided not to move on with the Facebook SDK. My app does not currently track users for advertising. Even though I sent a new release (UI improvements only), I still can't change the privacy policy to remove that my app "tracks" the user. I read multiple posts with people facing similar issues. For my binary, I have: No PrivacyInfo.xcprivacy file NSUserTrackingUsageDescription in Info.plist No tracking declarations in my app configuration I contacted support, and I was redirected here. My case number is 102778907920

Dear Screen Time Team! The Screen Time passcode can be brute-forced without rate limiting by repeatedly attempting guesses through the "Erase All Content and Settings" flow. This allows unlimited passcode attempts with no delay, lockout, or escalation, effectively defeating the purpose of the Screen Time passcode as a parental control mechanism. Impact: Children can bypass Screen Time protections by guessing the passcode No rate limiting enables trivial brute-force attacks (especially for 4-digit codes) Undermines trust in Screen Time as a parental control system Creates real-world safety risks for families relying on Screen Time restrictions Publicly shared methods (e.g. on TikTok) increase likelihood of widespread abuse Steps to Reproduce: Enable Screen Time and set a passcode Open Settings → General → Transfer or Reset iPhone → Erase All Content and Settings When prompted for the Screen Time passcode, enter an incorrect code Repeat the process with different guesses Expected Result: After a small number of incorrect attempts, the system should: enforce exponential backoff delays, or temporarily lock further attempts, or require Apple ID authentication Attempts should be rate-limited across system flows Actual Result: Unlimited passcode attempts are allowed No delay, lockout, or penalty is applied Enables rapid brute-force guessing of the Screen Time passcode Notes: This appears to bypass standard passcode protections that exist in other parts of iOS The issue is especially severe for 4-digit Screen Time passcodes (10,000 combinations) The attack surface is exposed through a system-level reset flow Suggested Fix: Introduce global rate limiting for Screen Time passcode attempts across all entry points Apply exponential backoff after failed attempts Require Apple ID authentication after multiple failures Consider enforcing 6-digit minimum passcodes for Screen Time Log and unify attempt counters across system components Severity: Critical (Security vulnerability enabling brute-force of parental control passcode) See TikTok: https://www.tiktok.com/@aldanaisthebest12170/video/7615053429500644621 Feedback request: FB22263276 – Frederik (one sec app)

Hi, we have an app which used DeviceID to track users. We had implemented ATT and setup our privacy declaration in ASC accordingly. Now in our new version we decided to not track users anymore. We removed NSUserTrackingUsageDescription, removed ATT permission code and submitted the new version. Now, reviewer has complained that our privacy declaration in ASC still says we are tracking users and refused app acceptance. They told us to update the privacy declaration in ASC. We tried to do so, but ASC does not allow us to remove device ID tracking. It is showing a warning that our app still uses NSUserTrackingUsageDescription and in fact that is true for the production version. We are now in a chicken egg problem. We can't change our privacy declaration in ASC because the production version still uses the feature AND we do not get the new version accepted as long as our privacy declaration is not changed. How can we fix that ? Pls advise !

I am doing my app for review to publish for the first time, and I did multiple fixes. I lastly got a generic response for the fixes already done. Now unable to figure out what exactly to fix. Can any help be provided by the reply below I received [Apple Reply] Guidelines 5.1.1(i) - Legal - Privacy - Data Collection and 5.1.2(i) - Legal - Privacy - Data Use Issue Description The app appears to share the user’s personal data with a third-party AI service but the app still does not clearly explain what data is sent, identify who the data is sent to, and ask the user’s permission before sharing the data. Apps may only use, transmit, or share personal data after they meet all of the following requirements: Disclose what data will be sent Specify who the data is sent to Obtain the user’s permission before sending data Identify in the privacy policy what data the app collects, how it collects that data, all uses of that data, and confirm any third party the app shares data with provides the same or equal protection Next Steps If the app sends user data to a third-party AI service, revise the app to explain what data is sent, identify who the data is sent to, and ask the user’s permission before sharing personal data with a third-party AI service. If it does not already, the app’s privacy policy must also identify what data the app collects, how it collects that data, and all uses of that data, including if it is shared with a third-party AI service. Note that only including this information in the app's Terms of Service or Privacy Policy is not sufficient. If the app does not send user data to a third-party AI service or does not include a third-party AI service, reply to this rejection to confirm and add this information to the App Review Information section of App Store Connect.

We’re having an iPad issue accessing the local network with iPadOS 26.3. We have an automation system that tests our app on an iPad using accessibility tags. the XCTest test code sends messages from the iPad via TCP/IP to setup external test equipment. The messages abruptly stopped transmitting across the iPad blood-brain barrier with iPadOS 26.3 (26.2.1 and earlier works fine). The technique that worked involved installing a helper app with the same bundleID as our app, allowing the helper app to access the network, and when our app runs it has network access through the helper. It’s clever and kludgey. Forums that we referenced in the past: https://developer.apple.com/forums/thread/663858 TN3179: Understanding local network privacy | Apple Developer Documentation I suspect that something was changed in 26.3 that closed our window. I need two things: ID what is different in 26.3 and fix the automation system. If there’s a new way for XCUITest code to access the local network I’m happy to try it out.

Hi, We’re building an iOS app that uses the Screen Time APIs (FamilyControls and DeviceActivity) to display a user’s own usage metrics inside the app. With the appropriate permissions granted, we are successfully reading and presenting metrics such as: Total screen time Device pickups These metrics are already visible to the user inside our app. We would now like to introduce a user-initiated “Share” feature. The idea is to: Render selected Screen Time metrics into a shareable image card generated locally on device. Present the standard iOS share sheet (UIActivityViewController). Allow the user to share that image to Messages, social apps, etc., if they choose. Important clarifications: This is fully user-initiated. The app does not automatically transmit Screen Time data. The metrics are already displayed in-app with user permission. The share asset would be generated locally. No background export or server-side posting would occur unless explicitly triggered by the user via the share sheet. We are seeking clarification on whether there are any policy or API restrictions around: Rendering Screen Time-derived metrics into a user-facing share card Allowing user-initiated export of those metrics via the standard iOS share flow Are there any additional privacy requirements, entitlement constraints, or App Review considerations we should be aware of when implementing this? Thanks in advance for any guidance.

Summary I'm implementing NEURLFilter with the com.apple.developer.networking.networkextension.url-filter-provider entitlement for a system-wide URL filtering feature. The feature works perfectly in development-signed builds (connecting successfully to my PIR server over extended testing) but every production-signed build fails before any network call is made. NEURLFilterManager reports .serverSetupIncomplete (code 9). After installing the NetworkExtension debug profile, the unredacted com.apple.CipherML logs reveal the cause: no privacy proxy is provisioned for this bundle identifier, and the connection is configured proxy fail closed. Environment iOS 26 Entitlement: com.apple.developer.networking.networkextension.url-filter-provider Extension point: com.apple.networkextension.url-filter-control PIR server configured via NEURLFilterManager.setConfiguration(...) Privacy Pass issuer configured Dev-signed builds: working correctly, connecting to the PIR server Production-signed builds (both TestFlight and distribution): failing identically The Error Chain Surfaced to the app via NEURLFilterManager.lastDisconnectError: NEURLFilterManager.Error.serverSetupIncomplete (code 9) ← NEAgentURLFilterErrorDomain Code 3 ← com.apple.CipherML Code 1100 "Unable to query status" ← com.apple.CipherML Code 1800 (error details were logged and redacted) After installing the VPN (NetworkExtension) debug profile, the unredacted com.apple.CipherML subsystem shows: queryStatus(for:options:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={ _NSURLErrorNWPathKey = satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey = https://<my-pir-server>/config, NSUnderlyingError = { Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" }, _NSURLErrorPrivacyProxyFailureKey = true, NSLocalizedDescription = "The Internet connection appears to be offline." } The critical diagnostic line in the com.apple.network subsystem is: nw_endpoint_proxy_handler_should_use_proxy Proxies not present, but required to fail closed And the connection setup shows the proxy fail closed flag is mandatory for the connection: [C... ... Hostname#...:443 quic, bundle id: <my-bundle-id>, attribution: developer, using ephemeral configuration, context: NWURLSession (sensitive), proxy fail closed] start The network path itself is healthy (Wi-Fi good, DNS resolves correctly), but the connection is explicitly configured to fail closed if no proxy is present, and no proxy is provisioned for this bundle identifier. The entire failure happens in approximately 18 ms, far too fast for any network round-trip, confirming no traffic ever leaves the device. What I've Verified The entitlement is present in the distribution build The NEURLFilterControlProvider extension loads and returns a valid Bloom filter prefilter (with a tag that round-trips correctly between extension and framework) NEURLFilterManager.setConfiguration(pirServerURL:pirPrivacyPassIssuerURL:pirAuthenticationToken:controlProviderBundleIdentifier:) accepts all four parameters without error Development-signed builds of the same bundle identifier connect successfully to the same PIR server On production-signed builds, zero requests reach the PIR server — failure is purely client-side, before any network activity The Question How does the OHTTP privacy proxy get provisioned for a bundle identifier so that production builds can successfully use NEURLFilter? Specifically: Is there a Capability Request form I need to submit for url-filter-provider? I cannot find one in the Capability Requests section of my developer portal. Should I be running my own OHTTP gateway (for example using swift-nio-oblivious-http), and if so, does Apple then need to provision routing from their OHTTP relay to my gateway URL? Is the OHTTP relay path meant to be automatic once the entitlement is active, and if so, is there a specific activation step I'm missing? Is there any way to verify the current provisioning state for a specific bundle identifier from the developer portal? I can provide the full sysdiagnose and unredacted bundle/server details privately to an Apple engineer if that would help diagnose. I'd prefer to keep them out of a public post. Thanks!

I need to bring attention to a very suspicious "copycat" incident that suggests a potential metadata scraping issue. I submitted my original sports insights app, KickPick, for review on April 2nd, 2024. To my shock, I discovered a competitor app already live on the store with same app name and nearly identical app information (descriptions, metadata) and a very similar UI structure. Domain Registration: The infringing developer registered their website domain on the exact same day I submitted my app for review (April 2nd). This is not a coincidence; it points to automated monitoring or scraping of new submissions/metadata. Plagiarized Legal Assets: While the UI has some variations, they have copied my Privacy Policy and Terms of Service verbatim. These documents were custom-written for my specific project logic, yet they appear on their site with only the company name changed. App Information: The app descriptions and store metadata are almost identical to what I provided in my pending submission. It is highly concerning that an original creator's work, is being "front-run" by a low-effort clone that appears on the store exactly when the original is submitted. I have filed a formal Rights Infringement report, but I want to ask the community: Has anyone else noticed clones popping up with domains registered on their exact submission date?