How to Create Custom Docsets for Dash
Updated
Dash can generate custom docsets for libraries and packages that aren't in its built-in catalog. You have two routes: use the Docset Generator to build a docset from your own documentation, or let Dash integrate with a package manager (Swift Packages, Ruby Gems, Python, PHP, Java) to produce one automatically. Either way, the finished docset behaves like any of Dash's 200+ built-in sets — it's searchable offline and kept alongside your other documentation.
What You Need Before Starting
- Dash for macOS installed (a purchase link is available on kapeli.com; the site does not state that the app is free).
- The source documentation for the library you want to index — either generated HTML docs or a package that a supported package manager can resolve.
- A rough idea of which entry points matter, so you can verify the docset actually contains what you expect.
Route 1: Generate a Docset from Your Own Documentation
Dash's Docset Generator is the path for libraries with existing HTML documentation (for example, a Sphinx or Javadoc output folder).
- Prepare the input. Point the generator at the folder containing your documentation's HTML files. The generator reads these pages to build the searchable index.
- Run the generation. The generator parses the HTML and produces a
.docsetbundle. - Add it to Dash. Install the resulting docset so Dash indexes it like a built-in set.
- Verify. Open Dash and search for a symbol or page title you know exists in the source docs. If it doesn't appear, the generator likely didn't reach that part of the HTML tree — check that all pages are in the input folder and linked correctly.
This route is best when your docs are already published as static HTML and you want an offline copy that matches your own version, not a generic upstream release.
Route 2: Generate Docsets Through Package Managers
Dash integrates with package managers to generate docsets for packages you actually use. The site lists these sources:
| Ecosystem | Source |
|---|---|
| Swift Packages | swiftpackageindex.com |
| Ruby Gems | rubygems.org |
| Python Packages | Any Sphinx docs |
| PHP Packages | packagist.org |
| Java Packages | maven.org (listing truncated on the source page) |
The workflow is the same across ecosystems: identify the package, let Dash pull its documentation through the corresponding source, and the generated docset becomes searchable in Dash. For Python specifically, the requirement is that the package ships Sphinx documentation — a package without Sphinx docs won't produce a usable docset this way.
Choose this route when you want documentation for a specific dependency version rather than a broad language reference. It's also the faster option: no manual HTML collection, and updates follow the package source.
Route 3: Use Third-Party Documentation Sources
Dash also accepts docsets from third-party sources and lets you request that a docset be added to its official catalog. Use this when someone else has already built the docset you need — it saves you the generation step entirely. If no docset exists anywhere, the request path is the way to get it into the maintained catalog rather than maintaining it yourself.
Verifying and Using the Result
After installation, confirm three things:
- Search works: type a known class, function, or method name and check that the correct page opens.
- Content is current: compare a recently changed API against the docset entry; a stale docset usually means the source docs weren't regenerated.
- It coexists with built-ins: custom docsets appear alongside the 200+ standard sets, so you can search across all of them at once.
If you use an AI agent workflow, note that Dash advertises MCP support for integration with Claude and other AI agents — a generated docset becomes part of the documentation corpus those tools can draw on, provided the integration is configured.
Common Stumbling Blocks
- Empty or partial docset: usually caused by incomplete HTML input or docs that aren't in a format the generator can parse. Sphinx output works for Python; hand-written HTML with unusual structure may not.
- Package not found: the package manager integration only covers packages published to the listed sources. A private or unpublished library needs Route 1.
- Docs out of date: generated docsets don't refresh themselves from your local source; regenerate after major documentation changes.
- Expecting a free download: the site shows a purchase link for Dash. Treat pricing and licensing as something to confirm on kapeli.com rather than assuming the app is free.
Which Route Should You Pick?
- Your own library with published HTML docs → Docset Generator (Route 1).
- A public package in Swift, Ruby, Python, PHP, or Java → package manager integration (Route 2).
- A docset someone already built → third-party source or catalog request (Route 3).
Start with Route 2 if your dependency is public — it's the least manual work. Fall back to the Docset Generator when the library is internal or its docs aren't served by a supported package source.