Alamofire: Xcode12 GM 'SessionDelegate' has different definitions in different modules

Created on 16 Sep 2020  路  9Comments  路  Source: Alamofire/Alamofire

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

QQ20200916-152325@2x

support

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.

All 9 comments

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.

Was this page helpful?
0 / 5 - 0 ratings