Nuke 4.1.2

Bunch of improvements in a built-in Promise:

• Promise now also uses new Lock - faster creation, faster locking
• Add convenience isPending, resolution, value and error properties
• Simpler implementation migrated from Pill.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

• Fix deadlock in Cache - small typo, much embarrassment 😄 (kean/Nuke-Alamofire-Plugin#8)

Nuke 4.1 ⚡️

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

• loadImage(with:into:) method with a default config is 6.3x faster
• Cache operations (write/hit/miss) are from 3.1x to 4.5x faster

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 (see the benchmark). 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.

Nuke 4.1 also includes a new Performance Guide and a collection of Tips and Tricks (it's just a draft really).

Other Changes

• Add convenience method loadImage(with url: URL, into target: AnyObject, handler: @escaping Handler) (more useful than anticipated).
• #88 Add convenience cancelRequest(for:) function
• Use @discardableResult in Promise where it makes sense
• Simplified Loader implementation
• Cache nodes are no longer deallocated recursively on removeAll() and deinit (I was hitting stack limit in benchmarks, it's impossible in real-world use).
• Fix: All Cache public trim() methods are now thread-safe too.

Nuke 4.0 🚀

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:

• Protocol-Oriented Programming. Nuke 3 promised a lot of customization by providing a set of protocols for loading, caching, transforming images, etc. However, those protocols were vaguely defined and hard to implement in practice. Protocols in Nuke 4 are simple and precise, often consisting of a single method.
• Single Responsibility Principle. For example, instead of implementing preheating and deduplicating of equivalent requests in a single vague ImageManager class, those features were moved to separate classes (Preheater, Deduplicator). This makes core classes much easier to reason about.
• Principle of Least Astonishment. Nuke 3 had a several excessive protocols, classes and methods which are all gone now (ImageTask, ImageManagerConfiguration just to name a few). Those features are much easier to use now.
• Simpler Async. Image loading involves a lot of asynchronous code, managing it was a chore. Nuke 4 adopts two design patterns (Promise and CancellationToken) that solve most of those problems.

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 solution for this problem - it introduces a new RateLimiter class which limits the rate at which URLSessionTasks are created. RateLimiter uses a classic 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 4.0-beta3

• #80 Final changes for Xcode 8 GM

Nuke 3.2

• Swift 2.3 support
• Preheating is now thread-safe #75

Nuke 4.0-beta2

• Use custom LRU memory cache instead of NSCache which is not LRU, and which is a bit slower, because you have to wrap keys (which are structs) into objects.
• Fix memory leak in Deduplicator

Nuke 4.0-beta1

Nuke 4 was rewritten from scratch for Swift 3 and new Swift API Design Guidelines.

Nuke 4 is now essentially a micro framework. It means smaller code base (now has 791 lines of code compared to Kingfisher's 2357); principle of least astonishment; more and simpler ways to extend existing functionality.

I hope it's going to be a pleasure to use. Thanks for your interest 😄

Nuke 3.1.3

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

Nuke 3.1.2

• #71 ImageViewLoadingController now cancels tasks synchronously, thanks to @adomanico