expo
expo copied to clipboard
expo
May 2024 iOS privacy manifest requirements tracking issue
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!
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?
edit ~3 months later: I published my app and by the time I needed to submit a new build, expo had already added the privacy manifest to their eas build system. It took almost no effort on my part. Thanks guys! 🙃
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.
Can the description be added manually in Xcode (expo's prebuilded apps)?
Which content should be used in that strings?
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...
@adrielschmitz You shouldn't be adding this to the .plist file, but to the new privacy manifest file (PrivacyInfo.xcprivacy)
@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>
@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 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...
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.
@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! 👍
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?
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 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
NSPrivacyAccessedAPICategoryFileTimestampyou chose the reasonC617.1was 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.
Async Storage added privacy manifest.
https://github.com/react-native-async-storage/async-storage/pull/1075
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
NSPrivacyAccessedAPIcategory in your app that will require these changes in order to meet the requirements after May 1st (common categories might includeNSPrivacyAccessedAPICategoryDiskSpaceandNSPrivacyAccessedAPICategoryFileTimestamp).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?
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
NSPrivacyAccessedAPIcategory in your app that will require these changes in order to meet the requirements after May 1st (common categories might includeNSPrivacyAccessedAPICategoryDiskSpaceandNSPrivacyAccessedAPICategoryFileTimestamp).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
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
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.
React Native Gesture Handler does not need a privacy manifest anymore, fixed in version 2.16.0.
https://github.com/software-mansion/react-native-gesture-handler/pull/2830
@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
NSPrivacyAccessedAPICategoryFileTimestampyou chose the reasonC617.1was 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.
For Expo how to impede this file into ios folder? just cp will work?
@adrielschmitz I wrote a plugin to add the privacy file into xcode project. Unfortunately, still got the luck letter.
const { withPlugins, withXcodeProject } = require("@expo/config-plugins");
const fs = require("fs");
const path = require("path");
const withPrivacyDeclaration = cnf => {
return withXcodeProject(cnf, config => {
const privacyInfoPath = path.join(
config.modRequest.platformProjectRoot,
"../PrivacyInfo.xcprivacy"
);
if (!fs.existsSync(privacyInfoPath)) {
console.error(
`PrivacyInfo.xcprivacy file not found at ${privacyInfoPath}`
);
return config;
}
const fileContent = fs.readFileSync(privacyInfoPath, "utf8");
const filePath = path.join(
config.modRequest.platformProjectRoot,
"PrivacyInfo.xcprivacy"
);
fs.writeFileSync(filePath, fileContent);
const xcodeProject = config.modResults;
// Add a new file to the project
const pbxGroupKey = xcodeProject.pbxCreateGroup("PrivacyInfo");
const targetUUID = xcodeProject.getFirstTarget().uuid;
xcodeProject.addSourceFile(filePath, { target: targetUUID }, pbxGroupKey);
return config;
});
};
function withPrivacy(config) {
return withPlugins(config, [withPrivacyDeclaration]);
}
module.exports = withPrivacy;
help plz, how to add the file in expo. Thanks in advance.
Why can't you just wait for Expo to add the privacy manifest to relevant libraries? And if it's your own library, maybe just wait for Expo to give further instructions?
help plz, how to add the file in expo. Thanks in advance.
Why can't you just wait for Expo to add the privacy manifest to relevant libraries? And if it's your own library, maybe just wait for Expo to give further instructions?
what about other libraries not maintained by Expo? Is a global manifest better?
help plz, how to add the file in expo. Thanks in advance.
Why can't you just wait for Expo to add the privacy manifest to relevant libraries? And if it's your own library, maybe just wait for Expo to give further instructions?
what about other libraries not maintained by Expo? Is a global manifest better?
Any specific library you have in mind? Like React Native team will take care of the libraries they maintain.
help plz, how to add the file in expo. Thanks in advance.
Why can't you just wait for Expo to add the privacy manifest to relevant libraries? And if it's your own library, maybe just wait for Expo to give further instructions?
what about other libraries not maintained by Expo? Is a global manifest better?
Any specific library you have in mind? Like React Native team will take care of the libraries they maintain.
react-native-fs Hugely depended upon library, not maintained anymore
Yes expo has its own plugin for that, but that is a great example of a library a lot of people will still have and have an issue with
help plz, how to add the file in expo. Thanks in advance.
Why can't you just wait for Expo to add the privacy manifest to relevant libraries? And if it's your own library, maybe just wait for Expo to give further instructions?
what about other libraries not maintained by Expo? Is a global manifest better?
Any specific library you have in mind? Like React Native team will take care of the libraries they maintain.
react-native-fsHugely depended upon library, not maintained anymore Yes expo has its own plugin for that, but that is a great example of a library a lot of people will still have and have an issue with
https://github.com/birdofpreyru/react-native-fs/issues/32
Have you looked at this fork? There seems to be a fix in progress.