Closed JoeSzymanskiFAN closed 5 months ago
SDWebImageSwiftUI has no way to use the new version, so it's not currently possible to get the required version
Why ? See our demo's Podfile.lock
PODS:
- libavif/core (0.11.1)
- libavif/libdav1d (0.11.1):
- libavif/core
- libdav1d (>= 0.6.0)
- libdav1d (1.2.0)
- libwebp (1.3.2):
- libwebp/demux (= 1.3.2)
- libwebp/mux (= 1.3.2)
- libwebp/sharpyuv (= 1.3.2)
- libwebp/webp (= 1.3.2)
- libwebp/demux (1.3.2):
- libwebp/webp
- libwebp/mux (1.3.2):
- libwebp/demux
- libwebp/sharpyuv (1.3.2)
- libwebp/webp (1.3.2):
- libwebp/sharpyuv
- SDWebImage (5.19.0):
- SDWebImage/Core (= 5.19.0)
- SDWebImage/Core (5.19.0)
- SDWebImageAVIFCoder (0.11.0):
- libavif/core (>= 0.11.0)
- SDWebImage (~> 5.10)
- SDWebImagePDFCoder (1.0.1):
- SDWebImage (>= 5.14.1)
- SDWebImageSVGCoder (1.7.0):
- SDWebImage/Core (~> 5.6)
- SDWebImageSwiftUI (3.0.1):
- SDWebImage (~> 5.10)
- SDWebImageWebPCoder (0.14.5):
- libwebp (~> 1.0)
- SDWebImage/Core (~> 5.17)
DEPENDENCIES:
- libavif/libdav1d
- SDWebImageAVIFCoder
- SDWebImagePDFCoder
- SDWebImageSVGCoder
- SDWebImageSwiftUI (from `./`)
- SDWebImageWebPCoder
SPEC REPOS:
trunk:
- libavif
- libdav1d
- libwebp
- SDWebImage
- SDWebImageAVIFCoder
- SDWebImagePDFCoder
- SDWebImageSVGCoder
- SDWebImageWebPCoder
EXTERNAL SOURCES:
SDWebImageSwiftUI:
:path: "./"
SPEC CHECKSUMS:
libavif: 84bbb62fb232c3018d6f1bab79beea87e35de7b7
libdav1d: 23581a4d8ec811ff171ed5e2e05cd27bad64c39f
libwebp: 1786c9f4ff8a279e4dac1e8f385004d5fc253009
SDWebImage: 981fd7e860af070920f249fd092420006014c3eb
SDWebImageAVIFCoder: 00310d246aab3232ce77f1d8f0076f8c4b021d90
SDWebImagePDFCoder: ec8d162f5a4a34760bf1ea3d7f818dd85dc82e81
SDWebImageSVGCoder: 15a300a97ec1c8ac958f009c02220ac0402e936c
SDWebImageSwiftUI: 5acb843d4fb27841adac772aecc0516e9ee90356
SDWebImageWebPCoder: c94f09adbca681822edad9e532ac752db713eabf
PODFILE CHECKSUM: a1b2837f429f61673bea58532abe00e850c10aeb
COCOAPODS: 1.15.2
I don't think SDWebImageSwifUI Can not use the latest version of SDWebImage
@dreampiggy I don't understand your last comment?
I'm getting the following when I upload now. Not sure if it is because of SDWEBImage, but I've added the PrivacyInfo for my app.
ITMS-91053: Missing API declaration - Your app’s code in the “UntitledBarracks” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryFileTimestamp. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.
ITMS-91053: Missing API declaration - Your app’s code in the “UntitledBarracks” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryUserDefaults. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.
However, SDWebImageSwiftUI has no way to use the new version, so it's not currently possible to get the required version.
Is your project issue. Maybe your min deployment version is wrong.
The demo shows that "we can always get the new version"
We have a similar problem. We only use SDWebImageSwiftUI and Apple is complaining about the missing API declaration. Apple complains about NSPrivacyAccessedAPICategoryFileTimestamp
. We only found references in SDWebImage, and SDWebImage provides the privacy manifest file, but Apple is not recognizing it. We use SDWebImageSwiftUI 2.2.4 which uses SDWebImage 5.19.1.
What linkage did you use ?
For dynamic linkage, each framework use its own symbol. SDWebImageSwiftUI
does not use any FileSystem API, so it shouldn't
For static linkage, each framework share the same symbol. So maybe you need to declare NSPrivacyAccessedAPICategoryFileTimestamp
at App level
We use swift package manager. I don't know wether spm packages are statically or dynamically linked.
SDWebImageSwiftUI has no references to NSPrivacyAccessedAPICategoryFileTimestamp
but SDWebImage does and SDWebImageSwiftUI depends on it.
Is that final package actually contains the Privacy Manifest
? You can use Xcode's archive organizer to get the privacy report to see the reason.
Maybe the issue is that SDWebImage does not get recognized contains a valid manifest
Yes, the privacy manifest file is there, however the reasons for NSPrivacyAccessedAPICategoryFileTimestamp
don't show up in the privacy report (i just generated one).
I means, the final package (.ipa)
That SDWebImage's PrivacyInfo
must exists in the final package, like this path:
I checked again, seems the syntax is correct as Apple's forum suggestion ?
https://github.com/SDWebImage/SDWebImage/blob/master/Package.swift#L35
well, it doesn't. That's the point. The report only lists our own declared reasons and not the ones SDWebImage uses.
Why? Any different between this syntax
I guess this is SwiftPM only problem, marked as label here. And you can firstly test using CocoaPods or manural archive (using Carthage build for exmaple)
We don't have CocoaPods nor Carthage in our project, so I am not able to test this easily.
I believe that we were able to use the correct version of SDWebmage without any changes to this component by setting the explicit SDWebImage dependency to the necessary version in the SPM settings. With that additional dependency definition in place, we do not see the privacy warnings when uploading builds to Apple.
Can you provide what that looks like because I'm still getting warned on this privacy issue using SPM.
We are using xcodegen, so I'm not 100% sure of how this would look with a standard SPM integration, but we have the following dependencies defined:
SDWebImage:
# This is a dependency of SDWebImageSwiftUI and SDWebImageSVGCoder, but needs to be
# explicitly set to v5.19.1 for xcprivacy support. Once those SDKs are updated, we
# can remove this explicit version tracking.
url: https://github.com/SDWebImage/SDWebImage
version: 5.19.1
SDWebImageSwiftUI:
url: https://github.com/SDWebImage/SDWebImageSwiftUI
version: 2.2.3
This setup makes use of the correct version of SDWebImageSwiftUI, while bumping SDWebImage itself up to the latest version.
Here's what I have
I'm not sure if there was additional work. We had to have our own privacy manifest set up, so it's possible we resolved our warnings by adding that.
Thanks! I've added mine as well, maybe you have some pointers?
That looks to be about what I would expect. I'm not sure what else would be missing outside of for some reason the file not being included I the final build. Sorry I can't help much more here.
Adding SDWebImage 5.19.1 via SPM as an explicit dependency to the project does not resolve the issue. I am still getting the privacy issue. And SDWebImageSwiftUI already adds SDWebImage 5.19.1, so explicitly adding SDWebImage should not make a difference.
I don't know what to do other than manually copying the reasons that SDWebImage declares and put them into our own privacy manifest file.
When using our repo's own Demo (open SDWebImageSwiftUI.xcworkspace
), it use SPM to integrate the SDWebImage
depedency
click archive, I can see the xcarchive, and the App bundle actually contains the PrivacyInfo.xcprivacy
, under a bundle named SDWebImage_SDWebImage.bundle
@ginnheimerCoder Does your final app or ipa not contains this file ?
Using the same tree command, it only shows our own PrivacyInfo file under the root directory of the app. There is no SDWebImage_SDWebImage.bundle
branch and no PrivacyInfo file in it.
I re-added SDWebImageSwiftUI (removed it from Package Dependency and re-added it) and now using the tree command, the SDWebImage_SDWebImage.bundle
branch is showing up and has the PrivacyInfo file in it – however, Apple is still complaining and SDWebImage with the declared reason is not showing up in the privacy report.
however, Apple is still complaining and SDWebImage with the declared reason is not showing up in the privacy report.
So, what's actually needed ? The privacy info already bundled in your App. I even saw in the Apple forum, seems some devs use SDWebImage as the correct way.
See: https://forums.developer.apple.com/forums/thread/734971
On the Apple forum, nobody mentions the use of SPM. I think this is an SPM issue.
On the Apple forum, nobody mentions the use of SPM. I think this is an SPM issue.
There are no different if you use Static Library
in CocoaPods.
I guess when you use .framework
bundle, you will not have any issue. Does the Apple ITC tools only scan for .framework
(Static framwork or dynamic framework)
what exactly do you mean when you say "use .framework bundle"? I just included the package via Swift Package Manager. Nothing more. What do I need to change?
So it seems like the issue has been resolved on the apple side. Today I received a response from the TSI i opened. Apple simply said “There has been a change in the policies. You should be able to upload a binary that contains a static framework.” They linked to the reminder Apple released on Friday.
I uploaded a new build (with no changes to the privacy issue) and up until now I haven’t received the privacy issue e-mail.
SPM does not use Static framework
to distribute your code.
It use Static ar archive
, means, SDWebImage.a
+ SDWebImage_bundle.bundle
If you still face the issue, maybe using other package manager, or tweak SPM to use binary framework dependency of SDWebImage is the only way.
See more: https://github.com/firebase/firebase-ios-sdk/blob/main/docs/firebase_in_libraries.md#introduction https://bpoplauschi.github.io/2021/10/25/Advanced-static-vs-dynamic-libraries-and-frameworks.html
If Apple's tool is stupid on SPM static linking and their dependency
. Maybe the stupid solution we (as developer) is to declare a empty privacy info as well.
There is a deadline coming up where Apple requires all usage of SDWebImage to include xcprivacy files. That was added in the 5.18.7 release: https://github.com/SDWebImage/SDWebImage/releases/tag/5.18.7
However, SDWebImageSwiftUI has no way to use the new version, so it's not currently possible to get the required version.
Apple will stop accepting uploads without this file starting on May 1, 2024, so this update needs to be made very soon to allow time to integrate and test the dependency update.