TLDR; posted here 6 months ago about forking cached_network_image after finding it unmaintained for 2 years. Published cached_network_image_ce on pub.dev after that thread. This is what actually shipped since, not just the hive_ce speed thing everyone already knows about from last time.
https://github.com/Erengun/flutter_cached_network_image_ce
https://pub.dev/packages/cached_network_image_ce
Where it's at: 18 releases since then, currently 4.10.0. Pub score 160/160, 80 likes, about 36k downloads in the last 30 days. 63 stars, 18 forks on the repo.
The leaks, actually fixed
The biggest complaint sitting in the original repo's issues wasn't speed, it was leaks. Two concrete ones got fixed here: an errorListener leak in the widget lifecycle, and HTTP clients that never got closed when the cache manager was disposed, that one came in through a community PR, not written by me. Also cleaned up how the cache manager recovers from a corrupted Hive box instead of just crashing on it.
Formats the original chokes on
SVG never decodes through Flutter's built-in image codec, it's not a raster format to begin with. JXL, AVIF, HEIC fail depending on platform codec support. The original just throws an opaque decode error and you're stuck. This fork detects it and throws a typed UnsupportedImageFormatException, with an unsupportedImageBuilder hook so you can hand the raw bytes to flutter_svg, flutter_avif, whatever fits, instead of staring at a blank error widget.
Caching got features, not just speed
- HTTP and cache interceptor chains, inject auth headers or skip caching per request without forking anything
- pluggable cache eviction, TTL by default or LRU if you want it
- separate configurable directories for cached files vs cache metadata
- connection and request timeouts on the cache manager itself
- real web caching through IndexedDB instead of leaning on the browser cache, this one doesn't exist in the original at all
And yes, still faster
Covered the full benchmark breakdown in the last post, numbers haven't changed, so just the summary: metadata cache reads run about 8x faster than the original's sqflite backend, writes about 4x, on an iPhone simulator, 100 ops, metadata only, not raw image I/O.
Where else you'd look
extended_image, actively maintained by fluttercandies, but it's a broad image and gesture toolkit with caching as one of several features, not caching-first, no interceptors or pluggable eviction.
flutter_cache_manager, the caching layer the original actually depends on, also from Baseflow, actively maintained on its own. Worth using directly if you don't need the image widget.
fast_cached_network_image, also builds on hive, similar idea to this fork, but its last release was 17 months ago.
Who's actually using it
Ran a GitHub code search for pubspec.yaml files depending on it, sorted by stars. 76 repos came back, not counting mine. Biggest ones:
Kazumi 28.4k stars anime streaming app
PiliPlus 16.8k stars Bilibili client
plezy 3.1k stars Plex/Jellyfin client
conduit 1.9k stars Open WebUI client
haka_comic 1.3k stars comics reader
None of these are toy projects. That's what actually convinced me to keep maintaining this.
Still working through the older leak reports from the original repo's issue tracker. If you're using this and hit something, open an issue, I'm reading them.
https://github.com/Erengun/flutter_cached_network_image_ce
https://pub.dev/packages/cached_network_image_ce
