Nuke 6.1.1

• Lower macOS deployment target to 10.10 - #156
• Improve README: add detailed Image Pipeline section, Performance section, rewrite Usage guide

Nuke 6.1

Features

• Add Request.Priority with 5 available options ranging from .veryLow to .veryHigh. One of the use cases of Request.Priority is to lower the priority of preheating requests. In case requests get deduplicated (multiple requests are handled by a single task) the task's priority is set to the highest priority of registered requests and gets updated when requests are added or removed from the task.

Improvements

• Fix warnings on Xcode 9.3 beta 3
• Loader implementation changed a bit, it is less clever now and is able to accommodate new features like request priorities
• Minor changes in style guide to make codebase more readable
• Switch to native NSLock, there doesn't seem to be any performance wins anymore when using pthread_mutex directly

Fixes

• #146 fix disk cache path for macOS, thanks to @willdahlberg

Nuke 6.0 🏎

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:

• Performance. The primary loadImage(with:into:) method is now 1.5x faster thanks to cumulative performance improvements to CancellationToken, Manager, Request and Cache. And it's not just main thread performance, many of the background operations were also optimized.
• API refinements. Some common operations that were surprisingly hard are easy now. And there the implementation details are no longer leaking into a public API (e.g. classes like Deduplicator).
• Fixed inconveniences like Thread Sanitizer warnings (false positives!). Improved compile time. Better documentation.

New APIs

• Implements progress reporting #81
• Scaling images is now easier and more discoverable with new convenience Request initialisers (Request.init(url:targetSize:contentMode: and Request.init(urlRequest:targetSize:contentMode:)
• Add a way to add anonymous image processors to the request (Request.process(key:closure:) and Request.processed(key:closure:))
• Add Loader.Options which can be used to configure Loader (e.g. change maximum number of concurrent requests, disable deduplication or rate limiter, etc).

Improvements

• Improve CancellationTokenSource, Loader, TaskQueue, Manager, Request, Cache performance
• Parallelize image processing for up to 2x performance boost in certain scenarios. Might increase memory usage. The default maximum number of concurrent tasks is 2 and can be configured using Loader.Options.
• Loader now always calls completion on the main thread
• Move URLResponse validation from DataDecoder to DataLoader
• Make use of some Swift 4 feature like nested types inside generic types
• Improve compile time
• Wrap Loader processing and decoding tasks into autoreleasepool which reduced memory footprint

Fixes

• Get rid of Thread Sanitizer warnings in CancellationTokenSource (false positive)
• Replace Foundation.OperationQueue & custom Foundation.Operation subclass with a new Queue type. It's simpler, faster, and gets rid of pesky Thread Sanitizer warnings #141

Removed APIs

• Remove global loadImage(...) functions #142
• Remove static Request.loadKey(for:) and Request.cacheKey(for:) functions. The keys are now simply returned in Request's loadKey and cacheKey properties which are also no longer optional now.
• Remove Deduplicator class, make this functionality part of Loader. This has a number of benefits: reduced API surface, improves performance by reducing the number of queue switching, enables new features like progress reporting.
• Remove Scheduler, AsyncScheduler, Loader.Schedulers, DispatchQueueScheduler, OperationQueueScheduler. This whole infrastructure was way too excessive.
• Make RateLimiter private
• DataLoader now works with URLRequest, not Request

Nuke 6.0-beta2

• Fix memory leak in Loader - regression introduced in 6.0-beta1
• Get rid of Thread Sanitizer warnings in CancellationTokenSource (false positive)
• Improve performance of CancellationTokenSource
• Improve Cache hits and writes performance by ~15%
• Improve Loader performance

Nuke 6.0-beta1

About 8 months ago I started using Nuke in production. The project has matured from being a playground for experimenting with Swift features to something that I rely on in my day job. The primary goal behind Nuke 6 is to simplify the project even further and to get rid of the implementation details leaking into a public API.

Nuke is now Swift 4 only. It's simpler, smaller (< 1000 lines of code), and faster. It features progress reporting and makes it simpler to create custom data loader (e.g. Alamofire data loader).

Features

• Implements progress reporting #81

Removed APIs

• Remove global loadImage(...) functions #142
• Remove Deduplicator class, make this functionality part of Loader. This has a number of benefits: reduced API surface, improves performance by reducing number of queue switching, enables new features like progress reporting.
• Remove schedulers (DispatchQueueScheduler, OperationQueueScheduler, etc). This whole infrastructure was way too excessive.
• Make RateLimiter private.

Improvements

• Replace Foundation.OperationQueue & custom Foundation.Operation subclass with a new TaskQueue type. It's simpler, faster, and gets rid of pesky Thread Sanitizer warnings #141
• DataLoader now works with URLRequest, not Request
• Loader now always calls completion on the main thread.
• Move URLResponse validation from DataDecoder to DataLoader
• Make use of some Swift 4 feature like nested types inside generic types.

Nuke 5.2

Add support for both Swift 3.2 and 4.0.

Nuke 5.1.1

• Fix Swift 4 warnings
• Add DataLoader.sharedUrlCache to easy access for shared URLCache object
• Add references to RxNuke
• Minor improvements under the hood

Nuke 5.1

• De facto Manager has already implemented Loading protocol in Nuke 5 (you could use it to load images directly w/o targets). Now it also conforms to Loading protocols which gives access to some convenience functions available in Loading extensions.
• Add static func targetSize(for view: UIView) -> CGSize method to Decompressor
• Simpler, faster Preheater
• Improved documentation

Nuke 5.0.1

• #116 Manager can now be used to load images w/o specifying a target
• Preheater is now initialized with Manager instead of object conforming to Loading protocol

Nuke 5.0 🍒

Overview

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

Changes

Removed promisified API and Promise itself

• Remove promisified API, use simple closures instead. For example, Loading protocol's method func loadImage(with request: Request, token: CancellationToken?) -> Promise<Image> was replaced with a method with a completion closure func loadImage(with request: Request, token: CancellationToken?, completion: @escaping (Result<Image>) -> Void). The same applies to DataLoading protocol.
• Remove Promise class
• Remove PromiseResolution<T> enum
• Remove Response typealias
• Add Result<T> enum which is now used as a replacement for PromiseResolution<T> (for instance, in Target protocol, etc)

Memory cache is now managed exclusively by Manager

• Remove memory cache from Loader
• Manager now not only reads, but also writes to Cache
• Manager now has new methods to load images w/o target (Nuke 5.0.1)

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

• Loader constructor now provides a default value for DataDecoding object
• DataLoading protocol now works with a Nuke.Request and not URLRequest in case some extra info from Nuke.Request is required
• Reduce default URLCache disk capacity from 200 MB to 150 MB
• Reduce default maxConcurrentOperationCount of DataLoader from 8 to 6
• Shared objects (like Manager.shared) are now constants.
• Preheater is now initialized with Manager instead of Loading object
• Add new Third Party Libraries guide.
• Improved documentation