Skip to content


Switch branches/tags

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


Nuke image caching library for Xamarin.Forms.

Get it from NuGet:


This repository was inspired by Jonathan Peppers GlideX implementation of the new IImageViewHandler interface for Xamarin.Forms (

Its goal is to provide the same kind of implementation for iOS, achieving a complete image caching solution for Xamarin.Forms: you don't have to change any line of your existing project, the Xamarin.Forms image source handlers will just be overridden with cache-enabled ones.



  1. Install in your xamarin forms iOS project
  2. Add this Init method after Forms.Init call:
Xamarin.Forms.Nuke.FormsHandler.Init(debug: false);
LoadApplication(new App());


  1. Install in your xamarin forms Android project
  2. Add this one liner after your app's Forms.Init call:
Xamarin.Forms.Forms.Init (this, bundle);
//This forces the custom renderers to be used
Android.Glide.Forms.Init (this);
LoadApplication (new App ());


You just achieved 90%+ memory reduction when manipulating Image views on both platforms.

Support for iOS < 12.2

As specified here:

You need to add the Xamarin.iOS.SwiftRuntimeSupport NuGet package to your target project if you want to support iOS 12.1 and earlier. Please read the above doc to submit an app with such support.

Known Issues

Xamarin.Forms.Nuke cannot cache images coming from the Asset Catalog:

This is due to the fact that the Asset Catalogue is packed in the ipa, and you cannot get an image URI from it. Since version 8.4.1, it will however cache correctly images respecting the density convention (@2x, @3x) locating in your Resources folder (see Issue #13).

However, if you still have some issues with your local images, you can disable Xamarin.Forms.Nuke for all FileImageSource by setting the disableFileImageSourceHandling parameter of the FormsHandler.Init to true:

Xamarin.Forms.Nuke.FormsHandler.Init(debug: false, disableFileImageSourceHandling: true);
LoadApplication(new App());


I changed a bit the glidex benchmark samples to have a more fair comparison. I switched from a random distribution of the images to a deterministic one to be sure we are comparing the same data set.

I used System.Diagnostics.Process.GetCurrentProcess().WorkingSet64 to have the memory workload of the process. The value given in the results are the consumed bytes between the MainPage and the complete loading of the target page.

The tests have been made on an iPhone 7 (real device, not a simulator).

For each test:

  1. Launch iPhone 7
  2. Wait 4-5 seconds on MainPage
  3. Launch a Page
  4. Scroll till the end of page
  5. Get consumed bytes in the output window
  6. Empty caches
  7. Kill app
Page Data Type Xamarin.Forms Xamarin.Forms.Nuke 8.4.0
GridOnlyRemotePage Remote only 248 905 728 15 073 280 (-94%)
GridPage Remote and local mix 195 035 136 15 040 512 (-92%)
ViewCellPage Remote and local mix 41 418 752 20 758 528 (-50%)
ImageCellPage Remote and local mix 27 000 832 20 611 072 (-24%)
HugeImagePage Local only 128 516 096 8 634 368 (-93%)

Comparison with FFImageLoading

Before I could successfully bind the Nuke swift library, I tried to use FFImageLoading as image source handler. You can find the older repository here:

As expected the native Nuke library outperforms FFImageLoading on every test.

Page Data Type FFImageLoading Xamarin.Forms.Nuke 8.4.0
GridOnlyRemotePage Remote only 25 722 880 15 073 280 (-41%)
GridPage Remote and local mix 24 674 304 15 040 512 (-39%)
ViewCellPage Remote and local mix 28 852 224 (1) 20 758 528 (-28%)
ImageCellPage Remote and local mix 28 868 608 (2) 20 611 072 (-28%)
HugeImagePage Local only 10 059 776 8 634 368 (-14%)
  • (1) often fails to load first images (failed 7 times on 10)
  • (2) often fails to load some images (failed 6 times on 10)

And more importantly, it loads way faster the cells images:

View Cells test

FFImageLoading Nuke

Image Cells test

FFImageLoading Nuke


The famous iOS Nuke native image caching library for Xamarin.Forms







No packages published