Asset Catalog Tinkerer: Opening .car Files Without Xcode
An app that lets you open .car files and browse/extract their images.
At a glance
- What is it?
- A macOS app that reads compiled asset catalogs and theme store files, shows the images inside, and lets you export them. Useful for inspecting a shipped app bundle, limited by its image-only scope.
- Who is it for?
- Adopt it if you need to pull images out of a compiled .car file or a theme store bundle on a Mac and you do not want to keep a full Xcode project around just to inspect one catalog. Do not adopt it if your catalog's interesting content is colors, or if you need a supported command-line pipeline for automated extraction.
- Can I use it commercially?
- Yes. BSD-2-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 141 days ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The .car file is a black box until you have a viewer
An asset catalog starts life in Xcode as a folder of PNGs, PDFs and JSON metadata. Once the build runs, that folder is compiled into a single binary file with a .car extension, and the individual images stop being separate files you can open in Preview. The README describes the app's job in one line: it lets you open asset catalog files and view the images they contain, then copy or export individual images or the whole catalog. That is the entire problem statement. There is no metadata editor, no diffing, no build integration. The audience is narrow and obvious: iOS and macOS developers who want to see what actually shipped inside a bundle, designers checking whether the right @2x and @3x variants made it through a build, and anyone poking at a third-party app's Resources directory. The README also notes a second file type the app handles, theme store files, which hold assets for UI components. Examples of those live in /System/Library/CoreServices/SystemAppearance.bundle, and the app also reads ProKit theme stores found inside ProKit.framework and LunaKit.framework. That second capability is what pushes it past being a one-trick viewer for app bundles, because it reaches into system and first-party app resources that are otherwise opaque.
What the app actually does with a catalog
The mechanism is read-and-render, not decode-and-rebuild. You point the app at a .car file, it parses the catalog, and it presents the contained images in a browsable list. From there the README describes two output paths: drag individual assets out of the window, or export the entire catalog or a selected subset to a directory. There is no mention of re-importing a modified catalog, no mention of editing metadata, and no mention of writing a .car back out. That asymmetry matters. The tool is a one-way valve from compiled format to loose image files. The repository layout supports the same reading: the project is written in Swift, and the topics list includes objective-c alongside swift, which suggests the parsing code draws on both. The QuickLook plugin is a separate target that hooks the same reading logic into Finder's preview, so selecting a .car in a Finder window shows a thumbnail grid without launching the main app. That plugin is the part most people will use daily, because it removes the step of opening a file in an application at all.
Installing it, and the two distribution channels
The README gives three ways in. The first is a direct download of a zipped release from the repository's releases directory, linked as AssetCatalogTinkerer_latest.zip. The second is Homebrew: brew install asset-catalog-tinkerer. The third is a Gumroad page where you can pay any amount, which the README frames as downloading and contributing. If you want the QuickLook plugin to work, the Homebrew route is the one worth checking first, since a cask install places the app bundle in the usual location where macOS registers its QuickLook extensions. A zip pulled straight from the repository may need to be moved into /Applications before the system picks up the plugin. The repository also carries a releases/ directory on the main branch, which is where the latest zip link points. Version numbers in the release history run 2.6-b1, 2.7, then 2.9, so the cadence is irregular rather than scheduled. There is no configuration file, no environment variable and no CLI flags documented in the material, which means anything you want to automate has to go through the GUI or through the QuickLook preview.
Colors, and everything else the app was not built for
The README is unusually direct about this: the app was designed with images in mind, so it does not support some of the more modern asset catalog features, such as colors, and it may or may not be updated to support them. Read that as a hard boundary rather than a roadmap. A modern catalog is not just bitmaps. It carries named color sets, and once you are past images, the tool has nothing to show you. If your investigation is about why a dark mode color resolved incorrectly, Asset Catalog Tinkerer will not help, because the color is not an image and the app has no view for it. The same applies to any other non-image asset type the compiled format supports. The second limitation is subtler: the README says the app can open any .car file, but it does not claim to handle every catalog version. Nothing in the supplied material states which catalog format revisions are understood, so a catalog produced by a much newer Xcode than the app was built against is an open question, not a documented guarantee. If the app fails to list assets you know are present, that is the first thing to check.
How it compares with assetutil and the Xcode route
The obvious alternative on macOS is the assetutil command-line tool that ships with Xcode. Both read compiled catalogs, but they sit at opposite ends of the workflow. assetutil is a text tool: it dumps catalog structure as JSON, which makes it scriptable and diffable, and it can be piped into other tools. Asset Catalog Tinkerer is a GUI: it shows you pixels, and its output is image files rather than structured data. If you need to answer a question about which scale variants exist, or you want to compare two builds of the same catalog in a script, assetutil's JSON output is the better fit, and Asset Catalog Tinkerer adds nothing there. If you need to look at the images, the reverse is true, because a JSON dump of a large catalog is not something you can scan visually. There is also the plain Xcode route: open the original .xcassets source folder if you have it. That is obviously better when you have the source, which is why the tool's real value is concentrated in the cases where you do not, such as a shipped app bundle, a theme store inside a framework, or a catalog from a build you no longer have the project for.
Maintenance, licensing and what a fork would inherit
The repository is not archived, and the most recent push recorded is 2026-04-27, well after the 2.9 release in August 2024. So the project is alive, but the release history shows long gaps: 2.6-b1 in July 2019, 2.7 in December 2021, 2.9 in August 2024. Anyone depending on it should plan around that rhythm rather than expect prompt fixes for a new catalog format. The licence is BSD-2-Clause, which is permissive and short. In practical terms that means you can read the source, modify it, and redistribute a modified build, provided you keep the copyright notice and the licence text with the distribution. It does not carry the patent grant language you would find in some other permissive licences, and it places no copyleft obligation on your own code. That is a description of the licence text, not legal advice; if you are shipping a modified build inside a commercial product, have someone qualified read the actual file in the repository. The upgrade cost is low in the sense that there is no configuration to migrate and no server component. It is a Mac app. The cost that does exist is the QuickLook plugin, which needs to be re-registered by the system after an update, and the fact that a catalog format change from Apple would require a code change rather than a settings tweak.
Where it earns its place and where it does not
The strongest case for Asset Catalog Tinkerer is a one-off inspection: you have a .car file, you want to know what images are inside, and you want them out. The drag-to-export and export-all paths in the README cover that without any setup beyond installing the app. The QuickLook plugin makes the same inspection nearly free when you are already in Finder. The weakest case is anything that looks like a pipeline. There is no documented CLI, no stable machine-readable output, and no stated support for non-image asset types, so building an automated extraction step on top of it would mean driving a GUI. For that, assetutil's JSON output is the tool that fits, and pairing the two is reasonable: assetutil to enumerate and script, Asset Catalog Tinkerer to look at the images when enumeration is not enough. The honest summary is that this is a focused viewer that does one thing, does it without a project file, and is explicit in the README about the category of asset it will not show you.
Editorial conclusion
Adopt it if you need to pull images out of a compiled .car file or a theme store bundle on a Mac and you do not want to keep a full Xcode project around just to inspect one catalog. Do not adopt it if your catalog's interesting content is colors, or if you need a supported command-line pipeline for automated extraction. Before relying on it, open one catalog you already know the contents of and confirm that every asset you expect appears, then check the BSD-2-Clause text in the repository if you plan to redistribute a modified build.
Community notes