Kingfisher: pure-Swift image downloading and caching, with a CocoaPods deadline and a moving platform floor

One call downloads, caches in two layers and displays

The smallest use is a single line on an image view:

import Kingfisher

let url = URL(string: "https://example.com/image.png")
imageView.kf.setImage(with: url)

Kingfisher downloads the image from the URL, sends it to both the memory cache and the disk cache, and shows it in the image view. When you set the same URL later, the image comes from the cache and appears immediately. The cache is described as a multiple-layer hybrid of memory and disk, with a customizable expiration date and size limit. The consequence is that you do not write cache plumbing yourself, but you also do not get an automatic answer to how large your cache may grow, because the size limit and expiration are settings you choose.

The same library reaches SwiftUI through KFImage

For SwiftUI the equivalent is a view that takes the URL directly:

var body: some View {
    KFImage(URL(string: "https://example.com/image.png")!)
}

The builder style makes the move between frameworks mechanical. Instead of the `kf` extension you can use the `KF` builder with chained calls such as placeholder, setProcessor, loadDiskFileSynchronously, cacheMemoryOnly and fade. If you later switch a screen to SwiftUI, you change `KF` to `KFImage` and keep the chain: the same placeholder, processor, loadDiskFileSynchronously, cacheMemoryOnly and fade calls apply, along with lowDataModeSource, onProgress, onSuccess and onFailure. Your processors and cache settings carry over, so the rewrite is mostly in the view layer rather than the image pipeline.

Processors are composed with a pipe operator and run before caching

Image processing is a first-class part of the API. The README example chains a downsampling processor and a rounding processor with the `|>` operator: DownsamplingImageProcessor takes the size of the image view, and RoundCornerImageProcessor takes a corner radius of 20. Options passed to setImage then select that processor, a scale factor, a fade transition and cacheOriginalImage.

The cacheOriginalImage option is the one with a visible side effect: the original large image is also cached to disk for later use, so a detail view does not download it again. You pay for that with disk space for both the processed thumbnail and the original. Other pieces on offer include image filters, a built-in transition animation, a customizable placeholder and indicator, and support for extending image processing and image formats.

Components are independent, so you can take only the downloader or only the cache

The feature list states that the downloader, the caching system and the image processors can be used separately as you need. That matters if your app already has a networking layer: images can be loaded from URLSession-based networking or from data you already hold locally, so you are not forced through Kingfisher's own request path.

The feature list also names prefetching images and showing them from the cache, cancelable downloading with automatic reuse of previously downloaded content, and Low Data Mode support. Extensions cover UIImageView, NSImageView, NSButton, UIButton, NSTextAttachment, WKInterfaceImage, TVMonogramView and CPListItem, and Live Photo loading and caching is listed too. If you need to set an image on a view type outside that list, you work with the lower-level components yourself.

Async cache probing is opt-in, so the default cache check can block the caller

One feature line reads: opt-in async cache probing in KingfisherManager, to avoid blocking the caller thread on disk cache checks. The word opt-in is the catch. If you do nothing, the disk cache check is not the asynchronous version, so a call made from a thread you care about may wait on the disk.

The README also lists the loadDiskFileSynchronously option in its examples, which shows that synchronous disk loading is a deliberate choice you can make per request. Teams with strict main-thread budgets should read how these two options interact before assuming that every cache lookup is free of disk work.

The platform and toolchain floor changes with the release line

The requirements are split three ways. The current development branch needs iOS 15.0+, macOS 12.0+, tvOS 15.0+, watchOS 9.0+ and visionOS 1.0+, with Xcode 26.0+ and a Swift 6.2+ compiler. Kingfisher 8.0 supports UIKit and AppKit from iOS 13.0+, macOS 10.15+, tvOS 13.0+ and watchOS 6.0+, and SwiftUI from iOS 14.0+, macOS 11.0+, tvOS 14.0+ and watchOS 7.0+, with Swift 5.9+. Kingfisher 7.0 goes back to iOS 12.0+ and Swift 5.0+.

Two consequences follow. An app that still targets iOS 13 can use the UIKit extensions on 8.0 but cannot use the SwiftUI view there. And anyone tracking the development branch must be on Xcode 26, so building from master is a toolchain upgrade in itself. Every platform in the requirements is an Apple platform, so an Android or web target is outside what the library lists.

CocoaPods stops receiving Kingfisher updates after 2 December 2026

A notice in the README says CocoaPods trunk becomes read-only on December 2, 2026. After that date, new Kingfisher versions cannot be published to CocoaPods. Versions already published keep resolving, but you will not get updates or security fixes through CocoaPods, and the README advises migrating to Swift Package Manager or the pre-built framework.

The Podfile it shows is:

source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '15.0'
use_frameworks!

target 'MyApp' do
  pod 'Kingfisher', '~> 8.0'
end

For Swift Package Manager, add the package dependency https://github.com/onevcat/Kingfisher.git in Xcode and select Up to Next Major with 8.0.0. The practical cost is on projects that rely on CocoaPods for the whole dependency tree: they will need a second install route for this one library, or a move off CocoaPods.

Releases are frequent, and each carries a name

The newest release is 8.15.0, named Control Freak, published on 3 November 2026. Before it came 8.14.0, Leaf Me Alone, on 17 October 2026, and 8.13.0, Mirror Mirror, on 23 September 2026. The last push to the repository was on 2 November 2026, and it is not archived.

The repository root includes CHANGELOG.md, a Demo project, a fastlane folder, a Kingfisher.podspec and a Package.swift. Three minor releases in about six weeks mean you should read the changelog before bumping, because pinning to Up to Next Major accepts all of them automatically.

Editorial conclusion

Choose Kingfisher if you build an iOS, macOS, tvOS, watchOS or visionOS app in Swift and want one library for downloading, processing and caching remote images in both UIKit and SwiftUI. Do not pick it for a non-Apple target, and do not pick CocoaPods as your install route for a project that expects updates after 2 December 2026. Before adopting, check your deployment target against the 8.0 or development-branch requirements.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. onevcat/Kingfisher on GitHub
4. README
5. Releases