Skip to content

Add Swift Package Manager support (Core + UI + WebP)#1

Open
damian-kolasinski wants to merge 5 commits into
masterfrom
spm-support
Open

Add Swift Package Manager support (Core + UI + WebP)#1
damian-kolasinski wants to merge 5 commits into
masterfrom
spm-support

Conversation

@damian-kolasinski

Copy link
Copy Markdown

Summary

Adds Swift Package Manager support so the library can be consumed via SPM instead of CocoaPods. The package exposes a single DFImageManager library product covering the Core, UI and WebP subspecs (the set the KingsChat app uses). AFNetworking, GIF and PhotosKit subspecs are excluded.

What changed

  • Package.swift — swift-tools-version 5.9, platform iOS 15, one target rooted at Pod/Source.
  • Pod/Source/include/DFImageManager/ — symlinks to all public headers (Core public + UI + WebP), so consumers keep using #import <DFImageManager/...> exactly as with the CocoaPods framework. Symlinks (the same pattern libwebp-Xcode uses) avoid duplicate-header drift and keep quoted intra-target imports working.
  • Pod/Source/include/module.modulemap — custom module map declaring umbrella "DFImageManager". Without it, SPM auto-picks DFImageManager.h as the sole umbrella header (name matches the module) and the rest of the API disappears from the module.
  • WebP — the libwebp/webp pod dependency is replaced with the maintained SPM wrapper SDWebImage/libwebp-Xcode pinned at exact 1.3.2 (same libwebp version as the pod). DFWebPImageDecoder.m now imports <webp/decode.h> (also resolves under CocoaPods).
  • DF_SUBSPEC_WEBP_ENABLED=1 is defined target-wide via cSettings, matching the merged prefix header CocoaPods generates when the WebP subspec is active — DFImageManager.sharedManager still registers DFWebPImageDecoder and sends the image/webp Accept header.

The podspec is untouched; CocoaPods consumption of this repo keeps working.

Consuming

There are no tags on this fork — pin by revision:

.package(url: "https://github.com/appunite/DFImageManager.git", revision: "7c024548b819dc59a4f15e5fc06d1353c63ea11b")

Product/target name: DFImageManager.

Validation

  • xcodebuild -scheme DFImageManager -destination "generic/platform=iOS Simulator" build — succeeds (only pre-existing OSSpinLock deprecation warnings).
  • A throwaway consumer package importing every <DFImageManager/...> header the KingsChat app uses (plus @import DFImageManager;, DFImageRequest, DFWebPImageDecoder, DFImageManager.sharedManager) builds clean for iOS Simulator from a wiped DerivedData.
  • The compiled object exposes the DFWebPImageDecoder symbols and the compile flags include DF_SUBSPEC_WEBP_ENABLED=1.

https://claude.ai/code/session_01LTj6vGgu7NmTs7bjupWAGh

damiankolasinski and others added 5 commits February 10, 2020 13:21
- Package.swift (swift-tools-version 5.9, iOS 15) exposing a single
  DFImageManager library product covering the Core, UI and WebP subspecs
- Pod/Source/include/DFImageManager/ contains symlinks to all public
  headers so consumers keep #import <DFImageManager/...> style imports;
  a custom module.modulemap declares the umbrella directory (SPM's
  auto-generated map would otherwise treat DFImageManager.h as the sole
  umbrella header)
- libwebp comes from the maintained SPM wrapper SDWebImage/libwebp-Xcode
  pinned at exact 1.3.2 (same version as the vendored pod), replacing
  the libwebp/webp pod dependency; DFWebPImageDecoder.m now imports
  <webp/decode.h> (also valid under CocoaPods)
- DF_SUBSPEC_WEBP_ENABLED=1 is defined target-wide, matching the merged
  prefix header CocoaPods generates when the WebP subspec is active, so
  DFImageManager.sharedManager still registers DFWebPImageDecoder and
  sends the image/webp Accept header

AFNetworking, GIF and PhotosKit subspecs are excluded from the SPM
target. The podspec is untouched; CocoaPods consumption keeps working.

Claude-Session: https://claude.ai/code/session_01LTj6vGgu7NmTs7bjupWAGh
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants