Skip to content
assetlib

Questions

How do I find unused images in my app?

Inventory every image file in the app's source tree with its size and dimensions, group exact duplicates by content hash, and then scan the source for literal references to each filename. Files with no reference are candidates to review, not a delete list: asset catalogs, generated identifiers, dynamic paths, density suffixes, and server-driven references can all keep an image in use without its name appearing in code. Duolingo reported removing over 17 MB of unused images from its iOS app with a review like this.

Updated October 9, 2026 · Assetlib

Is there a command that does the inventory?

Yes. The Assetlib audit is a free, read-only command on npm. It needs no account and makes no network calls after the package download:

npx -y @assetlib/audit@0.1.0 /path/to/your-app --assets assets --references src

It reports PNG, JPEG, and WebP files with measured bytes, SHA-256, and encoded dimensions; exact duplicate groups with the bytes the extra copies occupy; files whose long edge exceeds a threshold you set; and, when you pass --references, the source locations where each filename appears as a quoted literal. Pass --json for a stable machine-readable report. Pin the version so results are reproducible. Nothing is uploaded, optimized, deleted, or rewritten.

The same command is packaged as a skills-only plugin for Claude Code and Codex, so a coding agent can run it and explain the findings: claude plugin marketplace add AssetLib/agent-plugins, then claude plugin install assetlib-audit@assetlib. The source is in AssetLib/sdk-js.

The audit says 'no reference found.' Can I delete the file?

Not on that evidence alone. The scan matches quoted filename, basename, and relative-path literals in Swift, Objective-C, Kotlin, Java, XML, Dart, JavaScript, TypeScript, JSON, HTML, CSS, and SCSS. It does not execute code, build a usage graph, or see rendering telemetry. iOS asset catalogs and Android resources are referenced by generated symbols, not filenames. Images named by string concatenation, chosen by a server, or still needed by an older shipped build will show no match. Treat each unresolved file as a question for the person who owns that screen. DoorDash's app-size work describes finding images that looked unused in the mobile source and were still selected by backend systems.

What can I act on right away?

Exact duplicates are safe to consolidate: identical bytes under two names can become one file and one reference. Oversized files are worth a look: a 4000-pixel source shipped for a 300-point slot is paying download and memory for pixels no screen will show. Three copies of every image for 1x, 2x, and 3x are expected on iOS, so count them as one image when you judge the inventory. The audit's extraCopyBytes is an observation about copies on disk, not a promise about app-size savings; measure the built app before and after.

What comes after the inventory?

If the inventory shows a few images the team changes often, those are candidates to move out of the binary into placements that update without a release. The audit skill proposes at most three for a first migration and keeps the originals as bundled fallbacks. If nothing changes often, the inventory was still useful: consolidate duplicates, shrink oversized sources, and leave the rest bundled. Icons, launch graphics, and controls are usually better left in the app. How to change an image without an app update covers the options from there.