Sharing it

A .blipbar file

blipkit pack makes one file anyone can install: they open it (double-click, or Settings › Blips › Install…), and Blipbar shows what it is before anything is installed: its title, version, author and id, and everything its manifest lets it do, the hosts it can reach first, and running programs or touching files in orange, since that goes beyond a network extension. Install copies it in, places it in the panel and selects it in Settings. Opening a newer version later replaces it (settings and saved keys stay, since they go by id); if the author differs from the one installed, the install sheet says so in orange, because the new one would take over those keys.

Two things Blipbar refuses:

• An id in Blipbar’s own space (dev.blipbar.…). Settings and saved keys go by id, so an extension claiming dev.blipbar.stripe would read Stripe’s key. Only the bundled extensions use it (and blipkit dev’s link while working on one of them); blipkit pack won’t pack one.
• A file that isn’t just an extension: an entry that would land outside its folder, a link, more than 2,000 entries or 100 MB unpacked. Blipbar reads the zip’s table of contents before writing anything.

Put the file anywhere people can download it (a GitHub release is the usual place).

Before you share it

People install an extension expecting it to look and behave like the rest of Blipbar, and the install sheet is where they decide whether to trust it. Check yours for the ways an extension can break that:

• Manifest hygiene. id is reverse-DNS, in a space of your own (a domain you own, reversed, or dev.yourname.). title and description read like the ones in The manifest’s table, not a placeholder. icon is a real SF Symbol. categories matches an existing one where possible.
• Least-privilege permissions. network lists exactly the hosts you call, not a wildcard for everything. exec is empty unless you genuinely shell out. files covers only paths you actually touch. Remember none of this is a sandbox (Permissions), so the person installing your extension is trusting your manifest to be honest.
• No formatting workarounds. Numbers, currency, dates, and durations go through the value helpers (Value helpers), never pre-formatted into a string. A value: "$1,247" or a hand-built "2h 14m" string can’t be formatted for the viewer’s locale, and it makes your blip read differently from every other one.
• Layout fits the data, not the other way around. Don’t force a list because you want five lines of text: pick stat/progress/session/score/countdown/meter if one of those is the actual shape of what you’re showing (Builders: one per layout says what each is for).
• States mean what they say. attention is for something that needs a decision, not “any update at all”: it’s the one state that plays the notch’s attention animation and reminds again while it waits. stale/offline show the last known value, dimmed, with when it was last updated: never a live-looking number that’s actually old data from a dead connection. offline is for the network; a wrong setting (a 404, an unknown symbol or league, a link to a web page instead of a feed) is failure, with a subtitle that says what to fix, since retrying will never fix it.
• At most 4 actions, in order (small spaces show the first one or two), and destructive is really destructive. role: "destructive" asks first automatically: don’t use it for something reversible just to make it look serious, and don’t skip it (by choosing a different role) for something that actually can’t be undone.
• Stay under 4KB. A payload over 4KB after truncation is dropped. series (≤48 points), facts (≤4), and list.items (≤5) are cut to size for you, but you can still build a payload that’s too large in other fields (a long subtitle, a huge event string). blipkit validate shows you the real serialized payload; eyeball its size for anything text-heavy.
• interval matches how often the data actually changes. Polling every 10 seconds for a value that changes hourly spends battery for nothing, and battery drain is the usual reason people remove a notch app.
• Accessibility isn’t optional. This one is entirely the renderer’s job once you’ve picked a real layout and real typed values: you get it for free by not fighting the SDK (no raw Text for a number, no custom view). If you find yourself reaching for something the SDK doesn’t expose to get a look you want, that’s the signal to simplify the blip, not to work around the constraint.

If your extension needs something the SDK doesn’t support (a permission, an event type, a layout), ask in the Discord (https://discord.gg/FYHPMd66AG) rather than routing around the constraint from inside your extension.

The directory

Settings › Blips › Browse… lists the extensions in Blipbar’s directory, github.com/blipbar/extensions. To add yours, make a GitHub release of the .blipbar file from a public repo, then open a pull request there that adds one small entry: your id, the repo, the version, the file’s release URL and its SHA-256 (blipkit pack prints the whole entry). A check downloads the file and verifies the hash, then a person reads the source before it’s merged. Every update is a new entry version, reviewed the same way. Blipbar checks each download against the entry’s hash before the install sheet opens, so what installs is what was reviewed.