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"

On macOS 27 the File Provider extension of our app (Secure ShellFish, an SSH client) can't connect to any host on the local network, while the containing app connects to the same host on the same Mac without problems. Local Network is enabled for the app in System Settings, but every connection from the extension fails with "Local network prohibited". It did not happen on macOS 26 and still happens on macOS 27.2 (26B123). This is hitting end users of Secure ShellFish, not just my test setup, and it has been my number one support issue since macOS 27 was released. I filed this as FB24999927 with a sysdiagnose. I'm posting here to find out whether others with File Provider (or other) extensions see the same, and whether there is anything on our side that should make it work. Steps Install the app on a clean macOS 27 system and launch it. Choose Allow at the Local Network prompt. Add an SSH server on the local network (another Mac in my test) and open a terminal to it. This works. Open the same server in Finder (the File Provider domain under ~/Library/CloudStorage). The directory listing fails. What happens TN3179 says "In general, app extensions share the Local Network privilege state of their container app", so I expected the listing to load. Instead every connection from the extension to the LAN host is blocked, and the error depends on the networking API: CFStream: ENETDOWN (50) "Network is down" BSD socket connect(): EHOSTUNREACH (65) "No route to host" Network.framework (NWConnection, multipath TCP): waits with path unsatisfied (Local network prohibited) until our connect timeout, ETIMEDOUT (60) No Local Network prompt appears. Toggling the permission, rebooting, killing the extension process and reinstalling the app don't help. What I ruled out A stale extension process: freshly launched extension processes are blocked on their very first connection. A missing UUID cache: after installing a new build, nehelper populates the cache for the app with 14 UUIDs, including both slices of the extension's executable. The extension was blocked 23 seconds later. Shared executable UUIDs: the app and the extension have distinct Mach-O UUIDs. The sandbox: the extension has com.apple.security.network.client. A missing usage string: adding NSLocalNetworkUsageDescription to the extension's Info.plist changed nothing, with no prompt and no separate entry in System Settings. Networking in general: the extension reaches internet hosts and the Mac itself by its local name. Only other hosts on the local network are blocked. Log The blocked notification arrives with bundle_id: (null). UserEventAgent then maps the extension to the app by its UUID, nehelper answers that local network is allowed by preference, and the handler is called with the newly allowed state. Later connections from the same process are still blocked, so that state never takes effect for the extension. 09:19:37.575 UserEventAgent Got local network blocked notification: pid: 4297, uuid: 183484C2-8052-36AD-A81E-B02F15F875B3, bundle_id: (null) 09:19:37.575 UserEventAgent LocalNetwork: found bundle id com.appliedphasor.secure-shellfish.mac-provider by PID 09:19:37.575 ShellFish-Finder [C1.1.1 IPv6#dace0833.22 failed path (unsatisfied (Local network prohibited), interface: en0[802.11], ipv4, ipv6, uses wifi)] 09:19:37.576 UserEventAgent LocalNetwork: found bundle id com.appliedphasor.secure-shellfish by UUID 183484C2-8052-36AD-A81E-B02F15F875B3 09:19:37.597 nehelper UUID cache hit for com.appliedphasor.secure-shellfish 09:19:37.597 nehelper Local network allowed by preference for ShellFish (com.appliedphasor.secure-shellfish) 09:19:37.597 UserEventAgent App got response: 1 09:19:37.597 UserEventAgent Calling handler with newly allowed state: 1 09:19:44.795 fileproviderd populate-directory error: FP -1004 "Unable to list p5.local: Unable To Connect To P5.Local: Network Is Down."Questions Is this a known change in macOS 27? FB24035385 (helper and child processes no longer inherit Local Network access on macOS 27) sounds related, and other File Provider apps report the same, for example nextcloud/desktop#10885: https://github.com/nextcloud/desktop/issues/10885 Does an extension need anything on macOS 27 to share its container's Local Network privilege, such as an entitlement, an Info.plist key, or something the app must do first? If not, is there a supported workaround? The only one we see is to relay the extension's traffic through the main app over loopback, which only works while the app is running. For these users Finder integration is completely broken, because servers on the local network (Raspberry Pi, NAS, home servers) are the most common setup among them. Any pointers are much appreciated.

Our iOS app uses shm_open to create an app-owned, App Group-scoped POSIX shared-memory object. Before allowing access to previously authorized offline data, we call fstat on its file descriptor to verify the object's size, owner UID, and permission mode. We do not access file timestamps, use this information for fingerprinting, or send the metadata off-device. Apple's approved reason C617.1 refers to files inside app or App Group containers. However, POSIX shared-memory objects have no filesystem entry. Does C617.1 cover this specific use of fstat? If not, should we request a new approved reason?

Hi, Apple recently announced that Apple Intelligence will launch in mainland China with iOS 27.3. Will the Foundation Models framework also become available to third-party apps in mainland China? If so, will it use the new iOS 27 Apple Foundation Model or an older version? Will the new capabilities and Private Cloud Compute also be supported? Thanks!

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?