SDWebImage / SDWebImageSwiftUI

SwiftUI Image loading and Animation framework powered by SDWebImage
https://sdwebimage.github.io/SDWebImageSwiftUI
MIT License
2.18k stars 224 forks source link

[URGENT] Update SDWebImage dependency for Apple Privacy #310

Closed JoeSzymanskiFAN closed 5 months ago

JoeSzymanskiFAN commented 6 months ago

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.

dreampiggy commented 6 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
dreampiggy commented 6 months ago

I don't think SDWebImageSwifUI Can not use the latest version of SDWebImage

arbyruns commented 6 months ago

@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.

dreampiggy commented 6 months ago

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"

ginnheimerCoder commented 5 months ago

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.

dreampiggy commented 5 months ago

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

ginnheimerCoder commented 5 months ago

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.

dreampiggy commented 5 months ago

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

ginnheimerCoder commented 5 months ago
Bildschirmfoto 2024-04-23 um 08 41 22

Yes, the privacy manifest file is there, however the reasons for NSPrivacyAccessedAPICategoryFileTimestamp don't show up in the privacy report (i just generated one).

dreampiggy commented 5 months ago

I means, the final package (.ipa)

That SDWebImage's PrivacyInfo must exists in the final package, like this path: image

I checked again, seems the syntax is correct as Apple's forum suggestion ?

https://github.com/SDWebImage/SDWebImage/blob/master/Package.swift#L35

https://forums.developer.apple.com/forums/thread/742527

ginnheimerCoder commented 5 months ago

well, it doesn't. That's the point. The report only lists our own declared reasons and not the ones SDWebImage uses.

dreampiggy commented 5 months ago

Why? Any different between this syntax

dreampiggy commented 5 months ago

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)

ginnheimerCoder commented 5 months ago

We don't have CocoaPods nor Carthage in our project, so I am not able to test this easily.

JoeSzymanskiFAN commented 5 months ago

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.

arbyruns commented 5 months ago

Can you provide what that looks like because I'm still getting warned on this privacy issue using SPM.

JoeSzymanskiFAN commented 5 months ago

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.

arbyruns commented 5 months ago

Here's what I have image

JoeSzymanskiFAN commented 5 months ago

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.

arbyruns commented 5 months ago

Thanks! I've added mine as well, maybe you have some pointers?

image

JoeSzymanskiFAN commented 5 months ago

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.

ginnheimerCoder commented 5 months ago

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.

dreampiggy commented 5 months ago

When using our repo's own Demo (open SDWebImageSwiftUI.xcworkspace), it use SPM to integrate the SDWebImage depedency

image

click archive, I can see the xcarchive, and the App bundle actually contains the PrivacyInfo.xcprivacy, under a bundle named SDWebImage_SDWebImage.bundle

image

@ginnheimerCoder Does your final app or ipa not contains this file ?

ginnheimerCoder commented 5 months ago

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.

ginnheimerCoder commented 5 months ago

I re-added SDWebImageSwiftUI (removed it from Package Dependency and re-added it) and now using the tree command, the SDWebImage_SDWebImage.bundlebranch 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.

dreampiggy commented 5 months ago

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 image

ginnheimerCoder commented 5 months ago

On the Apple forum, nobody mentions the use of SPM. I think this is an SPM issue.

dreampiggy commented 5 months ago

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)

ginnheimerCoder commented 5 months ago

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?

ginnheimerCoder commented 5 months ago

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.

dreampiggy commented 5 months ago

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

dreampiggy commented 5 months ago

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.