May 2024 iOS privacy manifest requirements tracking issue

[keith-kurak]

UPDATE

We now have guide on how to add a privacy manifest via your app config (app.json / app.config.js).

---

Overview

Recently, Apple announced that, starting May 1, they would start enforcing that all new apps and updates must declare approved reasons for using specific APIs in a privacy manifest, preventing uploads to TestFlight if the requirement is not met. These requirements also apply to 3rd party SDK's, with specific SDK's identified by Apple requiring a signature in addition to the manifest.

If you submitted to TestFlight after March 13th, you may have received an email from Apple with an "ITMS-91053" warning, indicating that they found API usage matching an NSPrivacyAccessedAPI category in your app that will require these changes in order to meet the requirements after May 1st (common categories might include NSPrivacyAccessedAPICategoryDiskSpace and NSPrivacyAccessedAPICategoryFileTimestamp).

What Expo is doing about it

Expo engineers are actively engaged with this issue, doing everything in our power ensure that your app submissions continue uninterrupted despite the relatively short notice:

• Adding privacy manifests to all affected modules maintained by Expo
• Tracking progress on key dependencies not maintained by Expo (e.g., this PR to add the manifest to react-native) and ensuring our version validation is updated accordingly as these updates go live.
• Providing guidance on how to add the privacy manifest to community-maintained modules
• Providing guidance and/or tooling to add the privacy info to your CNG-compatible app as needed

As this potentially requires action by any number of 3rd party library maintainers, we can't guarantee that you will not see a rejection for this reason from Apple after May 1st. However, we are focused on taking care of what is in our control, and providing guidance on what is outside of our control.

What's next

We expect to have more specific information about the steps we're taking to address this requirement, including more information about action required on your end to keep your iOS app submissions running smoothly past May 1st.

We will keep this issue open and will post updates here, so watch this issue to keep up-to-date!

[ryanSoftwareEngineer]

If we get our submissions approved before may 1st to the app store, does that mean we can still have our app in the store and continue with javascript updates? Does this only impact new build submissions?

[adrielschmitz]

If we get our submissions approved before may 1st to the app store, does that mean we can still have our app in the store and continue with javascript updates? Does this only impact new build submissions?

No, all submissions will be affected... I'm going through this right now, in fact.

[p4bl1t0]

Can the description be added manually in Xcode (expo's prebuilded apps)?

Which content should be used in that strings?

[adrielschmitz]

Can the description be added manually in Xcode (expo's prebuilded apps)?

Which content should be used in that strings?

I've been trying this a few hours ago... Here are more details (https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api).. in theory it should be something like

<key>NSPrivacyAccessedAPITypes</key>
   <array>
       <dict>
           <key>NSPrivacyAccessedAPIType</key>
           <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
           <key>NSPrivacyAccessedAPITypeReasons</key>
           <array>
               <string>C617.1</string>
           </array>
       </dict>
...

which would be added to the .plist, but I haven't been successful yet...

[jordan-rp-cb]

@adrielschmitz You shouldn't be adding this to the .plist file, but to the new privacy manifest file (PrivacyInfo.xcprivacy)

[adrielschmitz]

@adrielschmitz You shouldn't be adding this to the .plist file, but to the new privacy manifest file (PrivacyInfo.xcprivacy)

Thanks!
In case anyone needs it, this was the file I sent... the added items were taken from the email received from Apple, so it may vary from project to project.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>C617.1</string>
        </array>
    </dict>

    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>35F9.1</string>
        </array>
    </dict>

    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryDiskSpace</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>E174.1</string>
        </array>
    </dict>

    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>CA92.1</string>
        </array>
    </dict>
</array>
</plist>

[dolapo-oluremi]

@adrielschmitz did you have to create a new privacy manifest file or is this just an update to your .plist file?
And very important to ask, did this resolve your issue?
thank you.

[adrielschmitz]

@adrielschmitz did you have to create a new privacy manifest file or is this just an update to your .plist file? And very important to ask, did this resolve your issue? thank you.

At first yes, I no longer received the email from Apple.

I created a new privacy manifest file on the root project...

[keith-kurak]

If we get our submissions approved before may 1st to the app store, does that mean we can still have our app in the store and continue with javascript updates? Does this only impact new build submissions?

The current warning is just that- a warning. You can still build and submit and publish to the stores without any changes before May 1st, and app versions already available in the store will have the same functionality they always had (so, if you built it with updates, it will still have updates). I'm not aware of a previous cutoff like this where builds were retroactively invalidated.

[federicomiralles]

@adrielschmitz You shouldn't be adding this to the .plist file, but to the new privacy manifest file (PrivacyInfo.xcprivacy)

Thanks! In case anyone needs it, this was the file I sent... the added items were taken from the email received from Apple, so it may vary from project to project.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>C617.1</string>
        </array>
    </dict>

    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>35F9.1</string>
        </array>
    </dict>

    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryDiskSpace</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>E174.1</string>
        </array>
    </dict>

    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>CA92.1</string>
        </array>
    </dict>
</array>
</plist>

Quick question @adrielschmitz...
How did you decide the right reason to report to Apple? For instance for NSPrivacyAccessedAPICategoryFileTimestamp you chose the reason C617.1 was the right one and not the other available options:

I mean the short description provided by Apple is far to vague and hence not conclusive for going with one option or the others and this is specially true for 3rd party libs for which we don't any clue what they do under the hood.

So I wanted to better to understand the logic/mechanism/tool? you used to select the correct reason/s for each API type flagged by Apple...

Thanks in advance! 👍

[zfrankdesign]

I just want to confirm the best fix for this is to wait for expo and react native libs (async storage etc) to add this file to their modules for the build pipeline and then upgrade these libs. We're not doing anything manually in our app with these things that apple is warning of. This issue will at some time get updated with guidance on if devs who are just using RN and expo modules are going to need to include a privacy manifest in their ios folder? I just see a lot of people trying to add their own manifest file, is it better to wait for libs to fix this?

[keith-kurak]

I just want to confirm the best fix for this is to wait for expo and react native libs (async storage etc) to add this file to their modules for the build pipeline and then upgrade these libs. We're not doing anything manually in our app with these things that apple is warning of. This issue will at some time get updated with guidance on if devs who are just using RN and expo modules are going to need to include a privacy manifest in their ios folder? I just see a lot of people trying to add their own manifest file, is it better to wait for libs to fix this?

Yes, please give us a little time, we're working hard on this so you (as much as possible) don't have to. You don't need to include these in your project to submit yet, so there's no need to rush ahead with your own workaround.

To some extent, individual app developers could fill in their own xcprivacy files, but, there's certain 3rd party SDK's that need both the declaration and the signing piece, and no individual app developer can work around the signing bit. If you wait a bit, too, we'll be working on guidance for, situations where it would help for you to provide your own manifest, you can do that while still being compatible with CNG/ Prebuild, so it'll be easier than the workarounds described above if you don't maintain your own native project files.

[adrielschmitz]

@adrielschmitz You shouldn't be adding this to the .plist file, but to the new privacy manifest file (PrivacyInfo.xcprivacy)

Thanks! In case anyone needs it, this was the file I sent... the added items were taken from the email received from Apple, so it may vary from project to project.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>C617.1</string>
        </array>
    </dict>

    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>35F9.1</string>
        </array>
    </dict>

    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryDiskSpace</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>E174.1</string>
        </array>
    </dict>

    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>CA92.1</string>
        </array>
    </dict>
</array>
</plist>

Quick question @adrielschmitz... How did you decide the right reason to report to Apple? For instance for NSPrivacyAccessedAPICategoryFileTimestamp you chose the reason C617.1 was the right one and not the other available options:

I mean the short description provided by Apple is far to vague and hence not conclusive for going with one option or the others and this is specially true for 3rd party libs for which we don't any clue what they do under the hood.

So I wanted to better to understand the logic/mechanism/tool? you used to select the correct reason/s for each API type flagged by Apple...

Thanks in advance! 👍

Hello...
I confess that this is very new and I haven't studied it in depth... I chose this option because of the packages I updated (@react-native-firebase/app and @react-native-firebase/messaging), I looked at some topics and others people who solved this same problem added this option.
But as @keith-kurak said below, it is not recommended to do this by hand, the ideal is to wait for the libraries to create these configurations. In my case, I needed to send the update, so I had to make this quick adjustment for the app to be accepted by Apple.

By the way, the project in question is in React Native, I'm not using Expo.

[KesoGizmoYoshi]

Async Storage added privacy manifest.

react-native-async-storage/async-storage#1075

[romeodancil]

Overview

Recently, Apple announced that, starting May 1, they would start enforcing that all new apps and updates must declare approved reasons for using specific APIs in a privacy manifest, preventing uploads to TestFlight if the requirement is not met. These requirements also apply to 3rd party SDK's, with specific SDK's identified by Apple requiring a signature in addition to the manifest.

If you submitted to TestFlight after March 13th, you may have received an email from Apple with an "ITMS-91053" warning, indicating that they found API usage matching an NSPrivacyAccessedAPI category in your app that will require these changes in order to meet the requirements after May 1st (common categories might include NSPrivacyAccessedAPICategoryDiskSpace and NSPrivacyAccessedAPICategoryFileTimestamp).

What Expo is doing about it

Expo engineers are actively engaged with this issue, doing everything in our power ensure that your app submissions continue uninterrupted despite the relatively short notice:

• Adding privacy manifests to all affected modules maintained by Expo
• Tracking progress on key dependencies not maintained by Expo (e.g., this PR to add the manifest to react-native) and ensuring our version validation is updated accordingly as these updates go live.
• Providing guidance on how to add the privacy manifest to community-maintained modules
• Providing guidance and/or tooling to add the privacy info to your CNG-compatible app as needed

As this potentially requires action by any number of 3rd party library maintainers, we can't guarantee that you will not see a rejection for this reason from Apple after May 1st. However, we are focused on taking care of what is in our control, and providing guidance on what is outside of our control.

What's next

We expect to have more specific information about the steps we're taking to address this requirement, including more information about action required on your end to keep your iOS app submissions running smoothly past May 1st.

We will keep this issue open and will post updates here, so watch this issue to keep up-to-date!

Does this fix will also work on React Native or just expo?

[fobos531]

Overview

Recently, Apple announced that, starting May 1, they would start enforcing that all new apps and updates must declare approved reasons for using specific APIs in a privacy manifest, preventing uploads to TestFlight if the requirement is not met. These requirements also apply to 3rd party SDK's, with specific SDK's identified by Apple requiring a signature in addition to the manifest.
If you submitted to TestFlight after March 13th, you may have received an email from Apple with an "ITMS-91053" warning, indicating that they found API usage matching an NSPrivacyAccessedAPI category in your app that will require these changes in order to meet the requirements after May 1st (common categories might include NSPrivacyAccessedAPICategoryDiskSpace and NSPrivacyAccessedAPICategoryFileTimestamp).

What Expo is doing about it

Expo engineers are actively engaged with this issue, doing everything in our power ensure that your app submissions continue uninterrupted despite the relatively short notice:

• Adding privacy manifests to all affected modules maintained by Expo
• Tracking progress on key dependencies not maintained by Expo (e.g., this PR to add the manifest to react-native) and ensuring our version validation is updated accordingly as these updates go live.
• Providing guidance on how to add the privacy manifest to community-maintained modules
• Providing guidance and/or tooling to add the privacy info to your CNG-compatible app as needed

As this potentially requires action by any number of 3rd party library maintainers, we can't guarantee that you will not see a rejection for this reason from Apple after May 1st. However, we are focused on taking care of what is in our control, and providing guidance on what is outside of our control.

What's next

We expect to have more specific information about the steps we're taking to address this requirement, including more information about action required on your end to keep your iOS app submissions running smoothly past May 1st.
We will keep this issue open and will post updates here, so watch this issue to keep up-to-date!

Does this fix will also work on React Native or just expo?

Both

[andres9722]

Hello, any new news here? I'm having the same problem, I'm not sure if there is already a solution, thank you very much

[jpsierens88]

Will this fix be applied to expo 49 as well?

[dan-doyon-endear]

Will this fix be applied to expo 49 as well?

Would very much like a fix in expo 49 as this is a short timeframe and not ready to go to 50 yet.

[claudiutwin]

any updates?

[rooksFX]

I'm experiencing the same issue as below

❌ error: Multiple commands produce...  problem. Expo 49 with sentry-expo (latest version) which relies on sentry/react-native 5.10.0 I am following Apple's instructions to add the PrivacyInfo file.
With sentry/react-native 5.10.0, I get the "multiple commands" error.
If I upgrade my app's sentry/react-native to the fixed version 5.19.3, it builds and I can submit my app with no warning email, but my app crashes.
Is there any other way to resolve the "multiple commands produce" issue? Or any other guidance with Expo 49 or sentry-expo?

@kliakhovskii-brex The guide in your comment is for managed workflow right? How about for bare workflow?

How do I fix the issue w/ Sentry for a bare workflow project?

[rooksFX]

2. sentry/react-native

❌ error: Multiple commands produce... problem. Expo 49 with sentry-expo (latest version) which relies on sentry/react-native 5.10.0 I am following Apple's instructions to add the PrivacyInfo file.
With sentry/react-native 5.10.0, I get the "multiple commands" error.
If I upgrade my app's sentry/react-native to the fixed version 5.19.3, it builds and I can submit my app with no warning email, but my app crashes.
Is there any other way to resolve the "multiple commands produce" issue? Or any other guidance with Expo 49 or sentry-expo?
Edit: I also tried the solution proposed above by @kliakhovskii-brex , adding the plugin to the config file and I was successfully able to create the PrivacyInfo.xcprivacy file with expo prebuild, but I still get the same "Multiple commands produce.." error when building the app.

Did you have any luck figuring out a way past this. I'm in the same situation with SDK 49, using @kliakhovskii-brex solution, but was getting the multiple commands produce error as well. After upgrading @sentry/react-native to 5.19.3, I am able to successfully EAS build/submit, and after submitting the app to External Testing, I'm not receiving the email. BUT the app crashes now, which I assume is related the the @sentry/react-native upgrade.
Is there any word yet on Expo supporting SDK 49 on this issue yet?

we also use sentry, but still on sentry-expo version due to Expo 48. We upgraded it (and underlaying @sentry/react-native) to the latest version and seems to work though.

After some additional testing, I was able to get my app to build, submit, avoid the Apple email, and WORK. I wanted to document what I ended up doing for anyone else running into this challenge. We are running Expo SDK 49.

1. Used @kliakhovskii-brex plugin and updated app.json privacyManifestsinstructions following that post: (May 2024 iOS privacy manifest requirements tracking issue #27796 (comment))
2. Upgraded sentry-expo to 7.2.0 and @sentry/react-native to 5.22.0 (these are the most up to date versions as of this post)

Thanks again for all of the help in this thread!

How do I get pass the issue/error when upgrading sentry-expo and @sentry/react-native ? Our project is still at Expo 49 SDK and we are using Bare Workflow.

[mtnzorro]

2. sentry/react-native

❌ error: Multiple commands produce... problem. Expo 49 with sentry-expo (latest version) which relies on sentry/react-native 5.10.0 I am following Apple's instructions to add the PrivacyInfo file.
With sentry/react-native 5.10.0, I get the "multiple commands" error.
If I upgrade my app's sentry/react-native to the fixed version 5.19.3, it builds and I can submit my app with no warning email, but my app crashes.
Is there any other way to resolve the "multiple commands produce" issue? Or any other guidance with Expo 49 or sentry-expo?
Edit: I also tried the solution proposed above by @kliakhovskii-brex , adding the plugin to the config file and I was successfully able to create the PrivacyInfo.xcprivacy file with expo prebuild, but I still get the same "Multiple commands produce.." error when building the app.

Did you have any luck figuring out a way past this. I'm in the same situation with SDK 49, using @kliakhovskii-brex solution, but was getting the multiple commands produce error as well. After upgrading @sentry/react-native to 5.19.3, I am able to successfully EAS build/submit, and after submitting the app to External Testing, I'm not receiving the email. BUT the app crashes now, which I assume is related the the @sentry/react-native upgrade.
Is there any word yet on Expo supporting SDK 49 on this issue yet?

we also use sentry, but still on sentry-expo version due to Expo 48. We upgraded it (and underlaying @sentry/react-native) to the latest version and seems to work though.

After some additional testing, I was able to get my app to build, submit, avoid the Apple email, and WORK. I wanted to document what I ended up doing for anyone else running into this challenge. We are running Expo SDK 49.

1. Used @kliakhovskii-brex plugin and updated app.json privacyManifestsinstructions following that post: (May 2024 iOS privacy manifest requirements tracking issue #27796 (comment))
2. Upgraded sentry-expo to 7.2.0 and @sentry/react-native to 5.22.0 (these are the most up to date versions as of this post)

Thanks again for all of the help in this thread!

How do I get pass the issue/error when upgrading sentry-expo and @sentry/react-native ? Our project is still at Expo 49 SDK and we are using Bare Workflow.

I stopped getting the error once I upgraded those libraries to their most current versions: sentry-expo to 7.2.0 and @sentry/react-native to 5.22.0.

[ron-nuqui]

2. sentry/react-native

❌ error: Multiple commands produce... problem. Expo 49 with sentry-expo (latest version) which relies on sentry/react-native 5.10.0 I am following Apple's instructions to add the PrivacyInfo file.
With sentry/react-native 5.10.0, I get the "multiple commands" error.
If I upgrade my app's sentry/react-native to the fixed version 5.19.3, it builds and I can submit my app with no warning email, but my app crashes.
Is there any other way to resolve the "multiple commands produce" issue? Or any other guidance with Expo 49 or sentry-expo?
Edit: I also tried the solution proposed above by @kliakhovskii-brex , adding the plugin to the config file and I was successfully able to create the PrivacyInfo.xcprivacy file with expo prebuild, but I still get the same "Multiple commands produce.." error when building the app.

Did you have any luck figuring out a way past this. I'm in the same situation with SDK 49, using @kliakhovskii-brex solution, but was getting the multiple commands produce error as well. After upgrading @sentry/react-native to 5.19.3, I am able to successfully EAS build/submit, and after submitting the app to External Testing, I'm not receiving the email. BUT the app crashes now, which I assume is related the the @sentry/react-native upgrade.
Is there any word yet on Expo supporting SDK 49 on this issue yet?

we also use sentry, but still on sentry-expo version due to Expo 48. We upgraded it (and underlaying @sentry/react-native) to the latest version and seems to work though.

After some additional testing, I was able to get my app to build, submit, avoid the Apple email, and WORK. I wanted to document what I ended up doing for anyone else running into this challenge. We are running Expo SDK 49.

1. Used @kliakhovskii-brex plugin and updated app.json privacyManifestsinstructions following that post: (May 2024 iOS privacy manifest requirements tracking issue #27796 (comment))
2. Upgraded sentry-expo to 7.2.0 and @sentry/react-native to 5.22.0 (these are the most up to date versions as of this post)

Thanks again for all of the help in this thread!

How do I get pass the issue/error when upgrading sentry-expo and @sentry/react-native ? Our project is still at Expo 49 SDK and we are using Bare Workflow.

I stopped getting the error once I upgraded those libraries to their most current versions: sentry-expo to 7.2.0 and @sentry/react-native to 5.22.0.

I'm guessing you are using managed workflow?

[sainjay]

@mvaivre Thanks for pointing out the absolute path – for some reason I didn't think that this is a problem, while it quite obviously is a major one!
While .gitignoring the file is a good solution it may not be an option for some – a fix is merged and I'll deploy it for SDK50 soon

@aleqsio can we expect a newer version of Expo package today, or is it going to take awhile for this?

Not today, but I'll try to ship it asap next week

Hey @aleqsio ,

Referring to this commit: efa9096

Tried the newest released Expo 50.0.18 which is launched today. Still facing the error with absolute path. Changes you made seem to be in the code though:

Error Screenshot - Fastlane

Any advice how to fix, a workaround maybe? any suggestions is appreciated as May starts tomorrow 😅

[aleqsio]

@mvaivre Thanks for pointing out the absolute path – for some reason I didn't think that this is a problem, while it quite obviously is a major one!
While .gitignoring the file is a good solution it may not be an option for some – a fix is merged and I'll deploy it for SDK50 soon

@aleqsio can we expect a newer version of Expo package today, or is it going to take awhile for this?

Not today, but I'll try to ship it asap next week

Hey @aleqsio ,

Referring to this commit: efa9096

Tried the newest released Expo 50.0.18 which is launched today. Still facing the error with absolute path. Changes you made seem to be in the code though:

Error Screenshot - Fastlane

Any advice how to fix, a workaround maybe? any suggestions is appreciated as May starts tomorrow 😅

That is weird, are you sure you made a clean prebuild?

[KesoGizmoYoshi]

@mvaivre Thanks for pointing out the absolute path – for some reason I didn't think that this is a problem, while it quite obviously is a major one!
While .gitignoring the file is a good solution it may not be an option for some – a fix is merged and I'll deploy it for SDK50 soon

@aleqsio can we expect a newer version of Expo package today, or is it going to take awhile for this?

Not today, but I'll try to ship it asap next week

Hey @aleqsio ,
Referring to this commit: efa9096
Tried the newest released Expo 50.0.18 which is launched today. Still facing the error with absolute path. Changes you made seem to be in the code though:

Error Screenshot - Fastlane

Any advice how to fix, a workaround maybe? any suggestions is appreciated as May starts tomorrow 😅

That is weird, are you sure you made a clean prebuild?

Im having the same problem with a clean prebuild of 50.0.18. For now I solved it by adding the ios folder to .easignore :)

[sainjay]

That is weird, are you sure you made a clean prebuild?

@aleqsio @KesoGizmoYoshi updated my prebuild step to prebuild --clean. It's building fine, will upload to apple and update if everything goes well. Thanks Aleqsio for such quick responses and all the contributors to this issue.

[gboudreau]

For anyone on Expo SDK 48 ou 49, there is now a polyfill plugin to add support for the ios.privacyManifests config.
It is documented on the official Expo doc about this: https://docs.expo.dev/guides/apple-privacy/

For SDK versions below 50, use the expo-privacy-manifest-polyfill-plugin.

[statico]

Confirmed, this is working for us with Expo v49! Thank you all.

$ grep '"expo"' package.json
    "expo": "49.0.13",

$ grep sentry package.json
    "@sentry/react": "7.112.2",
    "@sentry/react-native": "5.22.0",
    "sentry-expo": "7.2.0",

// app.config.ts
const config: ExpoConfig = {
  ...
  plugins: [
    "expo-privacy-manifest-polyfill-plugin",
    ...
  ],
  ios: {
    ...
    // @ts-expect-error - this is a polyfill from expo-privacy-manifest-polyfill-plugin
    privacyManifests: {
      NSPrivacyAccessedAPITypes: [
        {
          NSPrivacyAccessedAPIType: "NSPrivacyAccessedAPICategoryFileTimestamp",
          NSPrivacyAccessedAPITypeReasons: ["CA92.1"],
        },
        {
          NSPrivacyAccessedAPIType: "NSPrivacyAccessedAPICategoryDiskSpace",
          NSPrivacyAccessedAPITypeReasons: ["CA92.1"],
        },
      ],
    },
  },

[rooksFX]

For anyone on Expo SDK 48 ou 49, there is now a polyfill plugin to add support for the ios.privacyManifests config. It is documented on the official Expo doc about this: https://docs.expo.dev/guides/apple-privacy/

For SDK versions below 50, use the expo-privacy-manifest-polyfill-plugin.

Will that work w/ Bare Workflow as well?

[nuno-sequeira]

If I make eas build -p ios without the privacy manifests, it builds. If I add the manifests that are at the bottom, it fails on Run fastlane.

Error:

Build failed: The "Run fastlane" step failed with an unknown error. Refer to "Xcode Logs" below for additional, more detailed logs.

cd /Users/expo/workingdir/build/ios

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang-stat-cache /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS17.2.sdk -o /Users/expo/Library/Developer/Xcode/DerivedData/SDKStatCaches.noindex/iphoneos17.2-21C52-884b7f60ac6761a492c03f282b824eb9.sdkstatcache

​

warning: Run script build phase '[CP-User] [Hermes] Replace Hermes for the right configuration, if needed' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'hermes-engine' from project 'Pods')

warning: Run script build phase '[CP-User] Generate app.config for prebuilt Constants.manifest' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'EXConstants' from project 'Pods')

note: Run script build phase '[Expo] Configure project' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'GoActive' from project 'GoActive')

note: Run script build phase 'Bundle React Native code and images' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'GoActive' from project 'GoActive')

warning: duplicate output file '/Users/expo/Library/Developer/Xcode/DerivedData/GoActive-dkwstoaptvjagofplkfcalhhmzgq/Build/Intermediates.noindex/ArchiveIntermediates/GoActive/InstallationBuildProductsLocation/Applications/GoActive.app/PrivacyInfo.xcprivacy' on task: PhaseScriptExecution [CP] Copy Pods Resources /Users/expo/Library/Developer/Xcode/DerivedData/GoActive-dkwstoaptvjagofplkfcalhhmzgq/Build/Intermediates.noindex/ArchiveIntermediates/GoActive/IntermediateBuildFilesPath/GoActive.build/Release-iphoneos/GoActive.build/Script-800E24972A6A228C8D4807E9.sh (in target 'GoActive' from project 'GoActive')

/Users/expo/workingdir/build/ios/Pods/Pods.xcodeproj: warning: The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 11.0, but the range of supported deployment target versions is 12.0 to 17.2.99. (in target 'react-native-blob-util-ReactNativeBlobUtilPrivacyInfo' from project 'Pods')

Dependencies from package.json:

"dependencies": {
    "@expo/config-plugins": "^7.8.0",
    "@expo/prebuild-config": "^6.7.0",
    "@expo/vector-icons": "14.0.0",
    "@kesha-antonov/react-native-action-cable": "^1.1.4",
    "@native-html/iframe-plugin": "^2.6.1",
    "@react-native-async-storage/async-storage": "1.21.0",
    "@react-native-community/datetimepicker": "7.6.1",
    "@react-navigation/bottom-tabs": "^6.5.2",
    "@react-navigation/native": "^6.1.1",
    "@react-navigation/native-stack": "^6.9.7",
    "@reduxjs/toolkit": "^1.9.1",
    "@types/tinycolor2": "^1.4.6",
    "axios": "^1.2.1",
    "babel-plugin-content-transformer": "^0.2.1-0",
    "date-fns": "^2.30.0",
    "eas-cli": "^8.0.0",
    "expo": "^50.0.17",
    "expo-dev-client": "~3.3.11",
    "expo-device": "~5.9.4",
    "expo-document-picker": "~11.10.1",
    "expo-file-system": "~16.0.9",
    "expo-font": "~11.10.3",
    "expo-image-picker": "~14.7.1",
    "expo-linear-gradient": "~12.7.2",
    "expo-linking": "~6.2.2",
    "expo-localization": "~14.8.4",
    "expo-location": "~16.5.5",
    "expo-media-library": "~15.9.2",
    "expo-notifications": "~0.27.7",
    "expo-splash-screen": "~0.26.5",
    "expo-status-bar": "~1.11.1",
    "i18n-js": "^4.3.0",
    "i18n-node-yaml": "^1.0.4",
    "i18next": "^23.2.11",
    "js-yaml": "^4.1.0",
    "jsc-android": "^250230.2.1",
    "moment": "^2.29.4",
    "react": "18.2.0",
    "react-big-calendar": "^1.6.9",
    "react-dom": "18.2.0",
    "react-i18next": "^13.0.2",
    "react-native": "0.73.6",
    "react-native-big-calendar": "^3.4.1",
    "react-native-blob-util": "^0.19.6",
    "react-native-calendars": "^1.1301.0",
    "react-native-chart-kit": "^6.12.0",
    "react-native-countdown-circle-timer": "^3.1.0",
    "react-native-document-picker": "^9.1.0",
    "react-native-drop-shadow": "^0.0.6",
    "react-native-flash-message": "^0.4.2",
    "react-native-gesture-handler": "~2.14.0",
    "react-native-gifted-chat": "^2.4.0",
    "react-native-linear-gradient": "^2.7.3",
    "react-native-localization": "^2.3.2",
    "react-native-reanimated": "~3.6.2",
    "react-native-reanimated-carousel": "^3.1.5",
    "react-native-render-html": "^6.3.4",
    "react-native-safe-area-context": "4.8.2",
    "react-native-screens": "~3.29.0",
    "react-native-select-dropdown": "^3.3.4",
    "react-native-svg": "14.1.0",
    "react-native-toast-message": "^2.2.0",
    "react-native-tts": "^4.1.0",
    "react-native-uuid": "^2.0.1",
    "react-native-vector-icons": "^9.2.0",
    "react-native-web": "~0.19.6",
    "react-native-webview": "13.6.4",
    "react-native-youtube": "^2.0.2",
    "react-redux": "^8.0.5",
    "redux": "^4.2.0",
    "redux-saga": "^1.2.2",
    "tinycolor2": "^1.6.0"
  },

Privacy manifests on app.json:

"privacyManifests": {
        "NSPrivacyAccessedAPITypes": [
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategorySystemBootTime",
            "NSPrivacyAccessedAPITypeReasons": [
              "35F9.1"
            ]
          },
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryUserDefaults",
            "NSPrivacyAccessedAPITypeReasons": [
              "CA92.1"
            ]
          },
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryFileTimestamp",
            "NSPrivacyAccessedAPITypeReasons": [
              "DDA9.1"
            ]
          },
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryDiskSpace",
            "NSPrivacyAccessedAPITypeReasons": [
              "85F4.1"
            ]
          }
        ]
      }

[wodin]

Will that work w/ Bare Workflow as well?

This might work for you:

• Rename ios to ios.orig
• Update app.json as needed
• Run npx expo prebuild -p ios
• Copy the generated privacy manifest to ios.orig
• Delete ios
• Rename ios.orig back to ios

[wodin]

Dependencies from package.json:

The following should not be installed as dependencies/devDependencies:

    "@expo/config-plugins": "^7.8.0",
    "@expo/prebuild-config": "^6.7.0",
    "eas-cli": "^8.0.0",

You should generally also avoid overrides/resolutions for those packages.

By the way, are you using JSC?

    "jsc-android": "^250230.2.1",

And you seem to have some duplication. e.g.:

    "expo-document-picker": "~11.10.1",
    "react-native-document-picker": "^9.1.0",

    "expo-linear-gradient": "~12.7.2",
    "react-native-linear-gradient": "^2.7.3",

[next6leo]

expo-privacy-manifest-polyfill-plugin this does not support expo go. all my apps is using expo go(Managed) is it possible to support expo go since is expo things?

[KarlaSaenz]

@statico Did you receive any notification from Apple after submitting to the store?

[BoavistaLudwig]

I can`t pass eas build

[Privacy Manifest Aggregation] Appending aggregated reasons to existing PrivacyInfo.xcprivacy file.
[Privacy Manifest Aggregation] Reading .xcprivacy files to aggregate all used Required Reason APIs.
[!] An error occurred while processing the post-install hook of the Podfile.
no implicit conversion of nil into Array
/Users/expo/workingdir/build/node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:115:in +' /Users/expo/workingdir/build/node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:115:in block (5 levels) in get_used_required_reason_apis'
/Users/expo/workingdir/build/node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in each' /Users/expo/workingdir/build/node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in block (4 levels) in get_used_required_reason_apis'
/Users/expo/workingdir/build/node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in each' /Users/expo/workingdir/build/node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in block (3 levels) in get_used_required_reason_apis'
/Users/expo/workingdir/build/node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:105:in each' /Users/expo/workingdir/build/node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:105:in block (2 levels) in get_used_required_reason_apis'
/Users/expo/workingdir/build/node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:104:in each' /Users/expo/workingdir/build/node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:104:in block in get_used_required_reason_apis'
/Users/expo/workingdir/build/node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:102:in each' /Users/expo/workingdir/build/node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:102:in get_used_required_reason_apis'
/Users/expo/workingdir/build/node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:18:in `add_aggregated_privacy_manifest'

with

"privacyManifests": {
        "NSPrivacyAccessedAPITypes": [
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryUserDefaults",
            "NSPrivacyAccessedAPITypeReasons": ["CA92.1"]
          },
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategorySystemBootTime",
            "NSPrivacyAccessedAPITypeReasons": ["8FFB.1"]
          },
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryDiskSpace",
            "NSPrivacyAccessedAPITypeReasons": ["E174.1"]
          },
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryFileTimestamp",
            "NSPrivacyAccessedAPITypeReasons": ["3B52.1"]
          }
        ]
      },
      

I am on the latest npx expo install --fix with no issue @ expo-doctor

[rooksFX]

@sentry/react-native

How did you get passed the error w/ @sentry/react-native? Did you silenced Expo Doctor?

[next6leo]

expo-privacy-manifest-polyfill-plugin Error: Problem validating fields in app.json. Learn more.
• Field: ios - should NOT have additional property 'privacyManifests'. SDK 49 why eas build does not recognize privacyManifests ??

[rooksFX]

Will that work w/ Bare Workflow as well?

This might work for you:

• Rename ios to ios.orig
• Update app.json as needed
• Run npx expo prebuild -p ios
• Copy the generated privacy manifest to ios.orig
• Delete ios
• Rename ios.orig back to ios

@wodin I'm really confused now. How were the others still in Expo 49 got passed the issue w/ @sentry/react-native?
I just realized that the pollyfil is really for managed workflow.

[rooksFX]

@sentry/react-native

@statico How were you able to get pass the error w/ @sentry/react-native when running Expo Doctor?

[aleqsio]

@next6leo Expo Go will have a privacy manifest set when it is published, no need to do anything there.
I also wouldn't worry about the validation messages – those are just warnings since you're using a non-default plugin that is reading from a different place then expected, BUT this is on purpose so that it's easier to maintain and upgrade from it :)

[statico]

How were you able to get pass the error w/ @sentry/react-native when running Expo Doctor?

@rooksFX I have no idea. Expo Doctor has been complaining about version mismatches since we started the project a year ago. Trying to fix every version mismatch is near impossible and results in madness and hair loss. I've been ignoring the Expo Doctor warnings — the app works, and users are happy.

Did you receive any notification from Apple after submitting to the store?

@KarlaSaenz Yes, I just tried submitting a build and got an "Invalid Binary" error and an email with eight messages that looked like this:

Please correct the following issues and upload a new binary to App Store Connect.

ITMS-91055: Invalid API reason declaration - The PrivacyInfo.xcprivacy for the “GoogleMaps.bundle/GMSCoreResources.bundle/GMSShaders.metallib” file contains “CA92.1” as the value for a NSPrivacyAccessedAPITypeReasons key instead of a valid reason code for using an API in the NSPrivacyAccessedAPICategoryFileTimestamp category. Values for NSPrivacyAccessedAPITypeReasons keys in any 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.

I'm currently investigating.

[wodin]

Expo Doctor has been complaining about version mismatches since we started the project a year ago. Trying to fix every version mismatch is near impossible and results in madness and hair loss.

That should not normally be the case. What does your package.json look like?

[statico]

@wodin I pasted our package.json and npx expo-doctor output here. Feel free to comment there but let's keep this thread on topic about the privacy manifest issues.

[statico]

Apparently I misread the Describing Use of Required Reason API document. I don't know why Google needs these APIs, I've tried googling, and I don't know how to figure out where Frameworks/libswift_Concurrency.dylib comes from or if it's related to Google at all.

Since we're a small company with limited time and resources, I've chosen these reasons in an in-good-faith, best-effort attempt at describing why they're used:

    // @ts-expect-error - this is a polyfill from expo-privacy-manifest-polyfill-plugin
    // See https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api
    privacyManifests: {
      NSPrivacyAccessedAPITypes: [
        {
          NSPrivacyAccessedAPIType: "NSPrivacyAccessedAPICategoryFileTimestamp",
          // I think this happens because we allow users to pick files from their device
          NSPrivacyAccessedAPITypeReasons: ["3B52.1"],
        },
        {
          NSPrivacyAccessedAPIType: "NSPrivacyAccessedAPICategoryDiskSpace",
          // My guess is this is part of a disk caching system for Google's APIs
          NSPrivacyAccessedAPITypeReasons: ["E174.1"],
        },
      ],
    },

Full package.json here.

I'm beginning to think that the only way to write software in a team that's smaller than 1,000 people is to never rely on third-party dependencies at all, and that I should give up entirely and start an alpaca farm.

[statico]

@KarlaSaenz et al, we are successful!

[KarlaSaenz]

@statico Thanks for the reply!