Po

This should fix #1530

Check List

Thanks for considering to open an issue. Before you submit your issue, please confirm these boxes are checked.

• [x] I have read the wiki page and cheat sheet, but there is no information I need.
• [x] I have searched in existing issues, but did not find a same one.
• [x] I want to report a problem instead of asking a question. It'd better to use kingfisher tag in Stack Overflow to ask a question.

Issue Description

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

Xcode 12: Add Pods of Alamofire and Kingfisher Build Project

This should fix #1530

I don't have this issue when trying in a sample project installing both the latest versions of Kingfisher (5.15.3) and Alamofire (5.2.2). It might be either a version issue or a local project setting problem. And it is not strange that CocoaPods is generating the ObjC compatible header by default, so it is still triggering #1517.

@christophercotton That fix is nice and I will also add it to this repo so we can solve it in any dependency manager.

Check List

Thanks for considering to open an issue. Before you submit your issue, please confirm these boxes are checked.

• [x] I have read the wiki page and cheat sheet, but there is no information I need.
• [x] I have searched in existing issues, but did not find a same one.
• [x] I want to report a problem instead of asking a question. It'd better to use kingfisher tag in Stack Overflow to ask a question.

Issue Description

Xcode 12 reports are warning: Variable 'retrievingContext' was never mutated; consider changing to 'let' constant

What

Warning should not appear

Reproduce

compile

Other Comment

This should be already fixed long ago in https://github.com/onevcat/Kingfisher/pull/1492/files#diff-3e519cd03a013ef2802179ab0d255ae2R209

Hi,

Installing LINE SDK for Unity requires some environment set up to help the project automatically get the latest version of LINE SDK from GitHub. Please be sure to follow up on the installation guide here and here to set the project.

If everything is set, do you have any error when exporting your Unity project? It will help us to track down what exactly happens.

And if you are integrating by CocoaPods (which is the default choice), please remember to open the Unity-iPhone.xcworkspace instead of the original Unity-iPhone.xcodeproj file to build your project. CocoaPods manages the dependencies in the standalone workspace so you will not be able to find the framework in the original project.

Any further information is welcome!

Hi,

It seems that you are passing a nil to the parameters in the login method. https://github.com/hw20101101/H200914_Test_Protocol/blob/master/H200914_Test_Protocol/ViewController.m#L38

You should not do that since this parameters only accept a non-null value:

Try to remove the parameters:nil from your code, or set a LineSDKLoginManagerParameters value to it if you need any additional parameters. That should solve it.

App Tracking Transparency Framework Information.

As part of the iOS 14 /AppTracking Transparency framework, would like to know if any kind of the user data is collected or Tracked by the Kingfisher.

[As mentioned in the Apple (Ref: https://developer.apple.com/support/app-privacy-on-the-app-store/), below were some of the examples for Tracking:

• Sharing device location data or email lists with a data broker.
• Placing a third-party SDK in our app that combines user data from the app with user data from other developers’ apps to target advertising or measure advertising efficiency, even if we don’t use the SDK for these purposes. For example, using a login SDK that repurposes the data it collects from the app to enable targeted advertising in other developers’ apps.

The following situations are not considered tracking:

• When the data is linked solely on the end-user’s device and is not sent off the device in a way that can identify the end-user or device.
• When the data broker uses the data shared with them solely for fraud detection or prevention or security purposes, and solely on our behalf.]

<!-- Love Kingfisher? Please consider supporting our collective: 👉 https://opencollective.com/Kingfisher/donate -->

No.

Check List

• [x] I have read the wiki page and cheat sheet, but there is no information I need.
• [x] I have searched in existing issues, but did not find a same one.
• [x] I want to report a problem instead of asking a question. It'd better to use kingfisher tag in Stack Overflow to ask a question.

Issue Description

What

There seems to be a naming conflict inside the objc header file with the SessionDelegate class when using both Kingfisher and Alamofire in Xcode 12 GM. (You can see the issue on Alamofire side here, more discussion here)

/Users/sachajln/ios-workspace/MyProject/Carthage/Build/iOS/Kingfisher.framework/Headers/Kingfisher-Swift.h:836:1: error: 'SessionDelegate' has different definitions in different modules; first difference is definition in module 'Kingfisher.Swift' found method with designater initializer
- (nonnull instancetype)init OBJC_DESIGNATED_INITIALIZER;
^
/Users/sachajln/ios-workspace/MyProject/Carthage/Build/iOS/Alamofire.framework/Headers/Alamofire-Swift.h:772:1: note: but in 'Alamofire.Swift' found method with no designater initializer
- (nonnull instancetype)init SWIFT_UNAVAILABLE;
^

Reproduce

Use Alamofire and Kingfisher frameworks inside a project and do a xcodebuild -project YOUR_PROJECT.xcodeproj -sdk iphoneos with Xcode 12 GM command line tools.

Comments

I'm using Carthage to build and copy the frameworks in my project

5.15.3 was released for this.

Thanks for it!

This should fix #1522

There is no need to give the KingfisherSwiftUI target a higher deployment target, although no one can use it on a lower platform. The related APIs are already marked with correct @available annotation, so there is no need to limit its lowest version anymore.

I'm working with the project: Main project working with the latest Kingfisher and development target = iOS 11. Clip / Widget extension working with the latest Kingfisher/SwiftUI and development target = iOS 14.

After pod installing, the Kingfisher and Kingfisher-Core-SwiftUI target is added into the Pods project, and their Product Name are both Kingfisher. So when I archive the app , the error occurs due to the same Product Name of them:

Multiple commands produce '/xxx/Kingfisher.framework':
1) Target 'Kingfisher' has create directory command with output '/xxx/Kingfisher.framework'
2) Target 'Kingfisher-Core-SwiftUI' has create directory command with output '/xxx/Kingfisher.framework'

I know that it's not the issue or bug with Kingfisher, but can u provide me some solution in this situation?

Thx

This was a long-ago intended change since version 5.8. But at that time, Carthage fails to create valid cache hash when no ObjC header generated.

https://github.com/onevcat/Kingfisher/issues/1307

Now Carthage has fixed that issue, and it seems that Carthage built frameworks on Xcode 12 is failing at merging the headers from different frameworks when they have conflicting type names (#1517 and https://github.com/Alamofire/Alamofire/issues/3303). So it seems that now it is another good chance to apply this.

It removes support of Objective-C so there would be no header conflicting anymore with another project. (Regardless of it being an Xcode issue or a Carthage issue.)

It is a quite annoying change in Swift 5.3, basically only for writing better SwiftUI code. For any other use cases, it is a bit of regression to apply the new trailing closure rule.

For you case, if you have both the progress block and completion block, try to explicitly name the first block to avoid the ambiguous meaning:

imageView.kf.setImage(
    with: LocalFileImageDataProvider(fileURL: URL(string: "")!),
    progressBlock: { (_, _) in

    }
) { _ in

}

Or even write out them all:

imageView.kf.setImage(
    with: LocalFileImageDataProvider(fileURL: URL(string: "")!),
    progressBlock: { (_, _) in

    },
    completionHandler: { _ in

    }
)

The factory pattern is very nice in Alamofire and it definitely a good direction to improve the API. But it requires a major upgrade and I will consider if it is easy enough to migrate. I will try to see it I can implement it soon. Thank you for your suggestion.

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

1. Target 'Kingfisher.default-SwiftU'

And the target name in your log is suspicious, if you are not pasting it wrongly.

platform :ios, '11.0'

target 'SampleProject' do
  use_frameworks!
  pod 'Kingfisher/SwiftUI', :git => 'https://github.com/onevcat/Kingfisher.git', :branch => 'fix/swift-ui-deploy-target'
end

target 'SampleWidgetExtension' do
  use_frameworks!
  pod 'Kingfisher/SwiftUI', :git => 'https://github.com/onevcat/Kingfisher.git', :branch => 'fix/swift-ui-deploy-target'
end

Here is the Podfile I am trying and it works fine. CocoaPods recognized both as a single target in the pod framework.

Maybe check your project setting or Podfile to see if there is another setting causes this issue.

This should fix #1522

There is no need to give the KingfisherSwiftUI target a higher deployment target, although no one can use it on a lower platform. The related APIs are already marked with correct @available annotation, so there is no need to limit its lowest version anymore.

@SpiciedCrab

I got your idea. I pushed some change to the fix/swift-ui-deploy-target branch to make the deploy target requirement of SwiftUI subspec matching to the main target. Can you try it to see if it works for you? You can change both of the dependency declarations in your Podfile to something like this, before we can tag and release it as a new version:

pod 'Kingfisher/SwiftUI', :git => 'https://github.com/onevcat/Kingfisher.git', :branch => 'fix/swift-ui-deploy-target'

@sachajln @timbms @Senocico @alperkayabasi

Can you confirm whether this branch "fix/no-objc" can solve your issue? If everything goes fine, I will merge it and tag a new version soon.

Thanks!

Kingfisher's SwiftUI support is a part of (or say an additional slice) the core framework.

So if you are using use_frameworks! and linking Kingfisher dynamically (which should be the recommended way when you developing a multiple targets app containing widget or other extensions), you can just add KingfisherSwiftUI to pod file and link it to multiple targets. So only one full-featured of the framework will be added to your project.

fix for this issue: https://github.com/onevcat/Kingfisher/issues/1517

@bogdanmatasaru Thank you for this PR. Your fix works perfectly!

But I guess I can fix it in #1523, with a long-ago intended change to make the framework better.

This was a long-ago intended change since version 5.8. But at that time, Carthage fails to create valid cache hash when no ObjC header generated.

https://github.com/onevcat/Kingfisher/issues/1307

Now Carthage has fixed that issue, and it seems that Carthage built frameworks on Xcode 12 is failing at merging the headers from different frameworks when they have conflicting type names (#1517 and https://github.com/Alamofire/Alamofire/issues/3303). So it seems that now it is another good chance to apply this.

It removes support of Objective-C so there would be no header conflicting anymore with another project. (Regardless of it being an Xcode issue or a Carthage issue.)

I personally cannot reproduce this issue in my environment. Can anyone help provide some reproducible steps? Or can you prepare a simple sample in which this can happen?

Some more information would be also helpful for tracking it quicker:

• Are you using an ARM Mac? Or a traditional Intel mac? The official released Xcode 12.0 does not support ARM Mac yet, you need to keep to use beta 6.
• By which way you are installing Kingfisher? Pods, Carthage or SPM?
• Does this error happens when you click the Run button in Xcode? Or does it happen when you build with command line?

Thanks for any information.

@vulgur Cannot reproduce it when building with Kingfisher installed by SPM.

Are you trying to work on an ARM Mac (the Developer Transition Kit)?

KFImage uses the same ImageCache under-hood, so it follows everything (maybe you are already familiar) as Kingfisher does. You do not need to do anything to enable cache and it just works by default. If you want to tweak it, follow the cache related section in the Cheat Sheet in Wiki.

Fixed and released as 5.15.2 for this issue.

Hi Guys,

I have this error to build KingfisherSwiftUI 5.15.1 with XCode 11.7.+ Can you check it?

J

Fixed and released as 5.15.2 for this 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, it 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.

I'll check what I can do for it.

Issue Description

What

When trying to view a live preview of a SwiftUI file, Xcode failed to build the scheme and reports the error in the title

Reproduce

Open a SwiftUI file and attempt to view a live preview

Other Comment

Version 5.15.1

It should be fixed by #1515 and I will tag a new release for it soon.

Any ideas what the issue may be here? 'collectors' is my project target and name.

Not sure what you are using to install Kingfisher. But if you are using the xcframework, I heard that there is a bug in Xcode 12 GM that it is picking the wrong slice so you may have this issue. Reverting back to use Xcode 12 beta 6 or choose another way to install the framework might solve it.

(But I didn't verify it myself.)

Oh. I guess it is exactly what I have done?

No idea what can cause it. It is not likely to be what we can solve in Kingfisher, since Xcode should being respecting your project settings when build a project and Kingfisher can just follow the instruction of the build system.

By the way, may I know how did you add Kingfisher to your project? Can it be a problem of the dependency manager like Carthage or so?

Due to a previous bug of Xcode, Kingfisher defined multiple libraries, including automatic (static) and explicit dynamic ones. Currently that bug was already fixed and there should be no need to separate them. But I choose to keep these targets for a while for back compatibility. If there is no good reason, please ensure you just link the standard one “Kingfisher” to your target, and remove any other ones (“KingfisherDynamic” for example) from your link library phase.

@lehelmedves I created a fix in this branch https://github.com/onevcat/Kingfisher/tree/fix/swiftui-build-xcode11

However, I am on my vacation now and do not have a Mac at hand to verify it. Please try if that works and if everything goes fine I will tag it in a few days when I return.

Hello

yes I know iOS 14 is still in beta but maybe it helps you ;-)

I use kingfisher in a SwiftUI List to load pictures from urls. The initial state is shown as expected, but when I start scrolling the app crashs with a Bad Access- Error.

If I delete the KFImage everything working well.

If I use the same url for every cell it also works fine.

Maybe there is some problem when SwiftUI tries to reuse the Cell and can't load the image somehow.

Does anybody has an idea what to do ?

5.15.1 was released for this.

This is a workaround for #1508. But a real fix is still being waited from Apple.

This adds support for the resource bundle of the UI part of LINE SDK. It requires swift-tools-version:5.3 bundled in Xcode 12 and also keep compatibility for integrating of CocoaPods and Carthage.

We can merge it once Xcode 12 gets finally released so users can build LINE SDK with SPM.

@hassfers @RosayGaspard

I tried some fix (#1510) inside Kingfisher and hopefully, it can solve this issue. Can you try to switch to the master branch temporarily to check if it works? If everything goes fine, I will give it a tag then.