Apple Privacy Manifests

[LydGol90]

Hi there, I am interested to get the view of the team/community about Apple Privacy Manifests and how these impact react native.

1. Is the idea that developers will always create and maintain their own Privacy Manifests within React Native projects, or is there a plan for a default/template manifest to be included in future RN releases. (I use vanilla RN in my app but not sure how this might impact Expo users?)
2. For native/turbo modules that the app users, or libs that the app uses that make use of native/turbo modules, what is the view on how these might impact privacy manifests and/or who will be responsible for those. I don't think libs that include native modules can necessarily support a privacy manifest as they don't have an app target so not sure how this would work exactly. Thinking mostly here about the potential use of "Required Reason APIs" or data collection. Do we need a way for libs to indicate if they are using any of these?
3. It looks like hermes is on the list of Apple "Privacy Impacting SDKs". Will a Privacy Manifest be included for this in react native or in hermes SDK?

Many thanks in advance for any help/views on this

[TheSavior]

Thanks for the questions. We are working on this and will have more to share with the community soon

[gkasireddy202]

@sst-tim - I upgraded my project to 0.73. We are facing several issues after the degradation.we will work on the 0.73 upgrade after that. Please consider my request.

[sst-tim]

@gkasireddy202, they won't bring support to version that already out of support window. 0.71 is the latest support and even going to be removed once 0.74 added. If they start accomodating each user request, there will be others coming to ask support for 0.70, 0.69, 0.67 etc as well

[gkasireddy202]

@sst-tim - Yes you are right because of the May 1 deadline. We are facing so many issues on depend libraries in my project.

[gkasireddy202]

We are using react-native-navigation version 4 in our project. Getting some errors after upgrading to 0.73.2 those errors aren’t supported by the core team. Because of this, we cannot continue my project upgrading to the latest versions.

[fabiendem]

@gkasireddy202 You can always declare the missing items in your own app manifest yourself. You don't need to wait on the libraries to provide it.
Apple merges all the manifests into one at build time.

[liamjones]

For anyone coming to this thread who is not familiar with the Privacy Manifests stuff and wants to learn more about it; it's a requirement for new & updated apps uploaded to App Store Connect. It has a, currently somewhat nebulous, deadline of being required from "Spring 2024".

Apple Development news post: https://developer.apple.com/news/?id=r1henawx (The news post also contains links to reference docs)

[kunalchavhan]

I have been following this "Privacy Manifest" requirement from the time Apple announced it. I agree with @liamjones that more clarity is needed from Apple and it is evident as many widely used libraries have not still made this change, there is already an issue raised on hermes. Hoping that we get clarity from react native side as soon as possible.

[liamjones]

New update from Apple yesterday with concrete deadlines: https://developer.apple.com/news/?id=3d8a9yyh

Starting March 13: If you upload a new or updated app to App Store Connect that uses an API requiring approved reasons, we’ll send you an email letting you know if you’re missing reasons in your app’s privacy manifest. This is in addition to the existing notification in App Store Connect.

Starting May 1: You’ll need to include approved reasons for the listed APIs used by your app’s code to upload a new or updated app to App Store Connect. If you’re not using an API for an allowed reason, please find an alternative. And if you add a new third-party SDK that’s on the list of commonly used third-party SDKs, these API, privacy manifest, and signature requirements will apply to that SDK. Make sure to use a version of the SDK that includes its privacy manifest and note that signatures are also required when the SDK is added as a binary dependency.

[ken0nek]

a new third-party SDK that’s on the list of commonly used third-party SDKs

Looking at SDKs that require a privacy manifest and signature, hermes is only related to the core React Native in my understanding.

I thought every SDK we use has to have a privacy manifest at first but it seems that's not true (*for now).

[philIip]

@ken0nek, so let me give an overview of what SDK means here. the definition of SDKs that require a privacy manifest and signature is different from what we as developers usually consider to be an SDK. it is about how it is distributed, rather than its functionality. from the apple docs on privacy manifest:

Apps and third-party SDKs — distributed as XCFrameworks, Swift packages, or framework bundles — can contain a privacy manifest file, named PrivacyInfo.xcprivacy.

from this definition of framework, i.e. they aren't built into the source code of the app. here's some reading on how frameworks work. if the SDK is built as source, the app is responsible for providing the privacy manifest for that SDK's code.

RN is built as source, and hermes is distributed as 3rd party framework via RN source.

we're looking to provide a guidance here in the next few weeks to make this a straightforward process for you all! i hope this provides a bit more clarity

[philIip]

Hi everyone,

We are aware that Apple included Hermes in a list of “commonly used SDKs” that will require a Privacy Manifest and signature starting May 1, 2024.

As mentioned already, Hermes is distributed via React Native. We will provide Privacy Manifests for our SDKs that were listed by Apple in the coming weeks to ensure you have sufficient time to update prior to enforcement.

We expect to have more information to share in the coming weeks around the availability of our updated SDKs.

For versioning, we’re currently focusing on providing support to newer versions, but intending to backport this support to older versions of React Native.

Thanks!

[philIip]

For native/turbo modules that the app users, or libs that the app uses that make use of native/turbo modules, what is the view on how these might impact privacy manifests and/or who will be responsible for those. I don't think libs that include native modules can necessarily support a privacy manifest as they don't have an app target so not sure how this would work exactly. Thinking mostly here about the potential use of "Required Reason APIs" or data collection. Do we need a way for libs to indicate if they are using any of these?

this depends on where the native module exists. if it is a built-in for RN, then this will be provided through the guidance that we're working on. if it is a custom native module that you've built, then you as the developer would be responsible for adding the data use permissions and required reasons, as from the framework side we would have no idea why you would be doing certain things.

that being said, please hold tight, i know it's tough with a deadline approaching. we're working hard on this and will have updates to share soon!

[matt-oakes]

It seems like Apple is now sending out the warnings for this now. Here's an example of what we're getting in our app now:

Hello,

We noticed one or more issues with a recent submission for TestFlight review for the following app:

XXXXX

Although submission for TestFlight review was successful, you may want to correct the following issues in your next submission for TestFlight review. Once you've corrected the issues, upload a new binary to App Store Connect.

ITMS-91053: Missing API declaration - Your app’s code in the “XXXXX” 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.

ITMS-91053: Missing API declaration - Your app’s code in the “XXXXX” 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.

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

Thanks for your work so far in resolving this. Looking forward to seeing your guidance on resolving the warnings in the coming weeks.

[matt-oakes]

Not directly, but it's likely coming from expo-file-system which is a dependency of expo-asset. It looks like there's already a discussion ongoing for Expo to handle this.

Here's a full list of the apps dependencies with the warnings above, just for reference.

"@expo/vector-icons": "^13.0.0",
"@react-native-async-storage/async-storage": "1.18.2",
"@react-native-community/netinfo": "9.3.10",
"@react-navigation/bottom-tabs": "^6.5.11",
"@react-navigation/native": "^6.1.9",
"@react-navigation/native-stack": "^6.9.17",
"axios": "^1.6.2",
"classnames": "^2.3.2",
"d3-format": "^3.1.0",
"date-fns": "^2.29.3",
"expo": "^49.0.21",
"expo-asset": "~8.10.1",
"expo-constants": "~14.4.2",
"expo-device": "~5.4.0",
"expo-font": "~11.4.0",
"expo-notifications": "~0.20.1",
"expo-splash-screen": "~0.20.5",
"lodash": "^4.17.21",
"qs": "^6.11.2",
"react": "18.2.0",
"react-native": "0.72.6",
"react-native-easy-toast": "^2.3.0",
"react-native-gesture-handler": "~2.12.0",
"react-native-keyboard-aware-scroll-view": "^0.9.5",
"react-native-paper": "^5.11.3",
"react-native-safe-area-context": "4.6.3",
"react-native-screens": "~3.22.0",
"react-native-webview": "13.2.2",
"react-redux": "8.1.3",
"redux": "^4.2.1",
"redux-axios-middleware": "^4.0.1",
"redux-persist": "^6.0.0",
"redux-thunk": "^2.4.2"

[philIip]

got it, that would make sense. thanks!

[elibroftw]

I also got the same 4 warnings.

"dependencies": {
    "@apollo/client": "^3.7.15",
    "@babel/plugin-proposal-nullish-coalescing-operator": "^7.0.0-0",
    "@babel/plugin-proposal-optional-chaining": "^7.0.0-0",
    "@babel/plugin-transform-arrow-functions": "^7.0.0-0",
    "@babel/plugin-transform-shorthand-properties": "^7.0.0-0",
    "@babel/plugin-transform-template-literals": "^7.0.0-0",
    "@notifee/react-native": "^7.8.0",
    "@os-team/i18next-react-native-language-detector": "^1.0.27",
    "@react-native-async-storage/async-storage": "^1.21.0",
    "@react-native-clipboard/clipboard": "^1.13.2",
    "@react-navigation/bottom-tabs": "^6.5.11",
    "@react-navigation/material-top-tabs": "^6.6.5",
    "@react-navigation/native": "^6.1.6",
    "@react-navigation/native-stack": "^6.9.12",
    "@stripe/stripe-react-native": "^0.37.0",
    "graphql": "^16.6.0",
    "haversine": "^1.1.1",
    "i18next": "^23.1.0",
    "prop-types": "^15.6.0",
    "react": "18.2.0",
    "react-i18next": "^13.0.0",
    "react-native": "0.73.6",
    "react-native-camera-kit": "^13.0.0",
    "react-native-geolocation-service": "^5.3.1",
    "react-native-gesture-handler": "^2.14.1",
    "react-native-google-places-autocomplete": "^2.5.6",
    "react-native-localize": "^3.0.6",
    "react-native-maps": "^1.10.0",
    "react-native-navigation-bar-color": "^2.0.2",
    "react-native-pager-view": "^6.2.3",
    "react-native-paper": "^5.12.3",
    "react-native-permissions": "^4.1.1",
    "react-native-qrcode-svg": "^6.2.0",
    "react-native-reanimated": "^3.6.2",
    "react-native-safe-area-context": "^4.8.2",
    "react-native-screens": "^3.29.0",
    "react-native-sectioned-multi-select": "^0.10.0",
    "react-native-svg": "^14.1.0",
    "react-native-tab-view": "^3.5.2",
    "react-native-url-polyfill": "^2.0.0",
    "react-native-vector-icons": "^10.0.0",
    "usehooks-ts": "^2.9.1"
  },

Overlapping packages:

{'@react-navigation/bottom-tabs', 'react-native-gesture-handler', 'react-native', 'react-native-safe-area-context', 'react-native-paper', '@react-native-async-storage/async-storage', '@react-navigation/native', '@react-navigation/native-stack', 'react-native-screens', 'react'}

https://github.com/react-native-async-storage/async-storage/releases/tag/v1.23.1

[williamgurzoni]

@elibroftw Were you able to find out which SDK was using the NSPrivacyAccessedAPICategoryDiskSpace? I'm having the same issue. I see that the react-native-async-storage was using the NSPrivacyAccessedAPICategoryFileTimestamp, but not disk space API.

My overlapping packages:

react-native: 0.72.7,
react: 18.2.0,
@react-native-async-storage/async-storage: 1.23.1

Full dependencies:

"dependencies": {
    "@apollo/client": "^3.9.1",
    "@react-native-async-storage/async-storage": "^1.23.1",
    "@react-native-community/datetimepicker": "^7.6.2",
    "@react-native-community/netinfo": "^11.2.1",
    "@react-native-community/progress-bar-android": "^1.0.4",
    "@react-native-community/progress-view": "^1.4.2",
    "@react-native-community/slider": "^4.5.0",
    "@react-native-firebase/analytics": "^19.1.2",
    "@react-native-firebase/app": "^19.1.2",
    "@react-native-picker/picker": "2.5.1",
    "@redux-offline/redux-offline": "2.6.0-native.1",
    "@sentry/react-native": "^5.20.0",
    "apollo-upload-client": "^17.0.0",
    "graphql": "^16.8.1",
    "react": "18.2.0",
    "react-native": "0.72.7",
    "react-native-a-beep": "^1.1.0",
    "react-native-background-timer": "^2.4.1",
    "react-native-camera": "^3.43.6",
    "react-native-code-push": "8.2.1",
    "react-native-device-info": "^10.12.0",
    "react-native-easy-grid": "^0.2.2",
    "react-native-geolocation-service": "5.3.1",
    "react-native-get-random-values": "^1.10.0",
    "react-native-image-crop-picker": "^0.40.2",
    "react-native-keyboard-aware-scroll-view": "^0.9.5",
    "react-native-modal-datetime-picker": "^17.1.0",
    "react-native-navigation": "7.37.2",
    "react-native-permissions": "^4.1.1",
    "react-native-picker-select": "^9.0.1",
    "react-native-vector-icons": "^10.0.3",
    "react-redux": "6.0.1",
    "redux": "^3.7.1",
    "redux-persist": "^4.0.1",
    "redux-persist-filesystem-storage": "^2.1.0",
    "redux-persist-transform-filter": "^0.0.14",
    "rn-fetch-blob": "^0.12.0",
    "uuid": "^9.0.1",
}

[elibroftw]

Unfortunately I didn't, but I just created a manifest since even if the SDK includes the manifest, you need to as well.

[leofolive]

Guys, is there any quick way to find out which SDK is using something and not declared in privacy? as the warnings only point to the app itself.

[bananer]

I got some hints by running this script: https://github.com/Wooder/ios_17_required_reason_api_scanner

[gkasireddy202]

My Team needs to add the iOS privacy manifest file for the react-native version:0.68.7.

[sst-tim]

Hi, any updates on this? I think this will affect all React Native codebases that have IOS app in the App Store as they will be rejected after 1 May

[mobileteo]

I wondering if anyone has tried to create the Privacy file in the main app and tested if third-party libraries are accepted even if they didn't declared that manifest.

[mobileteo]

Following on this: it seems that declaring the manifest only at the top level of the project, and not in any library used is good for Apple and no warnings are triggered.

[christocracy]

I've been working at testing this out for about 10 days now (I'm a plugin author who manages plugins for Flutter, React Native, Capacitor and Cordova).

So, the accepted method for plugin authors to handle PrivacyInfo.xcprivacy for their code has been to define a resource_bundles in their plugin's .podspec;

Pod::Spec.new do |s|
  .
  .
  .
  s.resource_bundles = {'MyPluginNamePrivacy' => ['Resources/PrivacyInfo.xcprivacy']}
end

This results in a separate .bundle being appended to the app archive. The iOS app development community had hoped that Apple would find these .bundles, iterate through them to evaluate their contained PrivacyInfo.xcprivacy. However, after my extensive testing, Apple is NOT evaluating these .bundle containing each plugin's PrivacyInfo.xcprivacy.

Here is a file-explorer view of my iOS bundle. This is from a Flutter app, but it doesn't matter. This app contains a number of dependencies which each supply their own PrivacyInfo.xcprivacy contained within a .bundle (highlighted below in blue):

• TSLocationManger.bundle
• url_launcher_ios_privacy.bundle
• TSBackgroundFetch.bundle
• shared_preferences_foundation_privacy.bundle
• CocoaLumberjackPrivacy.bundle
• TSBackgroundFetch.bundle

This Archive was uploaded to App Store Connect and passed all privacy evaluation without any warnings, but the only way I've found to do so is to create your own custom PrivacyInfo file in XCode and append all the elements requested by all your plugins (shown above in red (My custom manifest...).

In XCode, select File -> New.

tl;dr: Apple SHOULD be evaluating any .bundle in an Archive and evaluating each plugin's supplied AppPrivacy.xcprivacy but they are NOT. You the application developer are currently responsible for managing your own AppPrivacy.xcprivacy and manually adding all the required elements requested by each of your plugins (some of which will be duplicates; eg: plugins requiring access to NSUserDefaults).

I hope this is just Apple being stupid and late and that they will soon update their archive evaluation behaviour.

An example PrivacyInfo.xcprivacy for authorizing usage of NSUserDefaults would look like this (Do not copy/paste this into your own app -- this is just an example).

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">
<dict>
    <key>NSPrivacyTrackingDomains</key>
    <array/>

    <key>NSPrivacyAccessedAPITypes</key>
    <array>        
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>

            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>CA92.1</string>
                <string>1C8F.1</string>
            </array>
        </dict>        
    </array>

    <key>NSPrivacyCollectedDataTypes</key>
    <array/>

    <key>NSPrivacyTracking</key>
    <false/>
</dict>
</plist>

If this is Apple's intended behaviour, then I guess React Native (and Flutter, Capacitor and Cordova (good luck)) should manage an App's Privacy Manifest and provide built-in tooling to automatically parse each plugin's AppPrivacy.xcprivacy and append those elements to the global Manifest (but ugh — managing the removal of those elements when a plugin is removed, when multiple plugins may depend upon some common NSPrivacyAccessedAPIType, such as the commonly used NSUserDefaults. I guess completely destroy/re-generate each time a plugin is added/removed)

[philIip]

hi everyone, thanks for your patience. i have outlined the react native strategy for privacy manifests here:

#776 (comment)

please go ahead and take any further discussions to that post.