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 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.

We are having an issue with the Local Network permission pop-up not getting triggered for our apps that need to communicate with devices via local network interfaces/addresses. As we understand, apps using UDP should trigger this, causing macOS to prompt for access, or, if denied, fail to connect. However, we are facing issues with macOS not prompting this popup at all. Here are important and related points: Our application is packaged as a .app package and distributed independently (not on the App Store). The application controls hardware that we manufacture. In order to find the hardware on the network, we send a UDP broadcast with a message for our hardware on the local network, and the hardware responds with a message back. However, the popup (to ask for permission) never shows up. The application is not able to find the hardware device. It is interesting to note that data is still sent out to the network (without the popup) but we receive back the wrong data. The behaviour is consistent macOS Sequoia (and above) with both Apple And Intel silicon. Workarounds that have been tried: Manual Authorization: One solution suggested in various blogs was to go to "Settings → Privacy and Security-> Local network", find your application and grant access. However, the application never shows up in the list here. Firewall: No difference is seen in behaviour with firewall being ON OR OFF. Setting NSLocalNetworkUsageDescription: We have also tried setting the Info.plist adding the NSLocalNetworkUsageDescription with a meaningful string and updating the NSBonjourServices. Running Via terminal (WORKS): Running the application via terminal sees no issues. The application runs correctly and is able to send UDP and receive correct data (and find the devices on the network). But this is not an appropriate solution. How can we get this bug/issue fixed in macOS Sequoia (and above)? Are there any other solutions/workarounds that we can try on our end?

Hi everyone, I am working on an iOS application that utilizes a Broadcast Upload Extension (ReplayKit) to perform local, on-device screen analysis. Currently, we are using RPSystemBroadcastPickerView to allow the user to initiate the broadcast session. However, for our specific tracking use case, requiring the user to manually tap the "Start Broadcast" button every time creates a significant friction point in the user experience. My questions are: Is there any private API, entitlement, or MDM (Mobile Device Management) configuration that allows an app to programmatically start a ReplayKit screen recording session completely in the background without explicit human intervention (e.g., without tapping a button in the UI)? If this is strictly prohibited for consumer apps on the App Store due to privacy guidelines, are there any exceptions or enterprise-level profiles available for supervised devices that bypass the mandatory RPSystemBroadcastPickerView user interaction? My understanding is that Apple enforces this manual trigger and the red status bar indicator for strict security and privacy reasons, but I am looking for an official confirmation on whether any programmatic workaround exists for this in modern iOS versions (iOS 15+). Thank you in advance for your time and clarification!

I've a iOT companion app, in which I'll connect to iOT's Wi-Fi and then communicate the device with APIs, for the above functionality we needed local network permission So we enabled neccessary keys in info.plist and at the time of App Launch we trigger local network permission using the following code info.plist <string>This app needs local network access permission to connect with your iOT device and customize its settings</string> <key>NSBonjourServices</key> <array> <string>_network-perm._tcp</string> <string>_network-perm._udp</string> </array> Network Permission Trigger Methods import Foundation import MultipeerConnectivity class NetworkPermissionManager: NSObject { static let shared = NetworkPermissionManager() private var session: MCSession? private var advertiser: MCNearbyServiceAdvertiser? private var browser: MCNearbyServiceBrowser? private var permissionCallback: ((String) -> Void)? func requestPermission(callback: @escaping (String) -> Void) { self.permissionCallback = callback do { let peerId = MCPeerID(displayName: UUID().uuidString) session = MCSession(peer: peerId, securityIdentity: nil, encryptionPreference: .required) session?.delegate = self advertiser = MCNearbyServiceAdvertiser( peer: peerId, discoveryInfo: nil, serviceType: "network-perm" ) advertiser?.delegate = self browser = MCNearbyServiceBrowser( peer: peerId, serviceType: "network-perm" ) browser?.delegate = self advertiser?.startAdvertisingPeer() browser?.startBrowsingForPeers() // Stop after delay DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { [weak self] in self?.stopAll() // If no error occurred until now, consider permission triggered self?.permissionCallback?("granted") self?.permissionCallback = nil } } catch { permissionCallback?("error: \(error.localizedDescription)") permissionCallback = nil } } func stopAll() { advertiser?.stopAdvertisingPeer() browser?.stopBrowsingForPeers() session?.disconnect() } } extension NetworkPermissionManager: MCSessionDelegate { func session(_: MCSession, peer _: MCPeerID, didChange _: MCSessionState) {} func session(_: MCSession, didReceive _: Data, fromPeer _: MCPeerID) {} func session(_: MCSession, didReceive _: InputStream, withName _: String, fromPeer _: MCPeerID) {} func session(_: MCSession, didStartReceivingResourceWithName _: String, fromPeer _: MCPeerID, with _: Progress) {} func session(_: MCSession, didFinishReceivingResourceWithName _: String, fromPeer _: MCPeerID, at _: URL?, withError _: Error?) {} } extension NetworkPermissionManager: MCNearbyServiceAdvertiserDelegate { func advertiser(_: MCNearbyServiceAdvertiser, didReceiveInvitationFromPeer _: MCPeerID, withContext _: Data?, invitationHandler: @escaping (Bool, MCSession?) -> Void) { invitationHandler(false, nil) } func advertiser(_: MCNearbyServiceAdvertiser, didNotStartAdvertisingPeer error: Error) { print("❌ Advertising failed: \(error)") if let nsError = error as NSError?, nsError.domain == NetService.errorDomain, nsError.code == -72008 { permissionCallback?("denied") } else { permissionCallback?("error: \(error.localizedDescription)") } permissionCallback = nil stopAll() } } extension NetworkPermissionManager: MCNearbyServiceBrowserDelegate { func browser(_: MCNearbyServiceBrowser, foundPeer _: MCPeerID, withDiscoveryInfo _: [String: String]?) {} func browser(_: MCNearbyServiceBrowser, lostPeer _: MCPeerID) {} func browser(_: MCNearbyServiceBrowser, didNotStartBrowsingForPeers error: Error) { print("❌ Browsing failed: \(error)") if let nsError = error as NSError?, nsError.domain == NetService.errorDomain, nsError.code == -72008 { permissionCallback?("denied") } else { permissionCallback?("error: \(error.localizedDescription)") } permissionCallback = nil stopAll() } }``` I want to satisfy this following cases but it's not working as expected # Case1 Working App launches --> trigger permission using above code --> user granted permission --> connect to iOT's Wi-Fi using app --> Communicate via Local API ---> should return success response # Case2 Not working App launches --> trigger permission using above code --> user denied permission --> connect to iOT's Wi-Fi using app --> Communicate via Local API ---> should throw an error I double checked the permission status in the app settings there also showing disabled state In my case case 2 is also return success, even though user denied the permission I got success response. I wonder why this happens the same above 2 cases working as expected in iOS 17.x versions

I'm seeing a behavior difference in CGWindowListCopyWindowInfo between macOS 26 Tahoe and macOS 27 Golden Gate beta regarding the Screen Recording / System Audio Recording privacy permission, and I'd like to confirm whether this is intentional or a beta regression. Environment macOS 26 Tahoe (26.x) — tested behavior below macOS 27 Golden Gate beta 4 (26A5388g) — tested behavior below Expected behavior (matches Tahoe) When my app does NOT have permission under System Settings > Privacy & Security > Screen & System Audio Recording: CGWindowListCopyWindowInfo still returns window list entries for other running apps. However, kCGWindowOwnerName for windows owned by processes other than my own app is nil. When permission IS granted, kCGWindowOwnerName is populated correctly for all windows. Actual behavior on Golden Gate Even without Screen Recording permission granted (verified in System Settings, and via CGPreflightScreenCaptureAccess() returning false), kCGWindowOwnerName is populated for windows owned by other running apps — i.e., the same as if permission had been granted. Repro swift let options: CGWindowListOption = [.optionOnScreenOnly, .excludeDesktopElements] let windowList = CGWindowListCopyWindowInfo(options, kCGNullWindowID) as? [[String: AnyObject]] for window in windowList ?? [] { let owner = window[kCGWindowOwnerName as String] as? String print(owner ?? "nil") } On Tahoe without permission: prints nil for other apps' windows. On Golden Gate beta 4 without permission: prints the actual owner name for other apps' windows. Question Is this a known/intentional change in Golden Gate, or a beta regression in the TCC enforcement path for this API? Since Apple has been steadily tightening screen-capture-adjacent APIs (Sonoma/Sequoia/Tahoe) and recommending migration to ScreenCaptureKit, should we treat any reliance on kCGWindowOwnerName's permission-gated nil behavior as unsupported going forward, and use a different API to check whether the process has Screen Recording access? Any guidance from DTS would be appreciated. Happy to file a Feedback Assistant report with a sample project if useful — let me know the FB number format expected.

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 !

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 am currently working on a specialized analytics and time-tracking application, and I am trying to find a reliable way to detect which app the user currently has open in the foreground in real-time. On Android, this is typically handled via Accessibility Services or UsageStats, but I am well aware of iOS’s strict sandboxing rules and privacy protections. So far, I have researched and tested a few workarounds, but none perfectly fit the use case: Screen Time API (FamilyControls / DeviceActivity): This is fantastic for blocking apps or getting daily aggregate usage, but it does not provide real-time callbacks or the bundle ID of the app currently on the screen. MDM (Mobile Device Management): Requires enterprise enrollment and wiping the device, which isn't feasible for a consumer-facing app. ReplayKit (Broadcast Extension): We are currently utilizing RPBroadcastSampleHandler to screen record the device and using OCR and Core ML to visually identify the app (e.g., detecting the YouTube UI). However, this is incredibly resource-intensive and pushes the 50MB Jetsam limit for extensions. My Question: Is there any official API, restricted entitlement, or system notification (like NSWorkspace.shared.frontmostApplication on macOS) that allows a background process to simply read the bundleID of the active foreground app on iOS? If not, is ReplayKit combined with OCR or Machine Learning truly the only way to detect what app a user is actively viewing on iOS without a jailbreak? Thank you in advance for any insights!

Hi all, I'm preparing to submit a watchOS app that only reads HealthKit heart rate data (HKQuantityTypeIdentifierHeartRate) and I want to make sure my storage and sharing practices won't trigger a rejection under Guidelines 5.1.1 (Data Collection and Storage) and 5.1.3 (Health and Health Research). Some specifics about my app: it's an Apple Watch app that reads heart rate only via HealthKit. Data is stored locally on the device first, then uploaded to my own backend server. It's not shared with any third parties (no analytics/ad SDKs touch this data). The uploaded heart rate data is displayed back to the user in a front-end heart rate viewer. My questions: Does uploading HealthKit heart rate data from local storage to my own backend server automatically raise review scrutiny, or is it acceptable as long as it's disclosed in the privacy policy and App Privacy Nutrition Label? Since I'm not sharing data with any third parties, does that satisfy Guideline 5.1.3's restriction on using HealthKit data for advertising or data-mining, or are there other requirements around server-side storage of health data specifically (e.g., encryption at rest/in transit, retention limits)? Is there a preferred way to document this data flow (device to backend) in the app submission, such as App Privacy details, HealthKit usage description, or Health & Fitness disclosures, that reviewers specifically look for to avoid a rejection or follow-up request? Has anyone had a watchOS app rejected for HealthKit-related data practices recently, and if so, what was the specific issue and how did you resolve it? I've read the Health & Fitness guidelines and the HealthKit documentation, but I'd appreciate real-world experience from anyone who has shipped a similar app, especially around what reviewers actually flag in practice. Thanks in advance.

We are developing an iOS application that uses the MobileVLCKit framework (version 3.7.3) for RTSP video streaming. We have encountered a critical performance issue that directly affects user experience. Problem Description When the app is granted the Local Network permission (the switch in Apps → OurApp → Local Network), the VLC media player takes 10–15 seconds to start playback after calling play(). If the user manually disables this permission, playback starts immediately (within 1 second). The issue is 100% reproducible on real devices and does not appear on the simulator. What we have tried Adjusting VLC options (network-caching, rtsp-tcp, clock-synchro, etc.) — no effect. Using different RTSP streams (both local and public) — same delay. Checking network logs: the delay occurs before any actual RTSP handshake (DESCRIBE/SETUP), suggesting the system is waiting for something network-related. Why this is critical We cannot instruct our users to turn off Local Network access, because the app also needs this permission for legitimate features (e.g., discovering cameras on the local network). Disabling it permanently is not a viable solution. Request We kindly ask for your guidance: Is there a recommended way to configure the app or the VLC instance to avoid this delay while keeping Local Network permission enabled? Could this be a bug in the permission-handling layer that causes unnecessary timeouts? Are there any entitlements, plist keys, or runtime flags we should use to optimise network access in this scenario? We are happy to provide detailed logs, a sample project, or any other information that could help identify and resolve this issue. Environment iOS: 16.0+ Device: Physical (all) VLCKit: 3.7.3 (integrated via CocoaPods) Xcode: 26.5 Thank you for your time. We look forward to your response.

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.

Hi all: We use MDM profile to apply Full Disk Access permission for app on macOS, After profile deployed successfully, The App can get correct Full Disk Access permission, However, on "Privacy & Security" UI, we found that our app shown disabled, see as however, on some macOS, it showed correctly as below The issue happened on different os version. macOS 15 and macOS 26 When the item shown as disable, even reboot computer several times, the issue still persist. Thanks for your help

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.

Problem description Since macOS Sequoia, our users have experienced issues with multicast traffic in our macOS app. Regularly, the app starts but cannot receive multicast, or multicast eventually stops mid-execution. The app sometimes asks again for Local Network permission, while it was already allowed so. Several versions of our app on a single machine are sometimes (but not always) shown as different instances in the System Settings > Privacy & Security > Local Network list. And when several instances are shown in that list, disabling one disables all of them, but it does not actually forbids the app from receiving multicast traffic. All of those issues are experienced by an increasing number of users after they update their system from macOS 14 to macOS 15 or 26, and many of them have reported networking issues during production-critical moments. We haven't been able to find the root cause of those issues, so we built a simple test app, called "FM Mac App Test", that can reproduce multicast issues. This app creates a GCDAsyncUdpSocket socket to receive multicast packets from a piece of hardware we also develop, and displays a simple UI showing if such packets are received. The app is entitled with "Custom Network Protocol", is built against x86_64 and arm64, and is archived (signed and notarized). We can share the source code if requested. Out of the many issues our main app exhibits, the test app showcases some: The app asks several times for Local Network permission, even after being allowed so previously. After allowing the app's Local Network and rebooting the machine, the System Settings > Privacy & Security > Local Network does not show the app, and the app asks again for Local Network access. The app shows a different Local Network Usage Description than in the project's plist. Several versions of the app appear as different instances in the Privacy list, and behave strangely. Toggling on or off one instance toggles the others. Only one version of the app seems affected by the setting, the other versions always seem to have access to Local Network even when the toggle is set to off. We even did see messages from different app versions in different user accounts. This seems to contradicts Apple's documentation that states user accounts have independent Privacy settings. Can you help us understand what we are missing (in terms of build settings, entitlements, proper archiving...) so our app conforms to what macOS expects for proper Local Network behavior? Related material Local Network Privacy breaks Application: this issue seemed related to ours, but the fix was to ensure different versions of the app have different UUIDs. We ensured that ourselves, to no improvement. Local Network FAQ Technote TN3179 Steps to Reproduce Test App is developed on Xcode 15.4 (15F31d) on macOS 14.5 (23F79), and runs on macOS 26.0.1 (25A362). We can share the source code if requested. On a clean install of macOS Tahoe (our test setup used macOS 26.0.1 on a Mac mini M2 8GB), we upload the app (version 5.1). We run the app, make sure the selected NIC is the proper one, and open the multicast socket. The app asks us to allow Local Network, we allow it. The alert shows a different Local Network Usage Description than the one we set in our project's plist. The app properly shows packets are received from the console on our LAN. We check the list in System Settings > Privacy & Security > Local Network, it includes our app properly allowed. We then reboot the machine. After reboot, the same list does not show the app anymore. We run the app, it asks again about Local Network access (still with incorrect Usage Description). We allow it again, but no console packet is received yet. Only after closing and reopening the socket are the console packets received. After a 2nd reboot, the System Settings > Privacy & Security > Local Network list shows correctly the app. The app seems to now run fine. We then upload an updated version of the same app (5.2), also built and notarized. The 2nd version is simulating when we send different versions of our main app to our users. The updated version has a different UUID than the 1st version. The updated version also asks for Local Network access, this time with proper Usage Description. A 3rd updated version of the app (5.3, also with unique UUID) behaves the same. The System Settings > Privacy & Security > Local Network list shows three instances of the app. We toggle off one of the app, all of them toggle off. The 1st version of the app (5.1) does not have local network access anymore, but both 2nd and 3rd versions do, while their toggle button seems off. We toggle on one of the app, all of them toggle on. All 3 versions have local network access.

I'm looking for a way to prevent my app from displaying in screenshots and screen recordings. There appears to be plenty of options for UIKit/iOS but nothing I can find for macOS. userDidTakeScreenshotNotification @Environment(.sceneCaptureState) private var captureState Obviously it's possible though as I remember back in the day you couldn't take screenshots of the DVD Player etc.

Hello, I am looking for guidance on how to pre-provision TCC permissions for automated desktop app testing on the macOS 27 beta. We have maintained a CI testing setup by saving snapshots of VMs with pre-configured user TCC databases. This allowed our UI tests to run without being blocked by permission prompts. This included permissions like screen recording, full disk access or apple events. On the macOS 27 beta, this workflow appears completely broken. While the system TCC database seems to function as it used to, the user TCC database has been moved into a ProtectedSystem container. Direct modifications to the user database now seem impossible. Is there any officially supported way to pre-provision user-level TCC permissions on macOS 27 VMs for automated CI environments? Is Apple's intention here that the system DB is the only one that's actually editable (with SIP disabled)? How does Apple recommend CI platforms handle user-level permission prompts in headless or automated VM environments moving forward? Any insights or recommended alternative workflows would be greatly appreciated. Thank you!

When a user uses the "Add Name" feature on an unknown number in their Call Logs, the name appears under "Other Known Contacts" in the native iOS Contacts app. The Problem: CNContactStore completely ignores these contacts during a standard fetch/enumeration. When user gives limited permission they can search for that contact and select it, but it won't be visible in my App as it's not technically a contact. Is CNContactStore intentionally blocked from reading "Other Known Contacts" for privacy reasons or are there any future plans to expose API so that third party apps can access it?

My app runs as expected when debugging, trigging the MacOS to ask the user for permission to use the microphone. The notarized version of the app does not have the MacOS asking for user permission but the app gets the message 'User rejected permission'. I'm seeing this after upgrading to 26.5.1 and so is one of my users. What changed in getting microphone permission?

This is our second App Store submission for Rex, a social entertainment discovery app whose core features depend on account-based personalization, saved history, and social/group functionality. Rex’s core features include Rex AI, which provides personalized movie and TV recommendations, along with social watchlists and Party Mode for group recommendations. These features do not function in any meaningful way without an account because they rely on user preferences, saved history, social connections, and persistent recommendation data to deliver the intended experience. Our app is being rejected under Guideline 5.1.1(v), even though account-based functionality is central to the premise of the product. Sign-in is not being used as a gate in front of otherwise accessible content. It is required because the product itself depends on an account-based experience. We have now received the same generic rejection message twice, with no indication that our previous responses were reviewed or considered. We submitted detailed explanations of how Rex works and why sign-in is foundational to the experience, but those points have not been acknowledged or addressed. The responses we have received do not engage with the specific nature of our app, do not address the 5.1.1(v) exception for apps whose core functionality is account-dependent, and appear to repeat the same form language without responding to the context we provided. This is a significant investment of time and resources, and we are trying to understand what Apple is specifically asking us to change. We are not trying to gate free content behind a login. We are trying to ship a product that, by design, requires an account for its core functionality to work. Can someone from Apple or the developer community help clarify how Guideline 5.1.1(v) should be applied to apps where personalization, social features, saved history, and group recommendations are the core product experience?

I’ve been using the Age Assurance support page and related Developer News posts as the source of truth for understanding Apple’s expectations around Age Assurance on Apple platforms: https://developer.apple.com/support/age-assurance/ https://developer.apple.com/news/?id=sg176nne Can anyone from Apple clarify whether anything has recently changed with App Review expectations related to Age Assurance? Specifically, are there any new requirements or updated guidance around implementing technologies like DeclaredAgeRange or PermissionKit? I didn’t see any sessions or announcements that indicated these frameworks are now required but with all of the new child safety announcements I thought I'd ask and document for the developer community. I did see the new sample code for implementing Age Assurance and permissions, but nothing suggesting their use is mandatory for App Store approval. https://developer.apple.com/documentation/declaredagerange/implementing-age-assurance-and-permissions Just trying to confirm whether current guidance remains the same, or if App Review expectations are evolving.