NSPrivacyAccessedAPICategoryDiskSpace : Missing API declaration

[n1tesh]

ITMS-91053: Missing API declaration - Your app’s code in the “” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryDiskSpace. 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.

Still getting NSPrivacyAccessedAPICategoryDiskSpace on 6.28.0

[dinhnhat0401]

same here. From Apple report, we (bugsnag sdk using apps) need to declare NSPrivacyAccessedAPICategoryDiskSpace. I have a few questions:

• Which reason should app describe for NSPrivacyAccessedAPICategoryDiskSpace?
• Shouldn't this be reflected here for latest version (6.28.0 or later)? https://docs.bugsnag.com/platforms/ios/appstore-privacy/#declaring-required-reasons-for-api-usage
• Need to add NSPrivacyAccessedAPICategoryDiskSpace to Bugsnag's privacy file.

[mclack]

Hi @n1tesh and @dinhnhat0401

I can confirm that usage of NSPrivacyAccessedAPICategoryDiskSpace has been removed as of v6.28.0, but will still be included in apps built for macOS. We're not aware of any issues with this, and this release should adhere to all of Apple's API usage guidelines already. As such, we're keen to work with you to understand why you are seeing this.

Can you both confirm whether this is an iOS app you are submitting? Can you also let us know whether you get any other information in your reports from Apple? Please share the full reports if you are able, alongside any other information you think may be relevant.

[n1tesh]

@mclack Yes this is regarding iOS App submission to AppStore v6.28.0.

Below is the warning mail we get post submission.

ITMS-91053: Missing API declaration - Your app’s code in the “MyAirtel” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryDiskSpace. 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

[dinhnhat0401]

@mclack thanks for the reply. Yes this is iOS app submission. MacOS includes M1 Mac devices which will practically using iPad version. I think this is why Apple sending this feedback. One approach is making the app comply with 7D9E.1 https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api Let me know what you think.

[mclack]

Hi @n1tesh and @dinhnhat0401

This is the first time we've seen users coming up against this particular issue for iOS releases, so we're currently unsure why this problem is occurring. We've tested building iOS apps ourselves (including a Mac Catalyst app, which will also run on macOS) and these do not include any call to statfs, so we're confident that our SDK is in line with Apple's guidelines.

We'd be interested to know what the result of running the following command on your binary is. This will scan for mentions of statfs: strings <application_binary> | grep statfs

We'd also like to confirm that it is definitely the BugSnag library which is leading to this warning, as Apple's response does not make this clear. Are you able to remove the BugSnag library from your app, and test whether this prevents the warning? After doing this, would you be able to re-run the command above to see if this results in any changes to mentions of statfs in the built binary?

If you're able to confirm that removing BugSnag entirely fixes the warning, then we'd suggest creating your own fork of bugsnag-cocoa, and remove the statfs call from the library: https://github.com/bugsnag/bugsnag-cocoa/blob/16b9145fc66e5296f16e733f6feb5d0e450574e8/Bugsnag/KSCrash/Source/KSCrash/Recording/Tools/BSG_KSFileUtils.c#L90

If you're still having problems with this, then does removing all mentions of statfs prevent the warning? It's possible that Apple is picking this string up where they shouldn't be.

[dinhnhat0401]

@mclack thanks for the info. After trying with a new empty project I can see the disk related statfs caused by another lib our app is using. 👍

Question, is it correct that the disk space info that I can see on bugsnag (with 6.28.0) is from a different set of APIs that doesn't require reason to use?

[daliad007]

Hey @mclack, we receive this warning when we upload our iOS app to the store. As a workaround as suggested, I created a fork and removed the statfs call and the warning is gone.

Do you think this could be removed from the main repo too at some point and perhaps replaced with a similar solution that go against Apple's new privacy rules?

[daliad007]

Hey @mclack, we receive this warning when we upload our iOS app to the store. As a workaround as suggested, I created a fork and removed the statfs call and the warning is gone.

Do you think this could be removed from the main repo too at some point and perhaps replaced with a similar solution that go against Apple's new privacy rules?

Hello, after further checking, it looks like it's a different SDK that is causing the warning to trigger, not Bugsnag related.

Thanks

[airtelshivam]

Hey @mclack, we receive this warning when we upload our iOS app to the store. As a workaround as suggested, I created a fork and removed the statfs call and the warning is gone. Do you think this could be removed from the main repo too at some point and perhaps replaced with a similar solution that go against Apple's new privacy rules?

Hello, after further checking, it looks like it's a different SDK that is causing the warning to trigger, not Bugsnag related.

Thanks

@mclack thanks for the info. After trying with a new empty project I can see the disk related statfs caused by another lib our app is using. 👍

Question, is it correct that the disk space info that I can see on bugsnag (with 6.28.0) is from a different set of APIs that doesn't require reason to use?

Can you share which. If its common for us then it would help.

[mclack]

Hi @dinhnhat0401 and @airtelshivam

is it correct that the disk space info that I can see on bugsnag (with 6.28.0) is from a different set of APIs that doesn't require reason to use?

Since v6.28.0 of bugsnag-cocoa, the functionality used to populate the device.freeDisk field has been removed, so this should just be reported with a value of 0 unless you are manually populating it within your app: https://github.com/bugsnag/bugsnag-cocoa/blob/16b9145fc66e5296f16e733f6feb5d0e450574e8/Bugsnag/include/Bugsnag/BugsnagDeviceWithState.h#L24-L25

The only exception to this is for macOS, so device.freeDisk should still be reported as usual in these applications.

Can you both confirm:

• Are these macOS applications?
• Are the reported device.freeDisk values equal to 0?
• Are you manually populating this field within your app?

[mclack]

Hi all,

As there has been no activity on this thread for a while, and the information provided seems to indicate that the problem is not with BugSnag, we are going to close this now.

If anyone continues to experience issues with this, and believes this is related to BugSnag after following the guidance above, please feel free to open a new issue, or open a ticket with us directly by contacting [email protected], and provide as much information as you can so that we can investigate further.