Nuke 10


Nuke 10.7.1

Jan 27, 2022

Nuke 10.7.0

Jan 24, 2022

Nuke 10.6.1

Dec 27, 2021

Nuke 10.6.0

Dec 27, 2021

This release added async/await, but the change was reverted in 10.6.1 (for CocoaPods) and the release was deleted in GitHub.

Nuke 10.5.2

Dec 2, 2021

Nuke 10.5.1

Oct 23, 2021

Nuke 10.5.0

Oct 23, 2021

// Before
ImageRequest(url: url, processors: [ImageProcessors.Resize(width: 320)])

// After
ImageRequest(url: url, processors: [.resize(width: 320)])

Nuke 10.4.1

Aug 30, 2021

Nuke 10.4.0

Aug 28, 2021

Nuke 10.3.4

Aug 26, 2021

Nuke 10.3.3

Aug 18, 2021

Nuke 10.3.2

Jul 30, 2021

Nuke 10.3.1

Jul 8, 2021

Nuke 10.3.0

Jun 10, 2021

Nuke 10.2.0

Jun 6, 2021

See also Nuke 10.0 Release Notes)

Nuke 10.1.0

Jun 3, 2021

Nuke 10.0.1

Jun 1, 2021

Nuke 10.0

Jun 1, 2021

Nuke 10 is extreme in every way. It is faster than the previous version (up to 30% improvement to some operations), more powerful, more ergonomic, and is even easier to learn and use. It brings big additions to the caching infrastructure, great SwiftUI and Combine support, and more ways to adjust the system to fit your needs.

This release is also a massive step-up in the general quality of the framework. It has many improvements to the docs (for example, a complete rewrite of the caching guide), more inline comments, more unit tests (Nuke now has ~100% test coverage with 2x number of lines of code in the test target compared to the main target). It's as reliable as it gets.

Migration. The compiler will assist you with the migration, but if something isn't clear, there is a comprehensive migration guide available.

Switching. Switching from Kingfisher? There is now a dedicated guide available to assist you. There is also one for migrating from SDWebImage.


NukeUI (Beta)

NukeUI is a new Swift package. It is a comprehensive solution for displaying lazily loaded images on Apple platforms.

It uses Nuke for loading images and has all customization options you can possibly imagine. It also supports animated GIFs rendering thanks to Gifu and caching and displayng short videos as a more efficient alternative to GIF.

The library contains two types:

Both views have an equivalent sets of APIs.

struct ContainerView: View {
    var body: some View {
        LazyImage(source: "")
            .placeholder { Image("placeholder") }
            .transition(.fadeIn(duration: 0.33))


Nuke now has first-class SwiftUI support with FetchImage which is now part of the main repo, no need to install it separately. It also has a couple of new additions:


Nuke 10 goes all-in on Combine. ImagePublisher was initially introduced in the previous release, Nuke 9.6, and now Combine is supported across the framework.


Nuke 10 has a reworked ImageRequest.Options option set replacing removed ImageRequestOptions. The name is similar, but the options are slightly different. The new approach has more options while being optimized for performance. ImageRequest size in memory reduced from 176 bytes to just 48 bytes (3.7x smaller).



Nuke Builder

NukeBuilder is a package that adds a convenience API for creating image requests inspired by SwiftUI. It was updated with support Nuke 10 and some quality-of-life improvements.



There are deprecation warnings in place to help guide you through the migration process.

Nuke 9

Nuke 9.6.1

May 24, 2021

Nuke 9.6.0

May 2, 2021

Nuke 9.5.1

Apr 28, 2021

Nuke 9.5.0

Apr 3, 2021

Nuke 9.4.1

Mar 27, 2021

Nuke 9.4.0

Mar 26, 2021

Nuke 9.3.1

Mar 21, 2021

Nuke 9.3.0

Feb 22, 2021

Nuke 9.2.4

Jan 16, 2021

Nuke 9.2.3

Dec 30, 2020

Nuke 9.2.2

Dec 26, 2020

Nuke 9.2.1

Dec 15, 2020

Nuke 9.2.0

Nov 28, 2020



Nuke 9.1.3

Nov 17, 2020

Nuke 9.1.2

Aug 25, 2020

Nuke 9.1.1

June 19, 2020


Nuke 9.1

June 1, 2020


Nuke 9.0

May 20, 2020

Nuke 9 is the best release so far with refinements across the entire framework and some exciting new additions.

SwiftUI · Combine · Task builder API · New advanced set of core protocols for power-users · HEIF · Transcoding images in disk cache · Progressive decoding performance improvements · Improved resizing APIs · Automatic registering of decoders · SVG · And More

Most of the Nuke APIs are source compatible with Nuke 8. There is also a Nuke 9 Migration Guide to help with migration.


The primary focus of this release was to build on top the infrastructure introduced in Nuke 8 to deliver more advanced features while keeping the easy things easy. To achieve this, in Nuke 9, all core protocols, like ImageProcessing, ImageEncoding, ImageDecoding, now have a basic subset of methods that you must implement, and then there are new advanced methods which are optional and give you full control over the pipeline.

Along with Nuke 9, three new amazing Swift packages were introduced:

ImagePipeline.shared.image(with: URL(string: "https://")!)
    .resize(width: 320)
    .blur(radius: 10)
    .load { result in

I would also like to highlight a few other changes to improve documentation.

First, there is a completely new API Reference available generated using SwiftDoc, a new package for generating documentation for Swift projects.

There is a completely new README and two new guides:

There is also a new Troubleshooting Guide.

Another small but delightful change the demo project which can now be run by simply clicking on the project and running it, all thanks to Swift Package Manager magic.


General Improvements

Documentation Improvements

ImageProcessing improvements

There are now two levels of image processing APIs. For the basic processing needs, implement the following method:

func process(_ image: UIImage) -> UIImage? // NSImage on macOS

If your processor needs to manipulate image metadata (ImageContainer), or get access to more information via the context (ImageProcessingContext), there is now an additional method that allows you to do that:

func process(_ container: ImageContainer, context: ImageProcessingContext) -> ImageContainer?

ImageDecoding Improvements

/// An image decoder which supports automatically registering in the decoder register.
public protocol ImageDecoderRegistering: ImageDecoding {
    init?(data: Data, context: ImageDecodingContext)
    // Optional
    init?(partiallyDownloadedData data: Data, context: ImageDecodingContext)

ImageEncoding Improvements

#353 - There are now two levels of image encoding APIs. For the basic encoding needs, implement the following method:

func encode(_ image: UIImage) -> UIImage? // NSImage on macOS

If your encoders needs to manipulate image metadata (ImageContainer), or get access to more information via the context (ImageEncodingContext), there is now an additional method that allows you to do that:

func encode(_ container: ImageContainer, context: ImageEncodingContext) -> Data?

Progressive Decoding Improvements

Improved Cache For Processed Images - #345

Nuke 9 revisits data cache for processed images feature introduced in Nuke 8.0 and fixes all the rough edges around it.

There are two primary changes.

1. Deprecate isDataCachingForOriginalImageDataEnabled and isDataCachingForProcessedImagesEnabled properties.

These properties were replaced with a new DataCacheOptions.

public struct DataCacheOptions {
    /// Specifies which content to store in the `dataCache`. By default, the
    /// pipeline only stores the original image data downloaded using `dataLoader`.
    /// It can be configured to encode and store processed images instead.
    /// - note: If you are creating multiple versions of the same image using
    /// different processors, it might be worse enabling both `.originalData`
    /// and `.encodedImages` cache to reuse the same downloaded data.
    /// - note: It might be worth enabling `.encodedImages` if you want to
    /// transcode downloaded images into a more efficient format, like HEIF.
    public var storedItems: Set<DataCacheItem> = [.originalImageData]

public enum DataCacheItem {
    /// Original image data.
    case originalImageData
    /// Final image with all processors applied.
    case finalImage

Now we no longer rely on documentation to make sure that you disable data cache for original image data when you decide to cache processed images instead.

2. Rework DataCacheItem.finalImage behavior.

The primary reason for deprecation is a significantly changed behavior of data cache for processed images.

The initial version introduced back in Nuke 8.0 never really made sense. For example, only images for requests with processors were stored, but not the ones without. You can see how this could be a problem, especially if you disable data cache for original image data which was a recommended option.

The new behavior is much simpler. You set configuration.dataCacheOptions.storedItems to [. finalImage], and Nuke encodes and stores all of the downloaded images, regardless of whether they were processed or not.

DataCache Improvements - #350

Nuke 9 realized the original vision for DataCache. The updated staging/flushing mechanism now performs flushes on certain intervals instead of on every write. This makes some of the new DataCache features possible.


This release introduces ImageContainer type. It is integrated throughout the framework instead of PlatformImage.



public protocol ImageCaching: AnyObject {
    subscript(request: ImageRequest) -> ImageContainer?



Nuke 8

Nuke 8.4.1

March 19, 2020


There are two new Swift packages available in Nuke ecosystem:

Both are distributed exclusively via Swift Package Manager. And both are API previews. Please, try them out, and feel free to contact me with any feedback that you have.

Nuke 8.4.0

November 17, 2019

Nuke 8.3.1

October 26, 2019

Nuke 8.3.0

October 06, 2019

Nuke 8.2.0

September 20, 2019

Nuke 8.1.1

September 1, 2019

Nuke 8.1

August 25, 2019

Nuke 8.0.1

July 21, 2019

Nuke 8.0

July 8, 2019

Nuke 8 is the most powerful, performant, and refined release yet. It contains major advancements it some areas and brings some great new features. One of the highlights of this release is the documentation which was rewritten from the ground up.

Cache processed images on disk · New built-in image processors · ImagePipeline v2 · Up to 30% faster main thread performance · Result type · Improved deduplication · os_signpost integration · Refined ImageRequest API · Smart decompression · Entirely new documentation

Most of the Nuke APIs are source compatible with Nuke 7. There is also a Nuke 8 Migration Guide to help with migration.

Image Processing

#227 Cache Processed Images on Disk

ImagePipeline now supports caching of processed images on disk. To enable this feature set isDataCacheForProcessedDataEnabled to true in the pipeline configuration and provide a dataCache. You can use a built-in DataCache introduced in Nuke 7.3 or write a custom one.

Image cache can significantly improve the user experience in the apps that use heavy image processors like Gaussian Blur.

#243 New Image Processors

Nuke now ships with a bunch of built-in image processors including:

There are also ImageProcessor.Anonymous to create one-off processors from closures and ImageProcessor.Composition to combine two or more processors.

#245 Simplified Processing API

Previously Nuke offered multiple different ways to add processors to the request. Now there is only one, which is also better than all of the previous versions:

let request = ImageRequest(
    url: URL(string: "http://..."),
    processors: [
        ImageProcessor.Resize(size: CGSize(width: 44, height: 44), crop: true),
        ImageProcessor.RoundedCorners(radius: 16)

Processors can also be set using a respective mutable processors property.

Notice that AnyImageProcessor is gone! You can simply use ImageProcessing protocol directly in places where previously you had to use a type-erased version.

#229 Smart Decompression

In the previous versions, decompression was part of the processing API and ImageDecompressor was the default processor set for each image request. This was mostly done to simplify implementation but it was confusing for the users.

In the new version, decompression runs automatically and it no longer a "processor". The new decompression is also smarter. It runs only when needed – when we know that image is still in a compressed format and wasn't decompressed by one of the image processors.

Decompression runs on a new separate imageDecompressingQueue. To disable decompression you can set a new isDecompressionEnabled pipeline configuration option to false.

#247 Avoiding Duplicated Work when Applying Processors

The pipeline avoids doing any duplicated work when loading images. Now it also avoids applying the same processors more than once. For example, let's take these two requests:

let url = URL(string: "")
pipeline.loadImage(with: ImageRequest(url: url, processors: [
    ImageProcessor.Resize(size: CGSize(width: 44, height: 44)),
    ImageProcessor.GaussianBlur(radius: 8)
pipeline.loadImage(with: ImageRequest(url: url, processors: [
    ImageProcessor.Resize(size: CGSize(width: 44, height: 44))

Nuke will load the image data only once, resize the image once and apply the blur also only once. There is no duplicated work done at any stage. If any of the intermediate results are available in the data cache, they will be used.

ImagePipeline v2

Nuke 8 introduced a major new iteration of the ImagePipeline class. The class was introduced in Nuke 7 and it contained a lot of incidental complexity due to addition of progressive decoding and some other new features. In Nuke 8 it was rewritten to fully embrace progressive decoding. The new pipeline is smaller, simpler, easier to maintain, and more reliable.

It is also faster.

+30% Main Thread Performance

The image pipeline spends even less time on the main thread than any of the previous versions. It's up to 30% faster than Nuke 7.

#239 Load Image Data

Add a new ImagePipeline method to fetch original image data:

public func loadData(with request: ImageRequest,
                     progress: ((_ completed: Int64, _ total: Int64) -> Void)? = nil,
                     completion: @escaping (Result<(data: Data, response: URLResponse?), ImagePipeline.Error>) -> Void) -> ImageTask

This method now powers ImagePreheater with destination .diskCache introduced in Nuke 7.4 (previously it was powered by a hacky internal API).

#245 Improved ImageRequest API

The rarely used options were extracted into the new ImageRequestOptions struct and the request initializer can now be used to customize all of the request parameters.

#255 filteredURL

You can now provide a filteredURL to be used as a key for caching in case the URL contains transient query parameters:

let request = ImageRequest(
    url: URL(string: "")!,
    options: ImageRequestOptions(
        filteredURL: ""

#241 Adopt Result type

Adopt the Result type introduced in Swift 5. So instead of having a separate response and error parameters, the completion closure now has only one parameter - result.

public typealias Completion = (_ result: Result<ImageResponse, ImagePipeline.Error>) -> Void


Apart from the general performance improvements Nuke now also offers a great way to measure performance and gain visiblity into how the system behaves when loading images.

#250 Integrate os_signpost

Integrate os_signpost logs for measuring performance. To enable the logs set ImagePipeline.Configuration.isSignpostLoggingEnabled (static property) to true before accessing the shared pipeline.

With these logs, you have visibility into the image pipeline. For more information see WWDC 2018: Measuring Performance Using Logging which explains os_signpost in a great detail.

Screenshot 2019-06-01 at 10 46 52


All the documentation for Nuke was rewritten from scratch in Nuke 8. It's now more concise, clear, and it even features some fantastic illustrations:

Screenshot 2019-06-11 at 22 31 18

The screenshots come the the reworked demo project. It gained new demos including Image Processing demo and also a way to change ImagePipeline configuration in runtime.


Nuke 7

Nuke 7.6.3

May 1, 2019

Nuke 7.6.2

Apr 24, 2019

Nuke 7.6.1

Apr 13, 2019

Nuke 7.6

Apr 7, 2019

Nuke 7.5.2

Dec 26, 2018

Nuke 7.5.1

Nov 8, 2018

Nuke 7.5

Oct 21, 2018




Nuke 7 had a lot of API changes, to make the migration easier it shipped with Deprecated.swift file (536 line of code) which enabled Nuke 7 to be almost 100% source-compatible with Nuke 6. It's been 6 months since Nuke 7 release, so now it's finally a good time to remove all of this code.

Nuke 7.4.2

Oct 1, 2018

Nuke 7.4.1

Sep 25, 2018

Nuke 7.4

Sep 22, 2018

Prefetching Improvements

Other Changes

Nuke 7.3.2

Jul 29, 2018

Nuke 7.3.1

Jul 20, 2018

Nuke 7.3

Jun 29, 2018

This release introduces new DataCache type and features some other improvements in custom data caching.

Migration note: The storage format - which is simply a bunch of files in a directory really - is backward compatible with the previous implementation. If you'd like the new cache to continue working with the same path, please create it with "com.github.kean.Nuke.DataCache" name and use the same filename generator that you were using before:

try? DataCache(name: "com.github.kean.Nuke.DataCache", filenameGenerator: filenameGenerator)

Nuke 7.2.1

Jun 18, 2018

Nuke's roadmap is now publicly available. Please feel free to contribute!

This update addresses tech debt introduces in version 7.1 and 7.2. All of the changes made in these version which improved deduplication are prerequisites for implementing smart prefetching which be able to skip decoding, load to data cache only, etc.


Nuke 7.2

Jun 12, 2018




Nuke 7.1

May 27, 2018



Nuke 7.0.1

May 16, 2018



Nuke 7.0

May 10, 2018

Nuke 7 is the biggest release yet. It has a lot of massive new features, new performance improvements, and some API refinements. Check out new Nuke website to see quick videos showcasing some of the new features.

Nuke 7 is almost completely source-compatible with Nuke 6.

Progressive JPEG & WebP

Add support for progressive JPEG (built-in) and WebP (build by the Ryo Kosuge). See README for more info. See demo project to see it in action.

Add new ImageProcessing protocol which now takes an extra ImageProcessingContext parameter. One of its properties is scanNumber which allows you to do things like apply blur to progressive image scans reducing blur radius with each new scan ("progressive blur").

Resumable Downloads (HTTP Range Requests)

If the data task is terminated (either because of a failure or a cancellation) and the image was partially loaded, the next load will resume where it was left off. In many use cases resumable downloads are a massive improvement to user experience, especially on the mobile internet.

Resumable downloads require the server support for HTTP Range Requests. Nuke supports both validators (ETag and Last-Modified).

The resumable downloads are enabled by default. The resumable data is automatically stored in efficient memory cache. This is a good default, but future versions might add more customization options.

Loading Images into Views

Add a new set of powerful methods to load images into views. Here's one of those methods:

public func loadImage(with request: ImageRequest,
                      options: ImageLoadingOptions = ImageLoadingOptions.shared,
                      into view: ImageDisplayingView,
                      progress: ImageTask.ProgressHandler? = nil,
                      completion: ImageTask.Completion? = nil) -> ImageTask?

You can now pass progress and completion closures as well as new ImageLoadingOptions struct which offers a range of options:

public struct ImageLoadingOptions {
    public static var shared = ImageLoadingOptions()
    public var placeholder: Image?
    public var transition: Transition?
    public var failureImage: Image?
    public var failureImageTransition: Transition?
    public var isPrepareForReuseEnabled = true
    public var pipeline: ImagePipeline?
    public var contentModes: ContentModes?

    /// Content modes to be used for each image type (placeholder, success, failure).
    public struct ContentModes {
        public var success: UIViewContentMode
        public var failure: UIViewContentMode
        public var placeholder: UIViewContentMode

    /// An animated image transition.
    public struct Transition {
        public static func fadeIn(duration: TimeInterval, options: UIViewAnimationOptions = [.allowUserInteraction]) -> Transition
        public static func custom(_ closure: @escaping (ImageDisplayingView, Image) -> Void) -> Transition

ImageView will now also automatically prepare itself for reuse (can be disabled via ImageLoadingOptions)

Instead of an ImageTarget protocol we now have a new simple ImageDisplaying protocol which relaxes the requirement what can be used as an image view (it's UIView & ImageDisplaying now). This achieves two things:

Image Pipeline

The previous Manager + Loading architecture (terrible naming, responsibilities are often confusing) was replaced with a new unified ImagePipeline class. ImagePipeline was built from the ground-up to support all of the powerful new features in Nuke 7 (progressive decoding, resumable downloads, performance metrics, etc).

There is also a new ImageTask class which feels the gap where user or pipeline needed to communicate between each other after the request was started. ImagePipeline and ImageTask offer a bunch of new features:

Animated Images (GIFs)

Add built-in support for animated images (everything expect the actual rendering). To enable rendering you're still going to need a third-party library (see FLAnimatedImage and Gifu plugins). The changes made in Nuke dramatically simplified those plugins making both of them essentially obsolete - they both now have 10-30 lines of code, you can just copy this code into your project.

Memory Cache Improvements

Aggressive Disk Cache (Experimental)

Add a completely new custom LRU disk cache which can be used for fast and reliable aggressive data caching (ignores HTTP cache control). The new cache lookups are up to 2x faster than URLCache lookups. You can enable it using pipeline's configuration:

When enabling disk cache you must provide a keyEncoder function which takes image request's url as a parameter and produces a key which can be used as a valid filename. The demo project uses sha1 to generate those keys.

$0.enableExperimentalAggressiveDiskCaching(keyEncoder: {
    guard let data = $0.cString(using: .utf8) else { return nil }
    return _nuke_sha1(data, UInt32(data.count))

The public API for disk cache and the API for using custom disk caches is going to be available in the future versions.

Existing API already allows you to use custom disk cache by implementing DataLoading protocol, but this is not the most straightforward option.

Performance Metrics

When optimizing performance, it's important to measure. Nuke collects detailed performance metrics during the execution of each image task:

ImagePipeline.shared.didFinishCollectingMetrics = { task, metrics in


(lldb) po metrics

Task Information {
    Task ID - 1
    Duration - 22:35:16.123 – 22:35:16.475 (0.352s)
    Was Cancelled - false
    Is Memory Cache Hit - false
    Was Subscribed To Existing Session - false
Session Information {
    Session ID - 1
    Total Duration - 0.351s
    Was Cancelled - false
Timeline {
    22:35:16.124 – 22:35:16.475 (0.351s) - Total
    nil – nil (nil)                      - Check Disk Cache
    22:35:16.131 – 22:35:16.410 (0.278s) - Load Data
    22:35:16.410 – 22:35:16.468 (0.057s) - Decode
    22:35:16.469 – 22:35:16.474 (0.005s) - Process
Resumable Data {
    Was Resumed - nil
    Resumable Data Count - nil
    Server Confirmed Resume - nil

Other Changes


Nuke 6

Nuke 6.1.1

Apr 9, 2018

Nuke 6.1

Feb 24, 2018




Nuke 6.0

Dec 23, 2017

About 8 months ago I finally started using Nuke in production. The project has matured from a playground for experimenting with Swift features to something that I rely on in my day's job.

There are three main areas of improvements in Nuke 6:




Removed APIs

Nuke 5

Nuke 5.2

Sep 1, 2017

Add support for both Swift 3.2 and 4.0.

Nuke 5.1.1

Jun 11, 2017

Nuke 5.1

Feb 23, 2017

Nuke 5.0.1

Feb 2, 2017

Nuke 5.0

Feb 1, 2017


Nuke 5 is a relatively small release which removes some of the complexity from the framework.

One of the major changes is the removal of promisified API as well as Promise itself. Promises were briefly added in Nuke 4 as an effort to simplify async code. The major downsides of promises are compelex memory management, extra complexity for users unfamiliar with promises, complicated debugging, performance penalties. Ultimately I decided that promises were adding more problems that they were solving.


Removed promisified API and Promise itself

Memory cache is now managed exclusively by Manager

The reason behind this change is to reduce confusion about Cache usage. In previous versions the user had to pass Cache instance to both Loader (which was both reading and writing to cache asynchronously), and to Manager (which was just reading from the cache synchronously). In a new setup it's clear who's responsible for managing memory cache.

Removed DataCaching and CachingDataLoader

Those two types were included in Nuke to make integrating third party caching libraries a bit easier. However, they were actually not that useful. Instead of using those types you could've just wrapped DataLoader yourself with a comparable amount of code and get much more control. For more info see Third Party Libraries: Using Other Caching Libraries.

Other Changes

Nuke 4

Nuke 4.1.2

Oct 22, 2016

Bunch of improvements in built-in Promise:

*Nuke.Promise is a simplified variant of Pill.Promise (doesn't allow throws, adds completion, etc). The Promise is built into Nuke to avoid fetching external dependencies.

Nuke 4.1.1

Oct 4, 2016

Nuke 4.1 ⚡️

Oct 4, 2016

Nuke 4.1 is all about performance. Here are some notable performance improvements:

Nuke 4.0 focused on stability first, naturally there were some performance regressions. With the version 4.1 Nuke is again the fastest framework out there. The performance is ensured by a new set of performance tests.

If you're interested in the types of optimizations that were made check out recent commits. There is a lot of awesome stuff there!

Nuke 4.1 also includes a new Performance Guide and a collection of Tips and Tricks.

Other Changes

Nuke 4.0 🚀

Sep 19, 2016


Nuke 4 has fully adopted the new Swift 3 changes and conventions, including the new API Design Guidelines.

Nuke 3 was already a slim framework. Nuke 4 takes it a step further by simplifying almost all of its components.

Here's a few design principles adopted in Nuke 4:

The adoption of those design principles resulted in a simpler, more testable, and more concise code base (which is now under 900 slocs, compared to AlamofireImage's 1426, and Kingfisher's whopping 2357).

I hope that Nuke 4 is going to be a pleasure to use. Thanks for your interest 😄

You can learn more about Nuke 4 in an in-depth Nuke 4 Migration Guide.

Highlighted New Features

LRU Memory Cache

Nuke 4 features a new custom LRU memory cache which replaced NSCache. The primary reason behind this change was the fact that NSCache is not LRU]. The new Nuke.Cache has some other benefits like better performance, and more control which would enable some new advanced features in future versions.

Rate Limiter

There is a known problem with URLSession that it gets trashed pretty easily when you resume and cancel URLSessionTasks at a very high rate (say, scrolling a large collection view with images). Some frameworks combat this problem by simply never cancelling URLSessionTasks which are already in .running state. This is not an ideal solution, because it forces users to wait for cancelled requests for images which might never appear on the display.

Nuke has a better, classic solution for this problem - it introduces a new RateLimiter class which limits the rate at which URLSessionTasks are created. RateLimiter uses a token bucket algorithm. The implementation supports quick bursts of requests which can be executed without any delays when "the bucket is full". This is important to prevent the rate limiter from affecting "normal" requests flow. RateLimiter is enabled by default.

You can see RateLimiter in action in a new Rate Limiter Demo added in the sample project.

Toucan Plugin

Make sure to check out new Toucan plugin which provides a simple API for processing images. It supports resizing, cropping, rounded rect masking and more.

Nuke 3

Nuke 3.2

Sep 8, 2016

Nuke 3.1.3

Jul 17, 2016

#72 Fix synchronization issue in ImageManager loader:task:didFinishWithImage... method

Nuke 3.1.2

Jul 14, 2016

Nuke 3.1.1

Jun 7, 2016

Nuke 3.1

Apr 15, 2016

Nuke 3.0

Mar 26, 2016

Nuke 2

Nuke 2.3

Mar 19, 2016

Nuke 2.2

Mar 11, 2016

Nuke 2.1

Feb 27, 2016

Nuke 2.0.1

Feb 10, 2016

Nuke 2.0

Feb 6, 2016

Nuke now has an official website!

Main Changes

UI Extensions Changes

Other Changes

Nuke 1

Nuke 1.4

Jan 9, 2016

Nuke 1.3

Dec 7, 2015

Nuke 1.2

Nov 15, 2015

Nuke 1.1.1

Oct 30, 2015

Nuke 1.1

Oct 23, 2015

Nuke 1.0

Oct 18, 2015

extension MKAnnotationView: ImageDisplayingView, ImageLoadingView {
    // That's it, you get default implementation of all the methods in ImageLoadingView protocol
    public var nk_image: UIImage? {
        get { return self.image }
        set { self.image = newValue }

Nuke 0.x

Nuke 0.5.1

Oct 13, 2015

Nuke is now available almost everywhere. Also got rid of CocoaPods subspecs.

New Supported Platforms

Repo Changes

Code Changes

Nuke 0.5

Oct 9, 2015

This is a pre-1.0 version, first major release which is going to be available soon.



Nuke 0.4

Oct 4, 2015




Nuke 0.3.1

Sep 22, 2015

#10 Fix Carthage build

Nuke 0.3

Sep 21, 2015

Nuke 0.2.2

Sep 20, 2015

Nuke 0.2.1

Sep 19, 2015

Nuke 0.2

Sep 18, 2015



Nuke 0

Mar 11, 2015