Is the issue still on the Firebase side or is it on Apple’s side? I do see there’s a bunch of .bundle files inside the .app, and they have PrivacyInfo.xcprivacy files inside them.

As far as I can tell, it’s entirely on Apple’s side.

The issue:

• When you use SPM (or CocoaPods if it’s set to use static linking), the code for your dependencies is all placed directly in the main binary for the app. But the corresponding PrivacyInfo.xcprivacy files can’t all be placed directly in the main app bundle without clashing, and there’s no automatic tooling for merging those into a single PrivacyInfo.xcprivacy, so instead a resource bundle (.bundle) for each package is created and nested in the .app, and the PrivacyInfo.xcprivacy file for each package is placed in its corresponding .bundle.

• This is in contrast with how things are structured when dynamically linked .frameworks are used. In that scenario, the .app binary contains just the top-level app code, and there’s a .framework bundle for each dependency that contains both the binary for its code and its PrivacyInfo.xcprivacy file (along with any other resources).

• The tooling that Apple is using in its App Store Connect privacy manifest validator seems to only look at the PrivacyInfo.xcprivacy files that are placed directly in the main app bundle or directly in a .framework. It doesn’t actually look at the nested resource bundles created in the static linking case.

So effectively Apple is ignoring the privacy manifests for all dependencies when you use SPM, Apple’s first-party recommended way of managing dependencies. Which is pretty maddening, and makes it seem like the team that created the App Store Connect “required reasons api” validator didn’t actually talk to the people working the privacy manifest support for SPM/Xcode.

Meanwhile, as far as I know, Apple still hasn’t publicly admitted this is the case, or acknowledged if this bug/limitation is something that they intend to address on their end.

If they don’t address it, the only current workaround is to manually create your own top-level PrivacyInfo.xcprivacy files for your apps, and include in them a merging of the contents of the PrivacyInfo.xcprivacy files from your dependencies (in particular the NSPrivacyAccessedAPITypes sections).

But if that’s the expected way of doing things, I think it really undermines the intended purpose of privacy manifests.

Hi @Digipom, thanks for reporting and apologies for the trouble. I was able to reproduce the above behavior. There appears to be an issue with how R.R. API usage attribution is validated when using static frameworks. If you inspect the app bundle, you should see privacy manifests from Firebase that justify this API usage. But since the SDK symbols are statically linked into the main app, the SDK resource bundles do not seem to be taken into account when checking for R.R. API usage.

We have filed a feedback with Apple and I will keep this thread updated.

Is this still being looked into?

Updating to 10.24.0 removed the warning for NSPrivacyAccessedAPICategorySystemBootTime, but we are still getting warnings for NSPrivacyAccessedAPICategoryDiskSpace and NSPrivacyAccessedAPICategoryFileTimestamp.

Unfortunately it isn’t clear from Apple’s messaging if it is coming from Firebase or from another third party library in our project.

@ncooke3 why was this closed?

This issue is still open. They closed a duplicate issue.

EDIT: The number of subscribers on this issue has gotten fairly large so let’s all take extra care to not spam the thread ❤️

@ncooke3 Thank you for your answer. I have a privacy manifest included to my project. In this manifest I declared the reason of using the UserDefaults API. Even if I have this privacy manifest - which is silenced the warning about the userdefaults - I still get warning about NSPrivacyAccessedAPICategorySystemBootTime and NSPrivacyAccessedAPICategoryFileTimestamp which are used by firebase. I would include these to my privacy manifest, but the problem is that I don’t know the exact relevant reasons since I don’t know how firebase uses these APIs exactly…

Hi all, even with 10.24.0 is have the same issue

Thanks, @adrianvintu, that is the behavior I’m seeing. I was also able to reproduce when depending on SwiftPM targets from source. We have filed two feedback tickets with Apple for this (they aren’t publicly visible but are FB13691093 & FB13687188). I don’t yet have a response to share, but will update accordingly!

I think there’s an issue with GoogleUtilities not having a privacy manifest for each target: https://github.com/google/GoogleUtilities/issues/150

(Relevant post from Apple Engineer: https://forums.developer.apple.com/forums/thread/742221?answerId=776008022#776008022)

Hi, I’m experiencing the similar issue, having a warning from Apple regarding NSPrivacyAccessedAPICategoryDiskSpace

I’ve looked through Privacy manifest included with Firebase SDK 10.24.0, and I couldn’t find any declaration of using these APIs

Knowing there is a feature in Crashlytics backend that shows available space on the device during the crash, I assume that issue is on Firebase side of using disk space API calls without declaring them in Privacy manifest. If I’m correct, hope it could be addresses in the next releases.

PS: we are using dynamic linking with cocoapods

Hi,

Do you know if these new privacy declarations mean that apps would have to explicitly ask for permission to report crashes via Firebase Crashlytics?

For reference NSPrivacyAccessedAPICategorySystemBootTime

3D61.1 Declare this reason to include system boot time information in an optional bug report that the person using the device chooses to submit. The system boot time information must be prominently displayed to the person as part of the report.

Information accessed for this reason, or any derived information, may be sent off-device only after the user affirmatively chooses to submit the specific bug report including system boot time information, and only for the purpose of investigating or responding to the bug report.

I’ve installed Firebase 10.23.0 for iOS via CocoaPods. When I search in my Xcode project for the mentioned privacy reason “3D61.1” in your article, I get no matches. However, I do get a match for another reason for NSPrivacyAccessedAPICategorySystemBootTime; “35F9.1”:

Declare this reason to access the system boot time in order to measure the amount of time that has elapsed between events that occurred within the app or to perform calculations to enable timers. Information accessed for this reason, or any derived information, may not be sent off-device. There is an exception for information about the amount of time that has elapsed between events that occurred within the app, which may be sent off-device.

This reason does not demand user permission by Apple.

I did verify all other reasons and they all do comply. Google has even removed collecting Disk Space (which was shown at the “Data” tab of a Crashlytics log), so there is no need to report a reason for NSPrivacyAccessedAPICategoryDiskSpace.

Hi,

Do you know if these new privacy declarations mean that apps would have to explicitly ask for permission to report crashes via Firebase Crashlytics?

For reference NSPrivacyAccessedAPICategorySystemBootTime

3D61.1 Declare this reason to include system boot time information in an optional bug report that the person using the device chooses to submit. The system boot time information must be prominently displayed to the person as part of the report.

Information accessed for this reason, or any derived information, may be sent off-device only after the user affirmatively chooses to submit the specific bug report including system boot time information, and only for the purpose of investigating or responding to the bug report.

Firebase Firestore and GTMSessionFetcher are missing the FileTimeStampAPI key in their XCPrivacy file. They use TimeStamp API’s (stat) and does not declare them. I cannot release my app until these are resolved as our release date is after May 1st.

I’m still getting alerts with 10.23.1.

FIrebaseAnalytics is a statically linked binary.

I use CocoaPods to integrate Crashlytics included in Firebase Apple SDK 10.22.0, and when submitting for review on the App Store, I encountered the same warning as this issue.

I statically link the framework with the following settings in the Podfile.

  use_frameworks! :linkage => :static
  pod 'FirebaseAnalytics'
  pod 'FirebaseCrashlytics'

Although this issue is tagged as Swift Package Manager, is it the same issue that occurred in my environment when using CocoaPods?

I see a lot of apps on the interwebs are using Firebase and Google Maps are complaining about this, mainly that Apple does not merge the privacy codes.

Any news are welcome.

It seems like things are working as intended now, so I believe this has been addressed as of the May 1 deadline. I’m going to close this issue now. Please feel free to open a new issue if anything else comes up.

@nczoltan, yes, that is expected. App Store Connect’s R.R. API validation logic still isn’t processing privacy manifests from frameworks. It only accounts for the privacy manifest in the root of the app, which explains why @Digipom’s approach suppresses the warnings.

Yes. The same issue occurs with CocoaPods when linking statically versus dynamically. As discussed above, as far as we can tell, this is an Apple issue, so it may help to send additional feedback to Apple.

We will at some point, but wanted to preserve the optionality for now, since 1.22.2 is still functional and anyone who cares about the warning can update.

@ncooke3 I’ve been reading Apple’s documentation and think I might have a clue.

I saw you made a new release on the forked leveldb this repo uses that adds the PrivacyInfo file. Firebase does not use this version yet though.

Do you think updating firebase to use leveldb 1.22.4 would solve the issue?

Maybe the warning is still delayed, but I was able to release a new build to TestFlight with 10.25.0 and I didn’t get any warnings. Was there actually an issue on Firebase’s side that was fixed with the move to 10.25.0? Will update in case the warning does come through.

The issue was on App Store Connect’s validation tooling-- it appeared to be ignoring SDK’s privacy manifests for statically linked SDKs. In Firebase 10.25.0, some R.R. API were removed to lessen the surface area that exposed this problem.

I submitted a build on April 30th (it was a patch to the live version that didn’t have any privacy manifests at all) and got it approved and available on the AppStore, and didn’t get any warning email. Paul mentioned here that Apple put some news up on the 26th April that suggests it will only affect new apps and apps that add dependencies on the list after the 1st of May, so it looks like existing apps with existing dependencies are not affected by this change in requirements. (but will be in some future announcement by Apple)

Starting May 1, 2024, new or updated apps that have a newly added third-party SDK that‘s on the list of commonly used third-party SDKs will need …

Maybe the warning is still delayed, but I was able to release a new build to TestFlight with 10.25.0 and I didn’t get any warnings. Was there actually an issue on Firebase’s side that was fixed with the move to 10.25.0? Will update in case the warning does come through.

Hi, I think I have the same problem , using cocoadpods to, even if firebase sdk, crashlytics, messaging and other is up to date I still have the error for NSPrivacyAccessedAPICategoryDiskSpace and NSPrivacyAccessedAPICategorySystemBootTime. I dont know what to do. Did I need to add reason type in my privacy that I think can match the sdk, or is it a bad Idea. Is Apple really gonna block new version for app already in the store may 1st ?

Knowing there is a feature in Crashlytics backend that shows available space on the device during the crash, I assume that issue is on Firebase side of using disk space API calls without declaring them in Privacy manifest. If I’m correct, hope it could be addresses in the next releases.

Hi @fannt & @adrianvintu, Crashlytics’s disk space reporting feature was removed in 10.22.0, so the warning should not be originating from Crashlytics on versions 10.22.0 or later.

@ncooke3 Thank you for your answer. I have a privacy manifest included to my project. In this manifest I declared the reason of using the UserDefaults API. Even if I have this privacy manifest - which is silenced the warning about the userdefaults - I still get warning about NSPrivacyAccessedAPICategorySystemBootTime and NSPrivacyAccessedAPICategoryFileTimestamp which are used by firebase. I would include these to my privacy manifest, but the problem is that I don’t know the exact relevant reasons since I don’t know how firebase uses these APIs exactly…

Easy: just search in the subfolders of your project for PrivacyInfo.xcprivacy file. You will get the privacy infos for severar packages, like firebase and google. See attached sameple firebase ns.txt

Then gather the NS declarations from the different files, and merge them when needed, like below

		<dict>
			<key>NSPrivacyAccessedAPIType</key>
			<string>NSPrivacyAccessedAPICategoryUserDefaults</string>
			<key>NSPrivacyAccessedAPITypeReasons</key>
			<array>
				<string>1C8F.1</string>
				<string>C56D.1</string>
			</array>
		</dict>

@adrianvintu, on the right hand side of the first image, no targets are checked for the Target Membership section. I suspect that if you checked the boxes for Runner and Share Extension, the privacy manifest would be included in the app bundle when archiving.

Hi @crleonard, 10.24.0 just finished releasing.

Is there anything I can send you that would be useful to add details to that feedback you filed?

No, I think the ticket I filed is sufficient, but thank you. I’ll continue to keep this bug updated for when I receive an official response on the ticket we have filed.

Correct:

% nm -gU /Users/tomhamming/Library/Developer/Xcode/DerivedData/iOS-dnhixupbtwibvndyouqzyexefztd/Build/Products/Debug-iphonesimulator/BRFree.app/Frameworks/FirebaseCrashlytics.framework/FirebaseCrashlytics /Users/tomhamming/Library/Developer/Xcode/DerivedData/iOS-dnhixupbtwibvndyouqzyexefztd/Build/Products/Debug-iphonesimulator/BRFree.app/Frameworks/FirebaseCrashlytics.framework/FirebaseCrashlytics: no symbols

Which makes it super weird that the binary scanner tool is finding symbols there…

% file ~/Library/Developer/Xcode/DerivedData/iOS-dnhixupbtwibvndyouqzyexefztd/Build/Products/Debug-iphonesimulator/BRFree.app/Frameworks/FirebaseCrashlytics.framework/FirebaseCrashlytics/
/Users/tomhamming/Library/Developer/Xcode/DerivedData/iOS-dnhixupbtwibvndyouqzyexefztd/Build/Products/Debug-iphonesimulator/BRFree.app/Frameworks/FirebaseCrashlytics.framework/FirebaseCrashlytics/: cannot open `/Users/tomhamming/Library/Developer/Xcode/DerivedData/iOS-dnhixupbtwibvndyouqzyexefztd/Build/Products/Debug-iphonesimulator/BRFree.app/Frameworks/FirebaseCrashlytics.framework/FirebaseCrashlytics/' (Not a directory)

If I navigate to that file in Finder, it’s a 35kb file.

Yes. What Xcode are you using?

Xcode 15.3 (15E204a)

After upgrading the Firebase SDK to version 10.23.0, the warning for ‘NSPrivacyAccessedAPICategoryDiskSpace’ is no longer appearing. However, I am still seeing other warnings — ‘NSPrivacyAccessedAPICategoryFileTimestamp’ and ‘NSPrivacyAccessedAPICategoryUserDefaults’. I integrated the Firebase SDK using Swift Package Manager.

This proofs that the implementation of the Privacy files within the Firebase SDK is working as expected. Are you 100% sure that the 2 remaining ones are not related to the code of your own app, or any other 3rd party library?

Our own app also had still 3 warnings remaining. Among themNSPrivacyAccessedAPICategoryUserDefaults, which makes sense since we use NSUserDefaults in our own app. The Apple support page which is referred in the email from App Store Connect, provides sufficient information about functions and methods that you can just search for in your Xcode project. For example for NSPrivacyAccessedAPICategorySystemBootTime it shows systemUptime. When searching for this in our code, we found calls to [[NSProcessInfo processInfo] systemUptime] in our own logic. This means that we are responsible to add a Privacy file ourselves, for example as instructed here. Don’t forget to assign the added Privacy file to the proper target(s).

After submitting the new Build with this Privacy file, we didn’t receive the email from App Store Connect anymore ✅

When we uploaded a build with recent added usage of Firebase Messaging from a notification extension to TestFlight, we got these reported for the extension:

NSPrivacyAccessedAPICategoryFileTimestamp NSPrivacyAccessedAPICategoryUserDefaults

There were no other edits to the notification extension, so what I assume is these are related to FirebaseMessaging, but I couldn’t see them mentioned here.

Same issue here with CocoaPods, I upgraded a few days ago Firebase to 10.23.1 and submitted for review and we still have the same warnings. Will SwiftPM fix also solve the issue when distributing the SDK through CocoaPods?

Possibly related: https://github.com/apple/swift-package-manager/issues/7317