The presenter in this WWDC session from 2019 (https://asciiwwdc.com/2019/sessions/701) states: "So, now in macOS Catalina, executables that are denied access to files due to a lack of Full Disk Access approval are now prepopulated unchecked." I'm unable to make this work. Included is a minimal test app that tries to access a resource that would require Full Disk Access (FDA) and then opens Privacy & Security ... FDA in settings. When I run this from Xcode or manually run the app from Finder the test app does not appear in the list of apps in FDA. If I manually drag and drop the app from the build folder into the FDA window and enable it then the app is granted FDA access successfully. To be clear I understand that even the app is automatically populated in the FDA list the user will still need to toggle the switch to enable it. But I'd like to avoid making the user hunt down the app manually add it. Testing on macOS Sonoma 14.5. Xcode 15.4. Link to project file: https://akiairzavu3i3x4dmaya-public.s3.amazonaws.com/FDA+test.zip

I have an application that uses Bonjour to communicate with other instances of the app on other devices. If I start an NWBrowser and the user has "Local Network" turned off for my app, the stateUpdateHandler for the browser gets .waiting with an error containing the string "PolicyDenied." This lets me show an alert to the user explaining what's happening, with a link to the app's Settings screen. But if I use NWListener (the counterpart of NWBrowser) and have "Local Network" turned off, there's no indication of any problem. After I start the listener, stateUpdateHandler is called with .ready as the state - even though it's not really ready to listen at all. The FAQ for Local Network Privacy suggests that any Bonjour operation will raise kDNSServiceErr_PolicyDenied if Local Network is off. However, in my application, that only seems to be true for browsing, not listening. Is there a way to detect a missing Local Network entitlement for NWListener? I know there are solutions involving sending a message to localhost, etc, but ideally there would be something simpler.

Hi Everybody, I would like to see the feature, that allows us to limit the access for selected apps to get access to our Contacts. Especially apps like WhatsApp cannot be trusted, in my opinion, so I would love to see the possibility to prevent, that they just analyse our full Contact book and sell the data. With a limited access feature, we can at least decide, which information we wanna share with suspicious companys. What do you think and how could we reach the developers attention to get this with the next major update. Greetings from Europe

Hear me out, developers at Apple! You've done an amazing job with privacy so far. The introduction of ContactAccess and the Contact Access Button this year is truly an amazing work of art. Well done. However, all the way back to the first iPhone I got in 2007, I wished Apple would make API's available to access the users installed apps (in a privacy way). This would (further) open up apps in the category of App Managers and App Launchers. Back in the early days the trick was to use deep link, but that was also awkward, since you needed to know the deeplink upfront and the apps needed to support it. Not ideal. It also had a side effect that Apple noticed, that evil party's used it to scan your device to know which apps you had installed and create a profile from that. Apple fixed that by using LSApplicationQueriesSchemes. Now you have to tell the App upfront which apps you will be calling (up to 50), or use Universal Link to be freed from this limitation again. Again not ideal. Why not turn it around and let the user decide? User central. Imagine an App Launcher app. There is a button in the launcher app where you as a user can click on to add an app. It calls an api available from Apple to launch a privacy shielded sheet with the apps the user got installed on its device. These are not exposed to the launcher app. When the user clicks on the installed app (or apps) it likes to add, the launcher app will get identifiers to launch the app. That's it. This would be limited access, perhaps the api could also expose full access, so permission could be granted once and the app will get all identifiers available. The choice will be up to the user. One step further, but this would be more nice-to-have, is the ability to access meta data of the app, such as icon, title, last launched, app size, etc. This way App Launchers can make decisions such as putting the most recent launched app in front or App Managers can use this to decide which apps you are not using and can advise to remove them to clean up space. Love to hear everyone's opinion. So let it be the start of the discussion.

Does anyone have recent experience of what App Review consider acceptable for location purpose strings these days? My map apps simply display a blue spot on the map showing your current location when you turn on the app's location button. That data doesn't leave the app; I'm not selling it to anyone, or doing anything nefarious. For years, I've had concise location purpose strings such as "Your location will be shown on the map". Now, App Review seem to find that inadequate. They say: "One or more purpose strings in the app do not sufficiently explain the use of protected resources. Purpose strings must clearly and completely describe the app's use of data and, in most cases, provide an example of how the data will be used. Next steps: Update the ... location purpose string to explain how the app will use the requested information and provide an example of how the data will be used. " I've just look at what Apple Maps uses as its purpose string, and it's just "Your location is used to show your position on the map, get directions, estimate travel times, and improve search results." I'm only doing the first of those things, so surely "Your location is used to show your position on the map" would get approved, right? Wrong! I have similar issues with the photos purpose string.

I'm writing a C/C++ command line program which, at some point, calls IOHIDManagerOpen. I've added both my program executable and lldb as permitted for input monitoring (as far as I remember, my program was added after showing up a permission prompt, I've added lldb manually later, trying to resolve the problem). My problem is that when I run my program from within lldb in Terminal, the call to IOHIDManagerOpen returns kIOReturnNotPermitted. When I run my program directly in the terminal session (without lldb), this call returns kIOReturnSuccess. Such behaviour means it will be impractical to use lldb for any debugging of this program. What can be done to make lldb session behave the same way, the normal execution works? I'm on: 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:55:06 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6020 arm64 and: lldb-1500.0.200.58 Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5)

Hi, I have an issue with App submission. My flow is: show third party cookie consent banner (is an external SDK) show ATT Apple with this message "Allowing tracking will enable more personalized ads for you." Apple says this: You collect data to track after the user selects "Ask App Not to Track" on the App Tracking Transparency permission request. Specifically, we noticed the app accesses web content you own and collects cookies for tracking after the user asked you not to track them. Next Steps To resolve this issue, please revise the app so that you do not collect data for tracking purposes if the user does not give permission for tracking. Alternatively, if you do not collect cookies for tracking purposes, revise the cookie prompts that appear in the app to clarify you do not track users. in the rejection they put the ATT alert and the third party banner as the screen Do you have any input on this as Apple never says things clearly about what the problem is. Thank you

I've added .storeButton(.visible, for:.policies) to my SubscriptionStoreView, and the buttons do appear, but when I tap on them I get a sheet that just says "Terms of Service Unavailable / Somethng went wrong. Try Again.". (similar for Privacy Policy). Is this expected in development? Will these start working correctly in production? (and, more importantly, in App Review?) The docs say that these use the values (i.e. URLs) set in App Store Connect, but that I can override those. This is a new app. Is that wrong, do I need to set the URLs explicitly? Edited to add: the console reports: Failed to fetch terms of service and privacy policy: Error Domain=NSURLErrorDomain Code=-1011 "(null)"

In the 'notes' app, users are allowed to set custom passwords to restrict other people who may know your device password from accessing it. However, in the 'lock and hide app', there is no support for custom passwords to prevent people who may know your device password from accessing your privacy. For example, your wife. Why is it necessary to allow certain places in the settings, such as permission settings and privacy reports, to still be able to view hidden apps after hiding them, instead of completely hiding them?

Errors building with manual provisioning profile and packages with PrivacyInfo.xcprivacy added. When I look at the changes in the package, the only difference is adding this .xcprivacy file. The error looks like this: PLCrashReporter_CrashReporter does not support provisioning profiles, but provisioning profile *** has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. Using an Enterprise certificate with manually created provisioning profile, I don't have the option to choose automatic. And I can't change build settings for the swift packages. Does anyone know how I can work around this issue?

Great post https://security.apple.com/blog/private-cloud-compute/ and I'd love to get on the action to help as a security researcher. There is a call to action, but it seems to be postponed until "after PCC becomes available in beta". Who at Apple should I keep in touch with and what is the best way to communite with that team. Thanks, François Proulx Software Supply Chain Security Research Lead at BoostSecurity.io

Is there a Description key for an app to explain why it's requesting Accessibility permissions?

By calling the deactivationRequest from the main app bundle, we see Privacy & Security prompts for TouchID to deactivate the System Extension. We want to know if there's way to avoid that prompt. And also need know why the prompt pops up to deactivate our own app's System Extension component. We even tried to call the deactivate request from Daemon which contain the root access. We still see the prompt. https://developer.apple.com/documentation/systemextensions/ossystemextensionrequest/deactivationrequest(forextensionwithidentifier:queue:)

I am trying to access the CMAltimeter class, and I keep getting the error Domain=CMErrorDomain Code=105. I know that indicates my app does not have permissions for motion and fitness. All the documentation I can find mentions the need to add NSMotionUsageDescription to Info.plist. However, I have done that, and it does not help. I am using Xcode 15. It seems that whenever I go to look up how to get permissions to something, the information on the web seems to be outdated, and Apple seems to move stuff around. I have found I can add the entry to Info.plist by using the Info.plist editor and selecting "Privacy - Motion Usage Description", but that does not help. I also notice that when I info tab on my build target, there is a "Privacy - Motion Usage Description" there also. If I add the entry there, it takes out out of my Info.plist, and makes an entry in the project's project.pbxproj file named INFOPLIST_KEY_NSMotionUsageDescription. Regardless of which of those I use, I still do not the 105 error. I'm sure I'm missing something more, but I can't find it anywhere. There was mention of a "Health and Fitness" in the signing capabilities, but I could not find anything listed there in Xcode 15

When I send a build in Xcode the process occurs normally, but a few minutes later I receive an e-mail saying: "ITMS-90683: Missing purpose string in Info.plist - Your app’s code references one or more APIs that access sensitive user data, or the app has one or more entitlements that permit such access. The Info.plist file for the “***.app” bundle should contain a NSMicrophoneUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. If you’re using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required." So the problem is the description of the use of the microphone, right? As the attached image shows that I have already done this process, and I continue to receive this error. Even when I remove the part of the avfoundation code that uses the microphone to try to submit the build, the error continues to be returned to me

Hello, I include a Privacy Manifest file in my app and specify one Privacy Nutrition Label Type (Email Address, for marketing purposes). My app uses some third-party SDKs like RevenueCat that contain Privacy Manifest files with nutrition label types specified (Purchases History for RevenueCat for example). Xcode can generate a report that aggregates all the data types that are collected by the app. But is App Store Connect updated when I upload a build? Or do I have to manually setup the App Privacy info? Thanks

Should the privacyInfo.xcprivacy file provided by an app also cover the content of the privacyInfo.xcprivacy from an SDK? For example, if Privacy Tracking Enabled is set to true in a third-party SDK, does that mean Privacy Tracking Enabled should also set to true in the privacyInfo.xcprivacy file included in the app?

Hello, I need help understanding how to manage the privacyInfo.xcprivacy file for apps. Do I need to include privacy details from SDKs in the app’s own file? For instance, if an SDK’s file mentions "Privacy Tracking Enabled: YES," does the app need the same setting? Also, if the SDK lists "Device ID" as a Collected Data Type, should the app list it too? I thought it was best to keep the app’s privacy file just about the app itself and not add SDK information to avoid making things too complex. But I can’t find clear rules on this. Can someone clarify this for me? Thanks!

After adding PrivacyInfo.xcprivacy following this Steps: https://vikramios.medium.com/itms-91053-missing-api-declaration-3c2bef935bd3 I am getting this error ❌ error: Multiple commands produce 'app_dir/PrivacyInfo.xcprivacy';

We're testing this new functionality with our app. One issue I've discovered is that because Gmail intentionally doesn't support push via the Mail app, sending codes to a Gmail email means users will likely never see this autofill. It does appear if you enter the Mail app, pull new messages, and then quickly switch back to the code entry in your app and present the keyboard. I'm basically looking for a behaviour correction here from Apple. Perhaps iOS should intercept notifications for the Gmail app (and other notable apps), or provide a way for devs to publish codes to a system API. As it stands, a large portion of our customers who use Gmail presumably will not be able to use this autofill feature.