'SessionDelegate' has different definitions in different modules; first difference is definition in module 'Alamofire.Swift' found method

It happens when you have Kingfisher (for example) as well in your project. I am facing this issue myself now and not sure how to solve it.
Some discussion here:
https://stackoverflow.com/questions/63614048/xcode-12-sessiondelegate-has-different-definitions-in-different-modules
Also reported this issue to Apple. But it still in Open state (not fixed in the GM build)
@zdnk As a workaround, you need to fork one of the frameworks and rename the protocol (in our case we forked Kingfisher).
This is a bug in Kingfisher (they need to disambiguate their Obj-C SessionDelegate) so you should report it to them (it likely already has).
@jshier it used to work on earlier versions of Xcode12 and versions below
it's not Kingfisher's issue.
It's the issue of whatever Obj-C framework isn't prefixing their SessionDelegate type, not Alamofire. I suppose it could also be a compiler issue of some kind. Either way, not an Alamofire issue.
Hi,
I am the maintainer of Kingfisher.
Just like Alamofire, Kingfisher is also a Swift framework. Both Kingfisher and Alamofire are trying to generate an Objective-C header ("-Swift.h"). Before Xcode 12 beta 6, Xcode correctly handled them, and Kingfisher lives happily with any other frameworks, including Alamofire, for more than 5 years.
However, I am not sure if it is an intended change of the latest Xcode or not. Anyway, I will try to seek a way (maybe not defining a module for ObjC anymore), to avoid any future conflict like this.
@onevcat Sorry, didn't realize Kingfisher was a native Swift framework (used to be Obj-C, right?). I agree, this seems like a bug in Xcode, but removing the Obj-C module seems like a good idea anyway. I'll open an issue and see if I can ship an update.
@jshier
Never mind! :P
was a native Swift framework (used to be Obj-C, right?)
No, it was written in Swift from the first line of code. The ObjC header generating of Kingfisher was removed once, but soon added back due to a Carthage bug which requires to get Swift compiler version information from the "-Swift.h" header file. Carthage fixed that by falling back to dSYM file to get the Swift compiler version. However, they never released a new version until recently.
removing the Obj-C module seems like a good idea anyway. I'll open an issue and see if I can ship an update.
Yes. This issue might not only happens between Alamofire and Kingfisher. Any other frameworks which contains a same type name and generates ObjC headers would lead to this. Kingfisher has quite a few Swift-only APIs, and it is intended to be only used in Swift project, so removing the module support is a plan from long-ago. Not quite sure whether Alamofire supports ObjC or not. If no, I think it should be a good idea to skip ObjC things. It makes compile much faster and maybe some smaller binary file.
Yeah, I was thinking of SDWebImage. My PR is up (#3308) and I try to get it merged ASAP. I've been meaning to do a release anyway, so it should ship soon.
Most helpful comment
Hi,
I am the maintainer of Kingfisher.
Just like Alamofire, Kingfisher is also a Swift framework. Both Kingfisher and Alamofire are trying to generate an Objective-C header ("-Swift.h"). Before Xcode 12 beta 6, Xcode correctly handled them, and Kingfisher lives happily with any other frameworks, including Alamofire, for more than 5 years.
However, I am not sure if it is an intended change of the latest Xcode or not. Anyway, I will try to seek a way (maybe not defining a module for ObjC anymore), to avoid any future conflict like this.