DreamPiggy

For CocoaPods, we can choose to use Subspec, or create one new Podspec for this. The difference is how user import. ```ruby # SDWebImage.podspec s.subspec `Core` do |ss| ss.sources_files =...

Seems Facebook team assume : `Objective-C user have to use CocoaPods, don't try to use SwiftPM`. See the https://github.com/facebook/facebook-ios-sdk/blob/master/Package.swift#L30-L46 Their SwiftPM only export the things `FacebookSDK`(like us's `SwiftWebImage` overlay framework),...

They mention this for Objective-C and Swift user, to use the different import: https://developers.facebook.com/docs/ios/getting-started 

> Like I said, Facebook deprecated their separate Swift framework, as it creates extra confusion (and other reasons). SDWebImage and SwiftWebImage are not separate framework. They are same one. Swift...

All this complicated issue is because of this limit: > Swift Package Manager each Target (A module, actually) can only contains single language, either C/C++, Objective-C, or Swift. You can...

Let's assume if we follows your suggestion to use CocoaPods's subspec: + CocoaPods CocoaPods use two subspecs, `Core` for pure Objective-C code with some `NS_SWIFT_NAME`, `Swift` for pure Swift overlay...

Another framework to reference about Swift API transition: [PSPDFKit](https://pspdfkit.com/) They used to have [true overlay framework](https://github.com/PSPDFKit/PSPDFKitSwift), but now merged into it's own mainstream codebase. Note: They support Carthage/CocoaPods, but not...

Maybe, we can just mixed coding with Objc and Swift into a single "Target". No actual "overlay". Put "Overlay" on logic, but not actual a target. The Swift and Objc...

Seems too long after the first proposal... My personal job and open-source work may related to some other compiler-based stack (not iOS UI level) 😓 But it's still really welcomed...

Did you try SDWebImge latest v5.13.2 version ?