firebase-ios-sdk
firebase-ios-sdk copied to clipboard
firebase
App Store Connect warnings that API usage is not being declared by Firebase
Description
I updated to Firebase 10.22.1, but App Store Connect is still warning of APIs such as mach_absolute_time():
ITMS-91053: Missing API declaration - Your app’s code in the “
System boot time APIs The following APIs for accessing the system boot time require reasons for use. Use the string NSPrivacyAccessedAPICategorySystemBootTime as the value for the NSPrivacyAccessedAPIType key in your NSPrivacyAccessedAPITypes dictionary. systemUptime mach_absolute_time() In your NSPrivacyAccessedAPITypeReasons array, supply the relevant values from the list below. 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.
Reproducing the issue
I'm using FirebaseAnalyticsWithoutAdIdSupport and FirebaseCrashlytics
Firebase SDK Version
10.22.1
Xcode Version
15.3
Installation Method
Swift Package Manager
Firebase Product(s)
Analytics, Crashlytics
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved
Expand Package.resolved snippet
{
"pins" : [
{
"identity" : "abseil-cpp-binary",
"kind" : "remoteSourceControl",
"location" : "https://github.com/google/abseil-cpp-binary.git",
"state" : {
"revision" : "df308b8b46607675f2b9ec8e569109008f9155ce",
"version" : "1.2022062300.1"
}
},
{
"identity" : "app-check",
"kind" : "remoteSourceControl",
"location" : "https://github.com/google/app-check.git",
"state" : {
"revision" : "3e464dad87dad2d29bb29a97836789bf0f8f67d2",
"version" : "10.18.1"
}
},
{
"identity" : "cocoalumberjack",
"kind" : "remoteSourceControl",
"location" : "https://github.com/CocoaLumberjack/CocoaLumberjack.git",
"state" : {
"revision" : "4b8714a7fb84d42393314ce897127b3939885ec3",
"version" : "3.8.5"
}
},
{
"identity" : "collectionconcurrencykit",
"kind" : "remoteSourceControl",
"location" : "https://github.com/JohnSundell/CollectionConcurrencyKit.git",
"state" : {
"revision" : "b4f23e24b5a1bff301efc5e70871083ca029ff95",
"version" : "0.2.0"
}
},
{
"identity" : "cryptoswift",
"kind" : "remoteSourceControl",
"location" : "https://github.com/krzyzanowskim/CryptoSwift.git",
"state" : {
"revision" : "7892a123f7e8d0fe62f9f03728b17bbd4f94df5c",
"version" : "1.8.1"
}
},
{
"identity" : "devicekit",
"kind" : "remoteSourceControl",
"location" : "https://github.com/devicekit/DeviceKit.git",
"state" : {
"revision" : "fe41d18eccd92a115cffaa35dfff03018c67e635",
"version" : "5.2.2"
}
},
{
"identity" : "firebase-ios-sdk",
"kind" : "remoteSourceControl",
"location" : "https://github.com/firebase/firebase-ios-sdk",
"state" : {
"revision" : "be49849dcba96f2b5ee550d4eceb2c0fa27dade4",
"version" : "10.22.1"
}
},
{
"identity" : "googleappmeasurement",
"kind" : "remoteSourceControl",
"location" : "https://github.com/google/GoogleAppMeasurement.git",
"state" : {
"revision" : "482cfa4e5880f0a29f66ecfd60c5a62af28bd1f0",
"version" : "10.22.1"
}
},
{
"identity" : "googledatatransport",
"kind" : "remoteSourceControl",
"location" : "https://github.com/google/GoogleDataTransport.git",
"state" : {
"revision" : "a637d318ae7ae246b02d7305121275bc75ed5565",
"version" : "9.4.0"
}
},
{
"identity" : "googleutilities",
"kind" : "remoteSourceControl",
"location" : "https://github.com/google/GoogleUtilities.git",
"state" : {
"revision" : "26c898aed8bed13b8a63057ee26500abbbcb8d55",
"version" : "7.13.1"
}
},
{
"identity" : "grpc-binary",
"kind" : "remoteSourceControl",
"location" : "https://github.com/google/grpc-binary.git",
"state" : {
"revision" : "ea4cb5cc0c39c732b85386263116d2e2fdbbdc61",
"version" : "1.49.2"
}
},
{
"identity" : "gtm-session-fetcher",
"kind" : "remoteSourceControl",
"location" : "https://github.com/google/gtm-session-fetcher.git",
"state" : {
"revision" : "76135c9f4e1ac85459d5fec61b6f76ac47ab3a4c",
"version" : "3.3.1"
}
},
{
"identity" : "interop-ios-for-google-sdks",
"kind" : "remoteSourceControl",
"location" : "https://github.com/google/interop-ios-for-google-sdks.git",
"state" : {
"revision" : "2d12673670417654f08f5f90fdd62926dc3a2648",
"version" : "100.0.0"
}
},
{
"identity" : "leveldb",
"kind" : "remoteSourceControl",
"location" : "https://github.com/firebase/leveldb.git",
"state" : {
"revision" : "43aaef65e0c665daadf848761d560e446d350d3d",
"version" : "1.22.4"
}
},
{
"identity" : "nanopb",
"kind" : "remoteSourceControl",
"location" : "https://github.com/firebase/nanopb.git",
"state" : {
"revision" : "b7e1104502eca3a213b46303391ca4d3bc8ddec1",
"version" : "2.30910.0"
}
},
{
"identity" : "promises",
"kind" : "remoteSourceControl",
"location" : "https://github.com/google/promises.git",
"state" : {
"revision" : "540318ecedd63d883069ae7f1ed811a2df00b6ac",
"version" : "2.4.0"
}
},
{
"identity" : "sourcekitten",
"kind" : "remoteSourceControl",
"location" : "https://github.com/jpsim/SourceKitten.git",
"state" : {
"revision" : "b6dc09ee51dfb0c66e042d2328c017483a1a5d56",
"version" : "0.34.1"
}
},
{
"identity" : "swift-argument-parser",
"kind" : "remoteSourceControl",
"location" : "https://github.com/apple/swift-argument-parser.git",
"state" : {
"revision" : "8f4d2753f0e4778c76d5f05ad16c74f707390531",
"version" : "1.2.3"
}
},
{
"identity" : "swift-log",
"kind" : "remoteSourceControl",
"location" : "https://github.com/apple/swift-log",
"state" : {
"revision" : "e97a6fcb1ab07462881ac165fdbb37f067e205d5",
"version" : "1.5.4"
}
},
{
"identity" : "swift-protobuf",
"kind" : "remoteSourceControl",
"location" : "https://github.com/apple/swift-protobuf.git",
"state" : {
"revision" : "65e8f29b2d63c4e38e736b25c27b83e012159be8",
"version" : "1.25.2"
}
},
{
"identity" : "swift-syntax",
"kind" : "remoteSourceControl",
"location" : "https://github.com/apple/swift-syntax.git",
"state" : {
"revision" : "6ad4ea24b01559dde0773e3d091f1b9e36175036",
"version" : "509.0.2"
}
},
{
"identity" : "swiftlint",
"kind" : "remoteSourceControl",
"location" : "https://github.com/realm/SwiftLint",
"state" : {
"revision" : "f17a4f9dfb6a6afb0408426354e4180daaf49cee",
"version" : "0.54.0"
}
},
{
"identity" : "swiftytexttable",
"kind" : "remoteSourceControl",
"location" : "https://github.com/scottrhoyt/SwiftyTextTable.git",
"state" : {
"revision" : "c6df6cf533d120716bff38f8ff9885e1ce2a4ac3",
"version" : "0.9.0"
}
},
{
"identity" : "swxmlhash",
"kind" : "remoteSourceControl",
"location" : "https://github.com/drmohundro/SWXMLHash.git",
"state" : {
"revision" : "a853604c9e9a83ad9954c7e3d2a565273982471f",
"version" : "7.0.2"
}
},
{
"identity" : "yams",
"kind" : "remoteSourceControl",
"location" : "https://github.com/jpsim/Yams.git",
"state" : {
"revision" : "0d9ee7ea8c4ebd4a489ad7a73d5c6cad55d6fed3",
"version" : "5.0.6"
}
}
],
"version" : 2
}
If using CocoaPods, the project's Podfile.lock
Expand Podfile.lock snippet
Replace this line with the contents of your Podfile.lock!
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
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.
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.
Possibly related: https://github.com/apple/swift-package-manager/issues/7317
@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?
@jjkaufman pod update or Package -> update to latest should update leveldb to 1.22.4
@paulb777 good point, but would it make sense to update min to 1.22.4 in Firebases Package.swift to ensure the warning / issues don't come up?
Currently its 1.22.2
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.
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.
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 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?
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?
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.
Thanks for the response; in our setup we are not explicitly specifying static linkage and still we are getting the warnings:
platform :ios, '14.0' inhibit_all_warnings! use_frameworks! ... pod 'Firebase/AnalyticsWithoutAdIdSupport', '~ > 10.16' pod 'Firebase/Crashlytics', '~ > 10.16' ...
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.
platform :ios, '14.0' inhibit_all_warnings! use_frameworks! ... pod 'Firebase/AnalyticsWithoutAdIdSupport', '~ > 10.16' pod 'Firebase/Crashlytics', '~ > 10.16'
For me updating Firebase alone (pod update Firebase) upgrades to version 10.23.1, when submitting is still flagging the original 3 privacy issues:
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.
Based on above comment - and after checking the following in my codebase:
// Due to Apple Privacy Manifests, Crashlytics is not collecting // disk space using statfs. When we find a solution, we can update // this to actually track disk space correctly.
if NSPrivacyAccessedAPICategoryDiskSpace is flagged, is no longer related to Firebase?
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.
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.
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 ✅
I'm at Firebase 10.23.0, using manual integration - I downloaded the framework SDK zip and linked them all in myself, following the directions in the readme. I am still getting warnings from App Store Connect about using NSPrivacyAccessedAPICategorySystemBootTime when I submit app updates.
I grep'd my whole git checkout folder for systemUptime and mach_absolute_time, and the only matches were for the latter in the Crashlytics framework. I'm quite confident that my code isn't using either of those symbols anywhere - it's only in Crashlytics. I can see the privacy manifest in the Crashlytics framework that declares this usage, but for some reason App Store Connect's scanner isn't picking them up.
Interestingly, when I use this tool to scan my built app binary for offending symbols, it says my app's binary references mach_absolute_time, and it also finds that symbol in the Crashlytics framework:
Used symbols in binary ./BRFree.app/BRFree: fstat, fstatfs, lstat, mach_absolute_time, NSFileModificationDate, NSFileSystemFreeSize, NSFileSystemSize, NSURLCreationDateKey, NSUserDefaults, stat, statfs
Used symbols in binary ./FirebaseCrashlytics.framework/FirebaseCrashlytics: fstat, mach_absolute_time, NSUserDefaults, stat
Used symbols in binary ./openssl.framework/openssl: fstat, stat
Used symbols in binary ./FirebaseCoreInternal.framework/FirebaseCoreInternal: NSUserDefaults
Used symbols in binary ./FirebaseCore.framework/FirebaseCore: NSUserDefaults
Used symbols in binary ./FirebaseSessions.framework/FirebaseSessions: NSUserDefaults
Used symbols in binary ./GoogleUtilities.framework/GoogleUtilities: NSURLCreationDateKey
Used symbols in binary ./libotCore.iOS.a: NSFileModificationDate, stat
Used symbols in binary ./libot_sqlite.a: fstat, fstatfs, lstat, stat, statfs
Is it possible the result in my binary is because Crashlytics is being embedded?
Hi @tomhamming, we are awaiting resolution on the scanner's behavior (filed feedback with Apple - FB13691093). Until then, Firebase 10.24.0 will be released next week and will remove some R.R. API usage to reduce the surface area of this issue.
Is it possible the result in my binary is because Crashlytics is being embedded?
Yes. What Xcode are you using?
Xcode 15.3 (15E204a)
When manually integrating them, did you select embed & sign or embed without signing?
Thanks, @tomhamming. It's unexpected to me as to why the R.R. scanner would find R.R. symbols in your main app and the Crashlytics framework. The FirebaseCrashlytics.xcframework contains static frameworks, so the SDK's symbols should be linked into your main app. But, on Xcode 15.3 with embed & sign enabled, Xcode should be swapping out Crashlytic's static archive when embedding it in the Frameworks/ directory of your app so as to not needlessly bloat the app binary as the SDK's symbols should already be in the main app. The static archive should be swapped with an empty dylib (verifiable by running file /path/to/yourapp.app/Frameworks/FirebaseCrashlytics/FirebaseCrashlytics), so I wouldn't expect the scanner to pick up symbols within FirebaseCrashlytics.framework/FirebaseCrashlytics.
% 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.
Hmm, try running again and removing the trailing /:
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: Mach-O 64-bit dynamically linked shared library arm64