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"

in this weeks i received this error: ITMS-91055: Invalid API reason declaration - The PrivacyInfo.xcprivacy for the “VanigliaPro” file contains “App Functionality” as the value for a NSPrivacyAccessedAPITypeReasons key instead of a valid reason code for using an API in the NSPrivacyAccessedAPICategoryFileTimestamp category. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, values for NSPrivacyAccessedAPITypeReasons keys in your app’s privacy manifest must be valid reason codes for the corresponding API category. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api. ITMS-91053: Missing API declaration - Your app’s code in the “xxxx” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryUserDefaults. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api. ITMS-91053: Missing API declaration - Your app’s code in the “xxxx” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryFileTimestamp. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api. any help for make correct privacy file?

I'm developing an Accessibility-enabled app that includes a helper app registered as a launch daemon using SMAppService. This daemon will connect to HID which requires both being root as well as having Accessibility (or Input Monitoring) permissions. I want this app to have as little friction for the user as I can manage. One friction I'd like to avoid is requiring the user to grant more than one application permission to use Accessibility features. So I'm wondering if I can set up the launch daemon so that it inherits the TCC permissions of its parent bundle. I'll note that the one way I've found that works is to not have the helper app have its own app bundle, but rather just have it be an executable placed alongside the main executable in enclosing bundle's Contents/MacOS directory. This has the disadvantage though of having the helper process and main process have the same name in Activity Monitor, which I think will be confusing to users. So in short, is there a supported way for a bundled application with its own CFBundleName / CFBundleDisplayName key to run as a launch daemon and also inherit Accessibility permissions from its parent app bundle?

Hi everyone! We recently integrated "Sign in with Apple" into our application using standard social login flows. For the vast majority of our users, the integration works perfectly—we receive the user's email during sign-in and sign-up. However, we are noticing an edge case where a small subset of users are returning an ID token that is completely missing the email. We can't seem to reproduce this error ourselves during testing. Every time we test a sign-up or sign-in, the email payload is included exactly as expected. My Questions: Is there a specific reason why Apple would omit the email claim from the ID token? Any insights or guidance would be greatly appreciated. Thank you!

I'm developing SipBudget, an iPhone app that will store manually entered alcohol-consumption records locally using SwiftData. The app will not use CloudKit synchronization, HealthKit, or a developer-operated cloud database. I understand that App Review Guideline 5.1.3(ii) prohibits storing personal health information in iCloud. I would appreciate technical guidance on two questions: Can a local SwiftData database be reliably excluded from ordinary iCloud device backups? If so, what is Apple's recommended implementation for ensuring that the database and related files remain excluded, including after database updates or migrations? I'm asking before implementation so I can design the storage architecture correctly. Thank you.

Hi, I'm developing an iOS app that uses a third-party library compiled with GraalVM Native Image and packaged as a dynamic framework. During a privacy compliance review, I found several Required Reason APIs in the compiled library. Their actual uses do not appear to fit Apple's documented approved reasons. 1. File Timestamp APIs (stat, fstat, lstat) The runtime uses these APIs to inspect system timezone files such as /etc/localtime, primarily checking file types, symbolic links, and sizes. However, reason C617.1 appears to cover files within the app's own containers, not system files. 2. Disk Space API (fstatvfs) The runtime uses fstatvfs to obtain filesystem block alignment information (f_frsize) for Direct I/O, rather than checking available disk space. This does not appear to match reason E174.1. 3. System Boot Time API (mach_absolute_time) The runtime uses this API to implement a monotonic clock, potentially including random seed initialization. Reason 35F9.1 covers elapsed-time measurements and timers, but does not clearly address random seeding. Questions Do these uses require Required Reason API declarations? If so, which approved reasons apply? How should developers handle API references included in a compiled runtime that may never execute in the app? If no approved reason matches these uses, what is the recommended compliant approach? The app does not use these APIs for tracking or device fingerprinting. I want to ensure the framework's Privacy Manifest accurately reflects its actual behavior rather than declaring unsupported reasons. Any guidance would be greatly appreciated. Thank you!

Hello, After a recent iOS update, I was going through my settings to set restrictions on apps installed on my device, and I noticed this option on each app's page: Learn from this App: "Allow Siri to learn from how you use [App Name] to make suggestions across apps." I turned it off right away, but it left me with several questions. In 2026, Siri has received major updates, including new AI features, and it now communicates with me much more often. Before I decide whether to turn this setting back on, I'd like to understand: What data does Siri collect from each app? For example, does it look at which apps I open and when, what I do inside them, or the content I view? How is that data used to improve suggestions? What does Siri actually do with what it learns? Where is this data processed and stored? Does it stay on my device, or is it sent to Apple's servers or synced through iCloud? How is my personal information protected? Is it linked to my Apple Account, and is it shared with app developers or third parties? How is the content I watch or read used across apps? Could something I view in one app affect suggestions in another app? Can I see or delete what Siri has already learned? If so, how? I know Apple takes privacy and security seriously, so I'm not too worried. But this is one of those features Apple didn't really talk about on stage, so I'd appreciate a clearer explanation of how it works. Thanks!

Background: We are loading a web login page inside ASWebAuthenticationSession. For login page, username and password have autofill password options enabled. On click of the username textfield when we tap the system "Passwords" suggestion in the QuickType bar above the keyboard causes the app to become completely unresponsive. No crash occurs and nothing is logged to the console. The only option to get back to the app is we must force-quit to recover. This issue is observed only on OS 26.6.1 and 26.7.1 other variant of the OS-26.x seems to be working fine. We have tested the gmail app having the ASWebAuthenticationSession for login scenario, the similar issue is observed in that too. Does anyone else also have faced similar issue ? Any help/pointers much appreciated.

iOS 27 adds a second stage to HealthKit read authorization. After picking data types, the user chooses "Past 30 Days and Future Data" or "All Recorded Data and Future Data", with Allow disabled until one is selected. Every user of every health app now makes this call, in the first seconds of onboarding, with no real context about what the app needs. I don't think the scale of this has landed yet. A meaningful share of users will pick 30 days. multi-year health trends, month to month comparisons, all-time records: with 30 days these features don't get worse, they stop existing. And it breaks silently. The user sees empty charts and a app that doesn't do what the screenshots promised. They won't connect that to a sheet they tapped through on day one — they'll connect it to the app. That's the reckoning: a wave of one-star reviews and support mail for a decision the developer never saw and can't inspect. Because we can't inspect it .authorizationStatus(for:) deliberately hides read authorization and getRequestStatusForAuthorization only says whether prompting would show UI, so a 30-day grant and a genuinely new Apple Watch user look identical from the query layer. A callback when Health permissions change for a type — even without disclosing the new state — would go a long way here. And we can't route users to the fix. UIApplication.openSettingsURLString opens the app's own Settings page, which has no Health section. The real control sits at Settings › Privacy & Security › Health › — four levels deep, unreachable from any public API. My suggestion is a URL constant scoped to the calling app, the way openNotificationSettingsURLString (iOS 15.4+) and openDefaultApplicationsSettingsURLString (iOS 18.3+) already work. But that's just my idea; if there's a better mitigation, or something already planned, I'd like to hear it. Worth saying the privacy gain looks thin either way: the app keeps all future data indefinitely, so a 30-day grant becomes a full-history grant in thirty days for anyone who keeps the app. The window limits what's readable today, not what accumulates. iOS 27 release is approaching... I think this will cause problems 😞 Filed as FB24398048 and FB24398031

On Xcode 27.0 (27A266a) / macOS 27.2, I ran xcrun mcpbridge from a scripted stdio MCP client and captured traffic system-wide, with a curl control visible in the same captures. Findings: mcpbridge itself opened no network sockets (online or offline, and under a deny-network sandbox). The "Xcode Service" process it connects to made about 2 KB of outbound TLS to an Apple edge address at startup, plus a certificate check via trustd and a request to devimages-cdn.apple.com. When a workspace was opened through XcodeOpenWorkspace, Xcode Service also made two TLS connections to appstoreconnect.apple.com (about 5 KB upstream). This did not occur without a workspace open, and XcodeListWorkspaces itself caused no traffic. mcpbridge sends a CoreAnalytics event to analyticsd (strings: "MCPBridgeTelemetry: Submitted CoreAnalytics event" / "Telemetry off; skipped"), payload <private>. Questions: What is sent to App Store Connect when a workspace is opened this way, and is it the same as opening the project in Xcode directly? What does the MCPBridgeTelemetry event contain, is it sent off-device, and what setting controls it? Is any MCP tool input or output (file contents, paths, build output) sent to Apple?

An app using FamilyControls (.individual) computes a single daily number on device from the user's own DeviceActivity data. Can that number be sent to a server so the user can compare it with friends? No app tokens, bundle IDs, or per-app times would leave the device. Is this allowed under DPLA section 3.3.3(P), which limits sharing usage data "beyond … the individual and their device"?

We run a Wi-Fi network with our own captive portal and want iOS clients to be told that Private Relay is not available here, as described in Prepare your network or web server for iCloud Private Relay and WWDC21 session 10096. Our setup: Resolver: Unbound, handed out via DHCP, with local-zone: "mask.icloud.com" always_nxdomain and local-zone: "mask-h2.icloud.com" always_nxdomain. The network is IPv4-only. The captive portal intercepts all UDP port 53 traffic and drops everything else (e.g. port 853). TCP port 53 is not served. We also tried NXDOMAIN for mask-api.icloud.com, apple-native-relay.apple.com, mask.apple-dns.net, mask-api.fe.apple-dns.net and mask-t.apple-dns.net, with no change. [Result of our resolver log: do queries for the mask hosts arrive from the test iPhone, and what do we answer? Before and after captive-portal login?] What the documentation promises: “users will be alerted that they need to either disable Private Relay for that network, or choose another network.” What happens: On [iPhone model], iOS [exact version/build], with Private Relay enabled in iCloud settings and “Limit IP Address Tracking” [on/off] for this Wi-Fi, joining our network shows no message at all. [What the user sees instead: Safari loads normally / pages fail / nothing changes.] Counter-observation: On a hotel guest network (Marriott) the same kind of device did show a notice, so the feature seems to still work on current iOS. We do not know how that network blocks Private Relay. Related reports: thread 687684 and thread 722315 describe a similar gap (network-level NXDOMAIN gives no alert, on-device DNS filtering does). Our own report: FB[number], no response so far. Questions: Which conditions must be met for iOS to show the message? Is NXDOMAIN for the two documented names enough, or does the alert also depend on other hostnames, the DNS response type (NXDOMAIN vs. NODATA), or the state of the network (e.g. before/after captive login)? Is the alert suppressed when “Limit IP Address Tracking” was turned off for that Wi-Fi earlier, or when Private Relay has already connected successfully on another network? Is the documentation still accurate for current iOS releases? If not, could it be updated?

Hello, I am writing about a Network Extension URL Filter configuration submitted through the Identity & Trust section of the CloudKit Console on 5 September 2026 Status shown: In Review / Waiting for Approval Last Modified: 5 September 2026 (unchanged since submission) It has now been 37 days with no response — no approval, no rejection, and no request for changes. The PIR server , Privacy Pass issuer and HTTP/2 OHTTP gateway have been live and serving since the day of submission, configured per the Onboarding.md guidance in Apple's PIR service example, including the apple-url-filter DNS TXT record on the service URL and the url-filter-test validation entry. Could anyone please let me know: Whether this configuration is actually in a review queue, and the expected timeframe; Whether anything further is required from our side — if so, we will act on it the same day. The URL filter is a core protection feature of our app, which is currently in App Store review; the feature stays disabled for users until this registration is approved, so the delay is holding up what we can ship. Thank you for your help.

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:

We develop an endpoint security agent that customer IT deploys and manages via MDM on supervised, ADE-enrolled Macs. The agent requires Accessibility permissions to perform core security functions. Historically, IT provisioned this via the PPPC payload which granted Accessibility as a managed control without end-user interaction. In macOS 27 this path for Accessibility has been removed. The documented replacement — the Privacy key in com.apple.configuration.app.settings — is consent-based: on a supervised device it presents the user a consolidated prompt with "Allow" preselected, which the user may decline. We are seeking guidance on the supported approach for macOS 27 GA: On a supervised macOS 27 device, is there a supported mechanism for an MDM-managed, code-signature-verified application to be provisioned with Accessibility as a managed security control, without depending on individual end-user consent? (i.e. an equivalent to what PPPC provided for enterprise-managed endpoints.) If the consent-based com.apple.configuration.app.settings Privacy declaration is the only path, what is Apple's recommended approach for enterprise-mandated security agents that must have Accessibility to function — including handling the case where a user declines or dismisses the prompt? We have also filed this as an enhancement request via Feedback Assistant (FB23531820). Environment for context: macOS 27 supervised via Automated Device Enrollment, managed by Jamf Pro.

PermissionDefaults under Privacy for com.apple.configuration.app.settings , device reports Info.UnsupportedSettings for "$.Privacy.PermissionDefaults for macOS 27 device iMac manufactured 2024 Request from MDM : "Type": "com.apple.configuration.app.settings", "Payload": { "Privacy": { "PermissionDefaults": { "net.soti.mobicontrol.macOS": { "OrganizationJustification": "Message", "Accessibility": "Allow" }, "net.soti.mobicontrol.macOSHelper": { "OrganizationJustification": "Message", "Accessibility": "Allow" } } } }, "Identifier": "2adc58b3-f631-41b8-93d8-f55612055c30", "ServerToken": "4dc895cc-b7c2-4729-b8a4-f9e2f8dba5a9" } Response from Device: { "StatusItems": { "management": { "declarations": { "activations": [ { "active": true, "identifier": "77409e31-ff4f-4f86-a1bd-175515e3a3bd", "valid": "valid", "server-token": "b096dd48-a127-4f65-a60d-bd615911deb8-1" }, { "active": true, "identifier": "84992e13-edc2-4791-989e-0cc54bd18ab8", "valid": "valid", "server-token": "8460aca3-b263-43fe-b659-343c81a6479e" }, { "active": true, "identifier": "bfd661e8-b81f-4383-b243-00330fca13ae", "valid": "valid", "server-token": "38399079-5402-401a-83f4-c39e8b4807e8" } ], "configurations": [ { "active": true, "identifier": "00d217fe-f6e2-479f-89b5-73b479bd9f1d", "valid": "valid", "server-token": "c25104a2-6d13-44a1-ac00-ccc916490ae9" }, { "reasons": [ { "details": { "Settings": [ "$.Privacy.PermissionDefaults" ] }, "code": "Info.UnsupportedSettings" } ], "active": true, "identifier": "2adc58b3-f631-41b0-93d8-f55612055c30", "valid": "valid", "server-token": "4dc895cc-b7c2-4429-b8a4-f9e2f8dba5a9" }, { "reasons": [ { "details": { "Settings": [ "$.Privacy.PermissionDefaults" ] }, "code": "Info.UnsupportedSettings" } ], "active": true, "identifier": "c5bc77f6-745d-43ae-9e49-6e9100d3f6a5", "valid": "valid", "server-token": "e3a5cdb3-fd51-42a2-afb4-fe5f602a493d-1" } ], "assets": [], "management": [] } } }, "Errors": [] }

Question: Camera Permission Reset and NSInternalInconsistencyException on iOS 26 We’ve recently started seeing an issue in our production app: NSInternalInconsistencyException "Call must be made on the main thread" We were able to reproduce the issue by manually revoking/resetting the Camera permission so that its state changes back to notDetermined. This raises a few questions: Does iOS 26 automatically revoke or reset previously granted permissions in certain scenarios? Has Apple introduced any changes to the permission or privacy policy in iOS 26? Is there any known behavior where an existing Camera permission can unexpectedly return to the notDetermined state after an OS update? Has anyone else encountered a similar issue in production after updating to iOS 26? We couldn’t find any clear or recent documentation from Apple that explains a change in this behavior. Has anyone experienced this issue or found any relevant Apple documentation explaining the permission-state changes in iOS 26?

I’m working on my first app and I wanted to add someone to TestFlight to help me test it. I submitted it for review and it was rejected because it’s asking for demo credentials. However, my app doesn’t use any credentials at all. It is fully local, doesn’t communicate or send any telemetry to any servers. The only servers it hits is Gmail and iCloud, if the user chooses to connect their mailboxes, and for backups to iCloud Drive. do I reach out to them and tell them that this app doesn’t need credentials or do I create a demo mode of the app and resubmit?

Binary code is associated with the NSUserTrackingUsageDescription deleted at present, but in the revised App privacy will contain NSUserTrackingUsageDescription, I feel very confused, don't know should shouldn't solve.

what happens to the 3DS payment page, the Auth0 login, Apple Wallet's add-pass screen and the QR camera?

We occasionally observe es_mute_process_events() called on an es_client_t while an AUTH event delivered by the same client is still outstanding. In the problematic state, es_mute_process_events() stops returning inside IOConnectCallStructMethod. Subsequent calls to es_respond_flags_result() and a fallback es_respond_auth_result() on the same es_client_t also block in IOConnectCallStructMethod, eventually causing the AUTH deadline to be missed. We would like to clarify the concurrency semantics of these APIs: Is it supported to call es_mute_process_events() before responding to an outstanding AUTH event delivered by the same es_client_t? Can es_mute_process_events() wait for in-flight/outstanding AUTH processing? Are mute operations and es_respond_*() calls serialized internally for a single es_client_t? Can an in-progress mute operation prevent a concurrent es_respond_*() call from completing? Is the recommended pattern to respond to the AUTH message first and update mute state asynchronously afterward?