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"

App Store Connect's privacy label system creates impossible review situations by checking live app versions instead of submitted builds. Problem: Developer has a live app with tracking on the App Store Developer create a new app version with all tracking removed Privacy labels from AppStore Connect cannot be updated because system references live version with tracking App gets rejected for privacy label mismatch with submitted build Cannot fix labels until approved, cannot get approved with wrong labels Expected behavior: Privacy label system should allow updates for pending app versions or check submitted build instead of live version. Steps to reproduce: Submit app update with tracking removed Try to update privacy labels to "no tracking" from AppStore Connect System shows error: "Your app contains NSUserTrackingUsageDescription, indicating that you will request permission to track users. You must indicate which data types are tracking users. If this is incorrect, update your app binary and upload a new build to App Store Connect." App gets rejected despite submitted build having no tracking This affects any developer trying to remove tracking functionality from AppStore Connect in such a scenario. I have opened a bug in Feedback Assistant: FB19459680

Hi everyone, I'm facing a frustrating App Store rejection that I can't seem to resolve. My app was rejected under Guideline 2.1 - Information Needed with the following message: "The app uses the AppTrackingTransparency framework, but we are unable to locate the App Tracking Transparency permission request when reviewed on iPadOS 18.5." However, in my latest version (2.9 Build 18), I have: Removed all SDKs that collect IDFA or perform tracking. Removed the AppTrackingTransparency framework entirely. Removed the NSUserTrackingUsageDescription key from Info.plist. Confirmed that no third-party SDKs are accessing IDFA or similar. Not using the app_tracking_transparency package (I'm using Flutter). I included a detailed review note explaining all of this, yet the app still gets rejected for not showing the ATT prompt — even though ATT is not used at all. Also, I can't update the App Privacy section until this new version is approved, which still reflects tracking from a previous live version (2.3). Has anyone faced something similar? Questions: Is there a way to confirm what part of the build might still be triggering ATT detection on Apple's side? Could an unused pod or leftover reference be the issue? How do I fully verify that ATT is not linked anywhere in the final binary? Any guidance or tips from others who’ve resolved this would be hugely appreciated! Thanks

Hi everyone, I have a macOS application that uses Screen Recording permission. I build my app with an adhoc signature (not with a Developer ID certificate). For example, in version 1.0.0, I grant Screen Recording permission to the app. Later, I build a new version (1.1.0) and update by dragging the new app into the Applications folder to overwrite the previous one. However, when I launch the updated app, it asks for Screen Recording permission again, even though I have already granted it for the previous version. I don’t fully understand how TCC (Transparency, Consent, and Control) determines when permissions need to be re-granted. Can anyone explain how TCC manages permissions for updated builds, especially with adhoc signatures? Is there any way to retain permissions between updates, or any best practices to avoid having users re-authorize permissions after every update?

Hey there! So, I'm trying to see what I'm able to do with the Device Activity Report Extension, and I have a few questions about the following quote: To protect the user’s privacy, your extension runs in a sandbox. This sandbox prevents your extension from making network requests or moving sensitive content outside the extension’s address space. In particular, what constitutes the address space for this extension? Can I save data to a UserDefaults object that only the extension can access? (Apps like Opal allow the user to label apps as "distracting" and "non-distracting", and I'm wondering how they do that!) From what I've read, I believe it cannot write to a shared app group or model (and I just want to confirm this) It also seems that there's nothing preventing it from reading data from the main app, so I'm just wondering if it's able to read data from an app group or model with no problem. Thanks in advance!

Hello everyone, Ujjwal here, founder and CEO of a new iOS app in the mental wellness space. Our mission is to provide accessible, AI-driven support for individuals dealing with anxiety, depression, and loneliness. From the very beginning, this has presented us with a unique and critical challenge: How do we effectively market an app to reach those who need it most, while upholding the absolute highest standards of user privacy? We've built our app, ThunDroid, with a "privacy-by-design" philosophy. We leverage on-device processing for our core AI features, utilize end-to-end encryption, and have proudly integrated 'Sign in with Apple' to maximize user anonymity. We believe these are not just features, but ethical obligations to our users, especially given the nature of the data they trust us with. The challenge, however, arises in marketing. This leads us to focus on mission-driven, organic marketing, but it's a slower path to reaching users who might be in immediate need of support. This brings me to my question for this knowledgeable community. What best practices or creative strategies have you found effective for marketing applications? I appreciate any insights or experiences you're willing to share as we continue to grow ThunDroid responsibly. Thank you for your time and consideration. App Store link: (would love to hear your reviews) [https://apps.apple.com/in/app/thundroid-ai-human-companion/id6746182736)

Hi everyone, I’m working on a concept for an iOS app that would allow a user to remotely control an Enterprise iOS device, similar to how AnyDesk or TeamViewer work on desktop. I understand that apps like TeamViewer for iOS offer screen sharing, and some level control but not a full level control. Before I invest further in development, I’d like to clarify a few points: Is there any official Apple-supported way (public or private API) to allow remote control of an iOS device? Has Apple ever approved apps that allow true remote control of iOS (not just screen sharing)? If full control is not allowed, what are the permitted alternatives (e.g. screen broadcast via ReplayKit, remote assistance mode, etc.)? Would such an app be considered for enterprise distribution only (via MDM), or is there a potential App Store path? Any insight or experience from developers who’ve tried this would be very appreciated. Thanks!

For context, my company develops a data loss prevention (DLP) product. Part of our functionality is the ability to detect sensitive data being pasted into a web browser or cloud-based app. The AppKit release notes for April 2025 document an upcoming “macOS pasteboard privacy” feature, which will presumably ship in macOS 26. Using the user default setting “EnablePasteboardPrivacyDeveloperPreview” documented in the release notes, I tested our agent under macOS 15.5, and encountered a modal alert reading " is trying to access the pasteboard" almost immediately, when the program reads the General pasteboard to scan its contents. Since our product is aimed at enterprise customers (and not individual Mac users), I believed Apple would implement a privacy control setting for this new feature. This would allow our customers to push a configuration profile via MDM, with the “Paste from Other Apps” setting for our application preset to “Allow”, so that they can install our product on their endpoints without manual intervention. Unfortunately, as of macOS 26 beta 4 (25A5316i), there does not seem to be any such setting documented under Device Management — for example in PrivacyPreferencesPolicyControl.Services, which lists a number of similar settings. Without such a setting available, a valuable function of our product will be effectively crippled when macOS 26 is released. Is there such a setting (that I've overlooked)? If not, allow me to urge Apple to find the resources to implement one, so that our customers can preset “Paste from Other Apps” to “Allow” for our application.

Our app is connected to a hardware wifi without network. Under normal circumstances, we can communicate with the device. At some point, the communication suddenly stops, and the ping prompts "No route to host". The only way to reconnect is to restart the device. It feels like the system has marked ARP. Is there any way to reconnect the device without restarting the device?

I am developing an app that communicates with external BLE device over GATT. The device has a secure-read characteristic exposing some of it's data and requires pairing/bonding in order to communicate with it. I was able to pair and connect with the device using AccessorySetupKit and .bluetoothPairingLE option: let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: serviceUUID) descriptor.supportedOptions = [.bluetoothPairingLE] let picketItem = ASPickerDisplayItem(name: name, productImage: image, descriptor: descriptor) In this case when setting up accessory, I was prompted to compare passkeys and after confirming I can read the characteristic etc. Then I tried adding .confirmAuthorization to picker item and problems started: let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: serviceUUID) descriptor.supportedOptions = [.bluetoothPairingLE] let picketItem = ASPickerDisplayItem(name: name, productImage: image, desc pickerItem.setupOptions = [.confirmAuthorization] When setting up, I can see a passkey to be confirmed, but when confirmed the setup ui get's suck in loading state. Under the hood in logs, I can see that my app has connected to peripheral and was able to read the characteristic. I am unsure why the ui is stuck in loading state in this case. What is the difference when using .confirmAuthorization option and what should be the proper flow of events to setup accessory and then access protoected characteristic?

I am developing a macOS application (targeting macOS 13 and later) that is non-sandboxed and needs to install and trust a root certificate by adding it to the System keychain programmatically. I’m fine with prompting the user for admin privileges or password, if needed. So far, I have attempted to execute the following command programmatically from both: A user-level process A root-level process sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.pem While the certificate does get installed, it does not appear as trusted in the Keychain Access app. One more point: The app is not distributed via MDM. App will be distributed out side the app store. Questions: What is the correct way to programmatically install and trust a root certificate in the System keychain? Does this require additional entitlements, signing, or profile configurations? Is it possible outside of MDM management? Any guidance or working samples would be greatly appreciated.

Hello Developer Forums Team, I’ve seen that some banking apps prevent screenshots on certain sensitive screens. I’m working on a similar feature in my SDK and want to confirm if my implementation complies with App Store guidelines. Since there’s no public API to block screenshots, I’m using a workaround based on the secure rendering behavior of UITextField (isSecureTextEntry = true). I embed my custom content (e.g., a UITableView) inside the internal secure container of a UITextField, which results in blank content being captured during screenshots—similar to what some banking apps do. Approach Summary I create a UITextField I detect its internal secure container by matching UIKit internal class names as strings I embed my real UI content into that container I do not use or call any private APIs, just match view class names via strings. ScreenshotPreventingView.swift final class ScreenshotPreventingView: UIView { private let textField = UITextField() private let recognizer = HiddenContainerRecognizer() private var contentView: UIView? public var preventScreenCapture = true { didSet { textField.isSecureTextEntry = preventScreenCapture } } public init(contentView: UIView? = nil) { super.init(frame: .zero) self.contentView = contentView setupUI() } private func setupUI() { guard let container = try? recognizer.getHiddenContainer(from: textField) else { return } addSubview(container) NSLayoutConstraint.activate([ container.topAnchor.constraint(equalTo: topAnchor), container.bottomAnchor.constraint(equalTo: bottomAnchor), container.leadingAnchor.constraint(equalTo: leadingAnchor), container.trailingAnchor.constraint(equalTo: trailingAnchor) ]) if let contentView = contentView { setup(contentView: contentView, in: container) } DispatchQueue.main.async { self.preventScreenCapture = true } } private func setup(contentView: UIView) { self.contentView?.removeFromSuperview() self.contentView = contentView guard let container = hiddenContentContainer else { return } container.addSubview(contentView) container.isUserInteractionEnabled = isUserInteractionEnabled contentView.translatesAutoresizingMaskIntoConstraints = false let bottomConstraint = contentView.bottomAnchor.constraint(equalTo: container.bottomAnchor) bottomConstraint.priority = .required - 1 NSLayoutConstraint.activate([ contentView.leadingAnchor.constraint(equalTo: container.leadingAnchor), contentView.trailingAnchor.constraint(equalTo: container.trailingAnchor), contentView.topAnchor.constraint(equalTo: container.topAnchor), bottomConstraint ]) } } HiddenContainerRecognizer.swift struct HiddenContainerRecognizer { private enum Error: Swift.Error { case unsupportedOSVersion(version: Float) case desiredContainerNotFound(_ containerName: String) } func getHiddenContainer(from view: UIView) throws -> UIView { let containerName = try getHiddenContainerTypeInStringRepresentation() let containers = view.subviews.filter { subview in type(of: subview).description() == containerName } guard let container = containers.first else { throw Error.desiredContainerNotFound(containerName) } return container } private func getHiddenContainerTypeInStringRepresentation() throws -> String { if #available(iOS 15, *) { return "_UITextLayoutCanvasView" } if #available(iOS 14, *) { return "_UITextFieldCanvasView" } if #available(iOS 13, *) { return "_UITextFieldCanvasView" } if #available(iOS 12, *) { return "_UITextFieldContentView" } let currentIOSVersion = (UIDevice.current.systemVersion as NSString).floatValue throw Error.unsupportedOSVersion(version: currentIOSVersion) } } How I use it in my Screen let container = ScreenshotPreventingView() override func viewDidLoad() { super.viewDidLoad() container.preventScreenCapture = true container.setup(contentView: viewContainer) //viewContainer is UIView in storyboard, in which all other UI elements are placed in e.g. UITableView self.view.addSubview(container) container.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ container.topAnchor.constraint(equalTo: self.view.topAnchor), container.bottomAnchor.constraint(equalTo: self.view.bottomAnchor), container.leadingAnchor.constraint(equalTo: self.view.leadingAnchor), container.trailingAnchor.constraint(equalTo: self.view.trailingAnchor) ]) } What I’d Like to Confirm Is this approach acceptable for App Store submission? Is there a more Apple-recommended approach to prevent screen capture of arbitrary UI? Thank you for your help in ensuring compliance.

We have a Java application built for macOS. On the first launch, the application prompts the user to allow local network access. We've correctly added the NSLocalNetworkUsageDescription key to the Info.plist, and the provided description appears in the system prompt. After the user grants permission, the application can successfully connect to a local server using its hostname. However, the issue arises after the system is rebooted. When the application is launched again, macOS does not prompt for local network access a second time—which is expected, as the permission was already granted. Despite this, the application is unable to connect to the local server. It appears the previously granted permission is being ignored after a reboot. A temporary workaround is to manually toggle the Local Network permission off and back on via System Settings &gt; Privacy &amp; Security, which restores connectivity—until the next reboot. This behavior is highly disruptive, both for us and for a significant number of our users. We can reproduce this on multiple systems... The issues started from macOS Sequoia 15.0 By opening the application bundle using "Show Package Contents," we can launch the application via "JavaAppLauncher" without any issues. Once started, the application is able to connect to our server over the local network. This seems to bypass the granted permissions? "JavaAppLauncher" is also been used in our Info.plist file

While I was submitting a new feedback today for an iPhone/iPad storage issue, I saw a new log called “iOS storage log”. I could find no reference to this when I searched online. It made me wonder if it was new and if it contained personal data? Most of us only have one device, with all our personal data. Therefore, I’d appreciate any input on what personal data these logs contain.

Hi Apple Devs & WebKit Team, We operate https://excnum.com — a personal website currently under reconstruction. It's HTTPS-secure, hosted on a clean VPS, and now features a simple placeholder page with no active forms, scripts, or external redirects. However, Safari on both iOS and macOS is flagging it as a “deceptive website”, blocking all access. This warning appears even though: The site uses a valid SSL certificate via Cloudflare There are no redirects, tracking scripts, or dynamic code We serve a static landing page (“under maintenance”) with zero interaction No malware, phishing, or obfuscation exists — verified with multiple tools A review request has already been submitted at: https://websitereview.apple.com We believe the site may have been blacklisted previously under past ownership or prior configurations. It has since been completely restructured and cleared, but the Safari warning persists. This false flag is harming visibility and trust for an otherwise neutral website. Any advice on how to expedite re-evaluation or request a manual delisting from the deceptive site list would be much appreciated. Thank you! — Alex Admin, EXCNUM.COM

I've developed a Mac app distributed through the App Store that uses NSAppleScript to control Spotify and Apple Music. I'm experiencing inconsistent behavior with automation permission prompts that's affecting user experience. Expected Behavior: When my app first attempts to send Apple Events to Spotify or Apple Music, macOS should display the automation permission prompt, and upon user approval, the app should appear in System Preferences &gt; Security &amp; Privacy &gt; Privacy &gt; Automation. Actual Behavior: Initial permission prompts work correctly when both apps are actively used after my app download. If a user hasn't launched Spotify/Apple Music for an extended period, the permission prompt fails to appear when they later open the music app. The music app doesn't appear in the Automation privacy pane too. Once this happens, permission prompts never trigger again for that app Steps to Reproduce: Fresh install of my app Don't use Spotify for several days/weeks Launch Spotify Trigger Apple Events from my app to Spotify No permission prompt appears, app doesn't show in Automation settings If you're using Apple Music during this time it runs without any problems. Troubleshooting Attempted: Used tccutil reset AppleEvents [bundle-identifier] - no effect Verified target apps are fully launched before sending Apple Events Tried different AppleScript commands to trigger permissions Problem occurs inconsistently across different Macs Technical Details: macOS 13+ support Using standard NSAppleScript with simple commands like "tell application 'Spotify' to playpause" App Store distribution (no private APIs) Issue affects both Spotify and Apple Music but seems more prevalent with Apple Music Questions: Is there a reliable way to programmatically trigger the automation permission prompt? Are there timing dependencies for when macOS decides to show permission prompts? Could app priority/usage patterns affect permission prompt behavior? I use MediaManager to run the functions and initialize it on AppDidFinishLaunching method and start monitoring there. Any insights or workarounds would be greatly appreciated. This inconsistency is affecting user onboarding and app functionality.

I want iOS device identifier for a framework that is used in multiple vendor's apps. I'm developing a framework to control a peripheral. The framework has to send unique information to register the device with the peripheral. My naive idea was to use IdentifierForVendor. But this API provides the device identifier for the same vendor's apps, not the framework. (The framework will be used by multiple vendors.) Is there a usable device identifier for the framework, regardless of app vendor? Please tell me any solution.

Hey, there are plans to design a government app. When a citizen will login they will see their passport, driving license etc... What is the solution of avoiding mandatory in-app user data deletion?

Is There a Reliable Way to Check Local Network Permission Status in 2025? I've read many similar requests, but I'm posting this in 2025 to ask: Is there any official or reliable method to check the current Local Network permission status on iOS 18.x? We need this to guide or navigate users to the appropriate Settings page when permission is denied. Background Our app is an IoT companion app, and Local Network access is core to our product's functionality. Without this permission, our app cannot communicate with the IoT hardware. Sadly, Apple doesn't provide any official API to check the current status of this permission. This limitation has caused confusion for many users, and we frequently receive bug reports simply because users have accidentally denied the permission and the app can no longer function as expected. Our App High Level Flow: 1. Trigger Permission We attempt to trigger the Local Network permission using Bonjour discovery and browsing methods. (see the implementation) Since there's no direct API to request this permission, we understand that iOS will automatically prompt the user when the app makes its first actual attempt to communicate with a local network device. However, in our case, this creates a problem: The permission prompt appears only at the time of the first real connection attempt (e.g., when sending an HTTP request to the IoT device). This results in a poor user experience, as the request begins before the permission is granted. The first request fails silently in the background while the permission popup appears unexpectedly. We cannot wait for the user's response to proceed, which leads to unreliable behavior and confusing flows. To avoid this issue, we trigger the Local Network permission proactively using Bonjour-based discovery methods. This ensures that the system permission prompt appears before any critical communication with the IoT device occurs. We’ve tried alternative approaches like sending dummy requests, but they were not reliable or consistent across devices or iOS versions. (see the support ticket) 2. Wi-Fi Connection: Once permission is granted, we allow the user to connect to the IoT device’s local Wi-Fi. 3. IoT Device Configuration: After connecting, we send an HTTP request to a known static IP (e.g., 192.168.4.1) on the IoT network to configure the hardware. I assume this pattern is common among all Wi-Fi-based IoT devices and apps. Problem: Even though we present clear app-level instructions when the system prompt appears, some users accidentally deny the Local Network permission. In those cases, there’s no API to check if the permission was denied, so: We can’t display a helpful message. We can’t guide the user to Settings → Privacy &amp; Security → Local Network to re-enable it. The app fails silently or behaves unpredictably. Developer Needs: As app developers, we want to handle negative cases gracefully by: Detecting if the Local Network permission was denied Showing a relevant message or a prompt to go to Settings Preventing silent failures and improving UX So the question is: What is the current, official, or recommended way to determine whether Local Network permission is granted or denied in iOS 18.x (as of 2025)? This permission is critical for a huge category of apps especially IoT and local communication-based products. We hope Apple will offer a better developer experience around this soon. Thanks in advance to anyone who can share updated guidance.

I am developing a navigation application. My goal is for this navigation app to also work in the background and provide the user with real-time directional updates. When apps request access to location services, users see a TCC (Transparency, Consent, and Control) prompt. This prompt allows the user to choose under what conditions the app can access location services (for example: “While Using the App”, “Always”, etc.). If the user selects the “While Using the App” option, can the navigation app still access location in the background and provide directional information to the user? Is something like this technically possible? Does Apple allow this behavior for navigation apps or similar use cases?