September 20, 2019
- Add support for Mac Catalyst – #299, Jonathan Downing)
September 1, 2019
- Switch to a versioning scheme which is compatible with Swift Package Manager
August 25, 2019
- Configure dispatch queues with proper QoS – #291, Michael Nisi)
- Remove synchronization points in
ImageDecoderwhich is not needed starting from iOS 10 – #277 - Add Swift Package Manager to Installation Guides
- Improve Travis CI setup: run tests on multiple Xcode versions, run thread safety tests, run SwiftLint validations, build demo project, validate Swift package – #279, #280, #281, #284, #285
July 21, 2019
- Remove synchronization in
ImageDecoderwhich is no longer needed – #277
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 ·
Resulttype · Improved deduplication ·os_signpostintegration · 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.
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.
Nuke now ships with a bunch of built-in image processors including:
ImageProcessor.ResizeImageProcessor.RoundedCornersImageProcessor.CircleImageProcessor.GaussianBlurImageProcessor.CoreImageFilter
There are also ImageProcessor.Anonymous to create one-off processors from closures and ImageProcessor.Composition to combine two or more processors.
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
processorsproperty.
Notice that
AnyImageProcessoris gone! You can simply useImageProcessingprotocol directly in places where previously you had to use a type-erased version.
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.
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: "http://example.com/image")
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.
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.
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.
Add a new ImagePipeline method to fetch original image data:
@discardableResult
public func loadData(with request: ImageRequest,
progress: ((_ completed: Int64, _ total: Int64) -> Void)? = nil,
completion: @escaping (Result<(data: Data, response: URLResponse?), ImagePipeline.Error>) -> Void) -> ImageTaskThis method now powers ImagePreheater with destination .diskCache introduced in Nuke 7.4 (previously it was powered by a hacky internal 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.
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: "http://example.com/image.jpeg?token=123")!,
options: ImageRequestOptions(
filteredURL: "http://example.com/image.jpeg"
)
)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>) -> VoidApart 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.
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.
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:
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.
- Add a cleaner way to set
ImageTaskpriority using a newpriorityproperty – #251 - [macOS] Implement image cost calculation for
ImageCache– #236 - [watchOS] Add
WKInterfaceImagesupport - Future-proof Objective-C
ImageDisplayingprotocol by addingnuke_prefixes to avoid clashes in Objective-C runtime - Add convenience
func decode(data: Data) -> Image?method with a defaultisFinalargument toImageDecodingprotocol – e3ca5e - Add convenience
func process(image: Image) -> Image?method toImageProcessingprotocol DataCachewill now automatically re-create its root directory if it was deleted underneath it- Add public
flushmethod toDataCache
May 1, 2019
- Fix #226
ImageTask.setPriority(_:)sometimes crashes
Apr 24, 2019
- Fix Thread Sanitizer warnings. The issue was related to
unfair_lockusage which was introduced as a replacement forOSAtomicfunctions in Nuke 7.6. In order to fix the issue,unfair_lockwas replaced with simpleNSLock. The performance hit is pretty insignificant and definitely isn't worth introducing this additional level of complexity.
Apr 13, 2019
- Fix SwiftPM 5.0 support by adding explicit platform version requirements – Vadim Shpakovski in #220
- Update Nuke 7 Migration Guide
Apr 7, 2019
- Add Swift 5.0 support – Daniel Storm in #217
- Add SwiftPM 5.0 support – Vadim Shpakovski in #219
- Remove Swift 4.0 and Swift 4.1 support
- Remove iOS 9, tvOS 9, watchOS 2.0, macOS 10.10 and macOS 10.11 support
- Add a single
Nuketarget which can build the framework for any platform - Replace deprecated
OSAtomicfunctions withunfair_lock, there are no performance regressions
Dec 26, 2018
- [macOS] Fix
Nuke.loadImageimage is not displayed when.fadeIntransition is used – #206 - Add
.alwaysTransitionflag toImageLoadingOptions– @gabzsa in #201
Nov 8, 2018
- Update Swift version in pbxproj to Swift 4.2, #199
- Update demo to Swift 4.2
Oct 21, 2018
- #193 Add an option to
ImageDecompressorto allow images to upscale, thanks to @drkibitz - #197 Add a convenience initializer to
ImageRequestwhich takes an image processor (ImageProcessing) as a parameter, thanks to @drkibitz
- Add a guarantee that if you cancel
ImageTaskon the main thread, you won't receive any more callbacks (progress, completion) - Improve internal
Operationperformance, images are loading up to 5% faster
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.
Oct 1, 2018
- #174 Fix an issue with an
ImageViewreuse logic where in rare cases a wrong image would be displayed, thanks to @michaelnisi
Sep 25, 2018
- Disable automatic
stopPreheatingwhich was causing some issues
Sep 22, 2018
- Add an
ImagePreheater.Destinationoption toImagePreheater. The default option is.memoryCachewhich works exactly the wayImagePreheaterused to work before. The more interesting option is.diskCache. The preheater with.diskCachedestination will skip image data decoding entirely to reduce CPU and memory usage. It will still load the image data and store it in disk caches to be used later. - Add convenience
func startPreheating(with urls: [URL])function which creates requests with.lowrequests for you. ImagePreheaternow automatically cancels all of the managed outstanding requests on deinit.- Add
UICollectionViewDataSourcePrefetchingdemo on iOS 10+. Nuke still supports iOS 9 so Preheat is also still around.
- #187 Fix an issue with progress handler reporting incorrect progress for resumed (206 Partial Content) downloads
- Remove
enableExperimentalAggressiveDiskCachingfunction fromImagePipeline.Configuration, please useDataCachedirectly instead - Update Performance Guide
Jul 29, 2018
- #178 Fix TSan warning being triggered by performance optimization in
ImageTask.cancel()(false positive) - Fix an issue where a request (
ImageRequest) with a default processor and a request with the same processor but set manually would have different cache keys
Jul 20, 2018
ImagePipelinenow updates the priority of shared operations when the registered tasks get canceled (was previosuly only reacting to added tasks)- Fix an issue where
didFinishCollectingMetricsclosure wasn't called for the tasks completed with images found in memory cache and the tasks canceled before they got a chance to run. Now every created tasks gets a correspondingdidFinishCollectingMetricscall.
Jun 29, 2018
This release introduces new DataCache type and features some other improvements in custom data caching.
- Add new
DataCachetype - a cache backed by a local storage with an LRU cleanup policy. This type is a reworked version of the experimental data cache which was added in Nuke 7.0. It's now much simpler and also faster. It allows for reading and writing in parallel, it has a simple consistent API, and I hope it's going to be a please to use.
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)
-
#160
DataCachenow has a defaultFilenameGeneratoron Swift 4.2 which usesSHA1hash function provided byCommonCrypto(CommonCryptois not available on the previous version of Swift). -
#171 Fix a regression introduced in version 7.1. where experimental
DataCachewould not perform LRU data sweeps. -
Update
DataCachingprotocol. To store data you now need to implement a synchronous methodfunc cachedData(for key: String) -> Data?. This change was necessary to make the data cache fit nicely inImagePipelineinfrastructure where each stage is managed by a separateOperationQueueand each operation respects the priority of the image requests associated with it. -
Add
dataCachingQueueparameter toImagePipeline.Configuration. The defaultmaxConcurrentOperationCountis2. -
Improve internal
Operationtype performance.
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.
- Simpler and more efficient model for managing decoding and processing operations (including progressive ones). All operations now take the request priority into account. The processing operations are now created per processor, not per image loading session which leads to better performance.
- When subscribing to existing session which already started processing, pipeline will try to find existing processing operation.
- Update
DFCacheintegration demo to use newDataCachingprotocol - Added "Default Image Pipeline" section and "Image Pipeline Overview" sections in README.
- Update "Third Party Libraries" guide to use new
DataCachingprotocol
Jun 12, 2018
- #163 Add
DataCachingprotocol which can be used to implement custom data cache. It's not documented yet, the documentation going to be updated in 7.2.1.
- Initial iOS 12.0, Swift 4.2 and Xcode 10 beta 1 support
- #167
ImagePipelinenow usesOperationQueueinstead ofDispatchQueuefor decoding images. The queue now respectsImageRequestpriority. If the task is cancelled the operation added to a queue is also cancelled. The queue can be configured viaImagePipeline.Configuration. - #167
ImagePipelinenow updates processing operations' priority.
- Fix a regression where in certain deduplication scenarios a wrong image would be saved in memory cache
- Fix MP4 demo project
- Improve test coverage, bring back
DataCache(internal) tests
May 27, 2018
- Improve deduplication. Now when creating two requests (at roughly the same time) for the same images but with two different processors, the original image is going to be downloaded once (used to be twice in the previous implementation) and then two separate processors are going to be applied (if the processors are the same, the processing will be performed once).
- Greatly improved test coverage.
- Fix an issue when setting custom
loadKeyfor the request, thehashValueof the default key was still used. - Fix warnings "Decoding failed with error code -1" when progressively decoding images. This was the result of
ImageDecodertrying to decode incomplete progressive scans. - Fix an issue where
ImageDecodercould produce a bit more progressive scans than necessary.
May 16, 2018
- Add a section in README about replacing GIFs with video formats (e.g.
MP4,WebM) - Add proof of concept in the demo project that demonstrates loading, caching and displaying short
mp4videos using Nuke
- #161 Fix the contentModes not set when initializing an ImageLoadingOptions object
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.
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").
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.
Add a new set of powerful methods to load images into views. Here's one of those methods:
@discardableResult
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:
- You can now add support for more classes (e.g.
MKAnnotationViewby implementingImageDisplayingprotocol - You can override the
display(image:method inUIImageViewsubclasses (e.g.FLAnimatedImageView)
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:
- To cancel the request you now simply need to call
cancel()on the task (ImageTask) which is a bit more user-friendly than previousCancellationTokenSourceinfrastructure. ImageTaskoffers a new way to track progress (in addition to closures) - nativeFoundation.Progress(created lazily)ImageTaskcan be used to dynamically change the priority of the executing tasks (e.g. the user opens a new screen, you lower the priority of outstanding tasks)- In
ImagePipeline.Configurationyou can now provide custom queues (OperationQueue) for data loading, decoding and processing (separate queue for each stage). - You can set a custom shared
ImagePipeline.
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.
- Add new
ImageCachingprotocol for memory cache which now works with a newImageResponeclass. You can do much more intelligent things in your cache implementations now (e.g. make decisions on when to evict image based on HTTP headers). - Improve cache write/hit/miss performance by 30% by getting rid of AnyHashable overhead.
ImageRequestcacheKeyandloadKeyare now optional. If you use them, Nuke is going to use them instead of built-in internalImageRequest.CacheKeyandImageRequest.LoadKey. - Add
TTLsupport inImageCache
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
DataLoadingprotocol, but this is not the most straightforward option.
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
print(metrics)
}(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
}
ImagePreheaternow checksImageCachesynchronously before creating tasks which makes it slightly more efficient.RateLimiternow uses the same sync queue as theImagePipelinereducing a number of dispatched blocks- Smarter
RateLimiterwhich no longer attempt to execute pending tasks when the bucket isn't full resulting in idle dispatching of blocks. I've used a CountedSet to see how well it works in practice and it's perfect. Nice small win. - Add
ImageDecoderRegistryto configure decoders globally. - Add
ImageDecodingContextto provide as much information as needed to select a decoder. ImageTask.Completionnow containsImageResponse(image + URLResponse) instead of just plain image.
CancellationToken,CancellationTokenSource- continued to be used internally, If you'd like to continue using cancellation tokens please consider copying this code into your project.DataDecoding,DataDecoder,DataDecoderComposition- replaced by a new image decoding infrastructure (ImageDecoding,ImageDecoder,ImageDecodingRegistryetc).Requestrenamed toImageRequest.- Deprecate
Resulttype. It was only used in a single completion handler so it didn't really justify its existence. More importantly, I wasn't comfortable providing a publicResulttype as part of the framework.
Apr 9, 2018
- Lower macOS deployment target to 10.10. #156.
- Improve README: add detailed Image Pipeline section, Performance section, rewrite Usage guide
Feb 24, 2018
- Add
Request.Prioritywith 5 available options ranging from.veryLowto.veryHigh. One of the use cases ofRequest.Priorityis to lower the priority of preheating requests. In case requests get deduplicated 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.
- Fix warnings on Xcode 9.3 beta 3
Loaderimplementation 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 usingpthread_mutexdirectly
- #146 fix disk cache path for macOS, thanks to @willdahlberg
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:
- Performance. Nuke 6 is fast! The primary
loadImage(with:into:)method is now 1.5x faster thanks to performance improvements ofCancellationToken,Manager,RequestandCachetypes. 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 to do are not super easy. And there are no more implementation details leaking into a public API (e.g. classes like
Deduplicator). - Fixes some inconveniences like Thread Sanitizer warnings (false positives!). Improved compile time. Better documentation.
- Implements progress reporting kean#81
- Scaling images is now super easy with new convenience
Requestinitialisers (Request.init(url:targetSize:contentMode:andRequest.init(urlRequest:targetSize:contentMode:) - Add a way to add anonymous image processors to the request (
Request.process(key:closure:)andRequest.processed(key:closure:)) - Add
Loader.Optionswhich can be used to configureLoader(e.g. change maximum number of concurrent requests, disable deduplication or rate limiter, etc).
- Improve performance of
CancellationTokenSource,Loader,TaskQueue - Improve
Managerperformance by reusing contexts objects between requests - Improve
Cacheby ~30% for most operations (hits, misses, writes) Requestnow stores all of the parameters in the underlying reference typed container (it used to store just reference typed ones). TheRequeststruct now only has a single property with a reference to an underlying container.- 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. Loadernow always call completion on the main thread.- Move
URLResponsevalidation fromDataDecodertoDataLoader - Make use of some Swift 4 feature like nested types inside generic types.
- Improve compile time.
- Wrap
Loaderprocessing and decoding tasks intoautoreleasepoolwhich reduced memory footprint.
- Get rid of Thread Sanitizer warnings in
CancellationTokenSource(false positive) - Replace
Foundation.OperationQueue& customFoundation.Operationsubclass with a newQueuetype. It's simpler, faster, and gets rid of pesky Thread Sanitizer warnings kean#141
- Remove global
loadImage(...)functions kean#142 - Remove static
Request.loadKey(for:)andRequest.cacheKey(for:)functions. The keys are now simply returned inRequest'sloadKeyandcacheKeyproperties which are also no longer optional now. - Remove
Deduplicatorclass, make this functionality part ofLoader. 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
RateLimiterprivate. DataLoadernow works withURLRequest, notRequest
Sep 1, 2017
Add support for both Swift 3.2 and 4.0.
Jun 11, 2017
- Fix Swift 4 warnings
- Add
DataDecoder.sharedUrlCacheto easy access for sharedURLCacheobject - Add references to RxNuke
- Minor improvements under the hood
Feb 23, 2017
- De facto
Managerhas already implementedLoadingprotocol in Nuke 5 (you could use it to load images directly w/o targets). Now it also conforms toLoadingprotocols which gives access to some convenience functions available inLoadingextensions. - Add
static func targetSize(for view: UIView) -> CGSizemethod toDecompressor - Simpler, faster
Preheater - Improved documentation
Feb 2, 2017
- #116
Managercan now be used to load images w/o specifying a target Preheateris now initialized withManagerinstead of object conforming toLoadingprotocol
- 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.
- Remove promisified API, use simple closures instead. For example,
Loadingprotocol's methodfunc loadImage(with request: Request, token: CancellationToken?) -> Promise<Image>was replaced with a method with a completion closurefunc loadImage(with request: Request, token: CancellationToken?, completion: @escaping (Result<Image>) -> Void). The same applies toDataLoadingprotocol. - Remove
Promiseclass - Remove
PromiseResolution<T>enum - Remove
Responsetypealias - Add
Result<T>enum which is now used as a replacement forPromiseResolution<T>(for instance, inTargetprotocol, etc)
- Remove memory cache from
Loader Managernow not only reads, but also writes toCacheManagernow 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.
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.
Loaderconstructor now provides a default value forDataDecodingobjectDataLoadingprotocol now works with aNuke.Requestand notURLRequestin case some extra info fromURLRequestis required- Reduce default
URLCachedisk capacity from 200 MB to 150 MB - Reduce default
maxConcurrentOperationCountofDataLoaderfrom 8 to 6 - Shared objects (like
Manager.shared) are now constants. Preheateris now initialized withManagerinstead ofLoadingobject- Add new Third Party Libraries guide.
- Improved documentation
Oct 22, 2016
Bunch of improvements in built-in Promise:
Promisenow also uses newLock- faster creation, faster locking- Add convenience
isPending,resolution,valueanderrorproperties - 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.
Oct 4, 2016
- Fix deadlock in
Cache- small typo, much embarrassment 😄 (kean/Nuke-Alamofire-Plugin#8)
Oct 4, 2016
Nuke 4.1 is all about performance. Here are some notable performance improvements:
loadImage(with:into:)method with a default config is 6.3x fasterCacheoperations (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. 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.
- Add convenience method
loadImage(with url: URL, into target: AnyObject, handler: @escaping Handler)(more useful than anticipated). - #88 Add convenience
cancelRequest(for:)function - Use
@discardableResultinPromisewhere it makes sense - Simplified
Loaderimplementation Cachenodes are no longer deallocated recursively onremoveAll()anddeinit(I was hitting stack limit in benchmarks, it's impossible in real-world use).- Fix: All
Cachepublictrim()methods are now thread-safe too.
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:
- 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
ImageManagerclass, 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,ImageManagerConfigurationjust 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.
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.
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.
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.
Sep 8, 2016
- Swift 2.3 support
- Preheating is now thread-safe #75
Jul 17, 2016
#72 Fix synchronization issue in ImageManager loader:task:didFinishWithImage... method
Jul 14, 2016
- #71 ImageViewLoadingController now cancels tasks synchronously, thanks to @adomanico
Jun 7, 2016
- Demo project update to support CocoaPods 1.0
- #69 Bitcode support for Carthage builds, thanks to @vincentsaluzzo
Apr 15, 2016
- #64 Fix a performance regression: images are now decoded once per DataTask like they used to
- #65 Fix an issue custom on-disk cache (
ImageDiskCaching) was calledsetData(_:response:forTask:)method when the error wasn't nil - Add notifications for NSURLSessionTask state changes to enable activity indicators (based on kean/Nuke-Alamofire-Plugin#4)
Mar 26, 2016
- Update for Swift 2.2
- Move
ImagePreheatControllerto a standalone package Preheat - Remove deprecated
suspendmethod fromImageTask - Remove
ImageFilterGaussianBlurand Core Image helper functions which are now part of Core Image Integration Guide - Cleanup project structure (as expected by SPM)
Managerconstructor now has a default value for configurationnk_setImageWith(URL:)method no longer resizes images by default, because resizing is not effective in most cases- Remove
nk_setImageWith(request:options:placeholder:)method, it's trivial ImageLoadingViewdefault implementation no longer implements "Cross Dissolve" animations, useImageViewLoadingOptionsinstead (seeanimationsorhandlerproperty)- Remove
ImageViewDefaultAnimationDuration, useImageViewLoadingOptionsinstead (seeanimationsproperty) ImageDisplayingViewprotocol now has a singlenk_displayImage(_)method instead of ank_imageproperty- Remove
nk_targetSizeproperty fromUI(NS)Viewextension
Mar 19, 2016
- #60 Add custom on-disk caching support (see
ImageDiskCachingprotocol) - Reduce dynamic dispatch
Mar 11, 2016
ImageTasksuspendmethod is deprecated, implementation does nothingImageLoadernow limits a number of concurrentNSURLSessionTasks- Add
maxConcurrentSessionTaskCountproperty toImageLoaderConfiguration - Add
taskReusingEnabledproperty toImageLoaderConfiguration - Add Swift Package Manager support
- Update documentation
Feb 27, 2016
- #57
ImageDecompressornow usesCGImageAlphaInfo.NoneSkipLastfor opaque images - Add
ImageProcessorWithClosurethat can be used for creating anonymous image filters ImageLoaderensures thread safety of image initializers by running decoders on aNSOperationQueuewithmaxConcurrentOperationCount=1. However,ImageDecoderclass is now also made thread safe.
Feb 10, 2016
- #53 ImageRequest no longer uses NSURLSessionTaskPriorityDefault, which requires CFNetwork that doesn't get added as a dependency automatically
Feb 6, 2016
Nuke now has an official website!
- #48 Update according to Swift API Design Guidelines. All APIs now just feel right.
- Add
UIImageextension with helper functions forCore Image:nk_filter(_:), etc. - Add
ImageFilterGaussianBluras an example of a filter on top ofCore Imageframework - Add
ImageRequestMemoryCachePolicyenum that specifies the wayManagerinteracts with a memory cache;NSURLRequestCachePolicyno longer affects memory cache - #17 Add
prioritytoImageRequest - Add
removeResponseForKey()method toImageMemoryCachingprotocol and the corresponding method toManager - Implement congestion control for
ImageLoaderthat preventsNSURLSessiontrashing - Simplify
ImageLoaderDelegateby combining methods that were customizing processing in a single high-level method:imageLoader(_:processorFor:image:). Users now have more control over processing - Add
NSURLResponse?parameter todecodemethod fromImageDecodingprotocol DataLoadingprotocol no longer hasisLoadEquivalentRequest(_:toRequest)andisCacheEquivalentRequest(_:toRequest). Those methods are now part ofImageLoaderDelegateand they have default implementationImageResponseInfois now a struct- Improved error reporting (codes are now stored in enum, more codes were added, error is now created with a failure reason)
- Move
nk_ImageTask(_:didFinishWithResponse:options)method toImageLoadingViewprotocol, that's really where it belongs to - Add
handlerproperty toImageViewLoadingOptionsthat allows you to completely override display/animate logic inImageLoadingView - Remove
nk_prepareForReusemethod fromImageLoadingViewextensions (useless) - Remove
placeholderfromImageViewLoadingOptions, move it to a separate argument which is only available onImageDisplayingViews - Add
animated,userInfotoImageViewLoadingOptions ImageViewLoadingOptionsis now nonull everywhere- Add
setImageWith(task:options:)method toImageViewLoadingController
- If you add a completion handler for completed task, the response is now marked as
isFastResponse = true - Fix an issue that allowed incomplete image downloads to finish successfully when using built-in networking
equivalentProcessors(rhs:lhs:)function is now private (and it also is renamed)- Remove public
isLoadEquivalentToRequest(_:)andisCacheEquivalentToRequest(_:)methods fromImageRequestextension - Add
ImageTaskProgressstruct that represents load progress, movefractionCompletedproperty fromImageTasktoImageTaskProgress - Remove public helper function
allowsCachingfromImageRequestextension - Remove deprecated
XCPSetExecutionShouldContinueIndefinitelyfrom playground
Jan 9, 2016
- #46 Add option to disable memory cache storage, thanks to @RuiAAPeres
Dec 7, 2015
- Add Core Image Integration Guide
- Fill most of the blanks in the documentation
- #47 Fix target size rounding errors in image downscaling (Pyry Jahkola @pyrtsa)
- Add
imageScaleproperty toImageDecoderclass that returns scale to be used when creatingUIImage(iOS, tvOS, watchOS only) - Wrap each iteration in
ProcessorCompositionin anautoreleasepool
Nov 15, 2015
- #20 Add preheating for UITableView (see ImagePreheatControllerForTableView class)
- #41 Enhanced tvOS support thanks to @joergbirkhold
- #39 UIImageView: ImageLoadingView extension no available on tvOS
- Add factory method for creating session tasks in DataLoader
- Improved documentation
Oct 30, 2015
- #35 ImageDecompressor now uses
32 bpp, 8 bpc, CGImageAlphaInfo.PremultipliedLastpixel format which adds support for images in an obscure formats, including 16 bpc images. - Improve docs
Oct 23, 2015
- #25 Add tvOS support
- #33 Add app extensions support for OSX target (other targets were already supported)
Oct 18, 2015
- #30 Add new protocols and extensions to make it easy to add full featured image loading capabilities to custom UI components. Here's how it works:
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 }
}
}- #30 Add UIImageView extension instead of custom UIImageView subclass
- Back to the Mac! All new protocol and extensions for UI components (#30) are also available on a Mac, including new NSImageView extension.
- #26 Add
getImageTaskWithCompletion(_:)method to Manager - Add essential documentation
- Add handy extensions to ImageResponse
Oct 13, 2015
Nuke is now available almost everywhere. Also got rid of CocoaPods subspecs.
- CocoaPods, Nuke, watchOS
- CocoaPods, Nuke, OSX
- CocoaPods, NukeAlamofirePlugin, watchOS
- CocoaPods, NukeAlamofirePlugin, OSX
- Carthage, Nuke, watchOS
- Carthage, Nuke, OSX
- Carthage, NukeAlamofirePlugin, iOS
- Carthage, NukeAlamofirePlugin, watchOS
- Carthage, NukeAlamofirePlugin, OSX
- Remove Nuke/Alamofire subspec, move sources to separate repo Nuke-Alamofire-Plugin
- Remove Nuke/GIF subspec, move sources to separate repo Nuke-AnimatedImage-Plugin
- #9, #19 ImageTask now has a closure for progress instead of NSProgress
- Rename ImageLoadingDelegate to ImageLoadingManager
- Add ImageLoaderDelegate with factory method to construct image decompressor, and
shouldProcessImage(_:)method - Make ImageRequest extensions public
- Make ImageTask constructor public; Annotate abstract methods.
Oct 9, 2015
This is a pre-1.0 version, first major release which is going to be available soon.
- #18 ImageTask can now be suspended (see
suspend()method). AddsuspendLoadingForImageTask(_:)method toImageLoadingprotocol - #24 ImageRequest can now be initialized with NSURLRequest. ImageDataLoading
imageDataTaskWithURL(_:progressHandler:completionHandler:)method changed toimageDataTaskWithRequest(_:progressHandler:completionHandler:). First parameter is ImageRequest, return value change from NSURLSessionDataTask to NSURLSessionTask. - ImageLoader no longer limits number of concurrent NSURLSessionTasks (which had several drawbacks)
- Add base ImagePreheatingController class
- Multiple preheating improvements: significantly simplified implementation; visible index paths are now subtracted from preheat window; performance improvements.
- BUGFIX: When subscribing to an existing NSURLSessionTask user was receiving progress callback with invalid totalUnitCount
- Add public
equivalentProcessors(lhs:rhs:) -> Boolfunction that works on optional processors - Add essential documentation
Oct 4, 2015
- Make ImageLoading protocol and ImageLoader class public
- Make ImageManager
cachedResponseForRequest(_:)andstoreResponse(_:forRequest:)methods public - Make ImageRequestKey class and ImageRequestKeyOwner protocol public
- Remove unused ImageManaging and ImagePreheating protocols
- #13 BUGFIX: Crash on 32-bit iOS simulator on Mac with 16Gb+ of RAM (@RuiAAPeres)
- BUGFIX: Processing operation might not get cancelled in certain situations
- ImageProcessing protocol now provides default implementation for
isEquivalentToProcessor(_:)method including separate implementation for processors that also conform to Equatable protocol. - Add identifier: Int property to ImageTask
- ImageRequestKey now relies on Hashable and Equatable implementation provided by NSObject
- ImageMemoryCaching protocol now works with ImageRequestKey class
- Adopt multiple Swift best practices (tons of them in fact)
- ImageManager is now fully responsible for memory caching and preheating, doesn't delegate any work to ImageLoader (simplifies its implementation and limits dependencies)
- Remove ImageRequestKeyType enum
- Rename ImageManagerLoader to ImageLoader
- Simply ImageManagerLoader (now ImageLoader) implementation
- Add multiple unit tests
Sep 22, 2015
#10 Fix Carthage build
Sep 21, 2015
- ImageTask now acts like a promise
- ImageManager.shared is now a property instead of a method
- ImageTask progress is now created lazily
- Add maxConcurrentTaskCount to ImageManagerConfiguration
- Move taskWithURL method to ImageManaging extension
- Add ImagePreheating protocol
- Multiple improvements across the board
Sep 20, 2015
- Add limited Carthage support (doesn't feature FLAnimatedImage and Alamofire integration yet, you'll have to stick with CocoaPods for that)
- ImageTask resume() and cancel() methods now return Self
- ImageTask completion property is now public
- Minor implementation improvements
Sep 19, 2015
- Add ImageCollectionViewPreheatingController (yep)
- Add Image Preheating Guide
- Add preheating demo
Sep 18, 2015
- Optional Alamofire integration via 'Nuke/Alamofire' subspec
- Optional FLAnimatedImage integration via 'Nuke/GIF' subspec
- More concise API
- Add image filters to ImageRequest
- Add ImageManaging protocol
- Add ImageDecoderComposition
- Add ImageProcessorComposition
- watchOS
- Add convenience functions that forward calls to the shared manager
- Use ErrorType
- Add removeAllCachedImages method
- ImageRequest userInfo is now Any? so that you can pass anything including closures
- ImageResponseInfo now has userInfo: Any? property
- ImageResponseInfo is now a struct
- CachedImageResponse renamed to ImageCachedResponse; userInfo is now Any?
- Multiple improvements across the board
Mar 11, 2015
- Initial commit



