Sharing apps as signed bundles

When you want to hand an app to someone else, export it as a bundle: a single .apptrope file that packs the app’s files together with a manifest that describes and protects them. The recipient can load that one file directly into Apptrope, and Apptrope checks its integrity before anything runs. This page covers how to create a bundle, what goes into one (and what deliberately does not), and how signing works.

Export a bundle

Every app in your Library has a ⋯ actions menu on its card. To create a bundle:

Find the app in your Library (use search if you have a lot of them).
Open the card’s ⋯ menu.
Choose Export bundle….
Pick where to save the resulting .apptrope file.

That single .apptrope file is the whole shareable artifact. You can send it however you like (email, a shared drive, a chat message), and the person on the other end loads it the same way they would load any other app source: point Apptrope at the .apptrope bundle file.

What a bundle contains

A bundle is two things wrapped into one file:

The app files are the source and assets that make up the app.
A manifest is metadata about the app plus a SHA-256 integrity hash computed over the whole file surface of the bundle.

The integrity hash is the important part. It is a fingerprint of everything in the bundle, and Apptrope verifies it before the app runs. If a single byte of the bundle changed in transit or on disk, the hash will not match and Apptrope will know the bundle is not what was exported.

What is excluded

Bundles are meant to be safe to share, so a couple of categories are left out automatically:

Dotfiles, files and folders whose names begin with a ., are not included.
Secrets, the environment variables and secrets you set through a card’s ⋯ → Environment… editor, live in your OS keychain (or a local secrets file in debug builds), and they are never placed inside a bundle.

Because secrets stay behind, a recipient who runs your bundle will not inherit your API keys, tokens, or other private values. If the app needs those to work, the recipient sets their own through the same Environment… editor after they load it.

Signing with your author key

A bundle can be signed with your Ed25519 author key. Signing does two things beyond the built-in integrity check:

It proves the bundle came from you, not just that it is internally consistent.
It lets recipients who already trust your key run your apps smoothly.

Integrity and signing work together:

Protection	What it proves	Who provides it
SHA-256 integrity hash	The bundle is unmodified since export	Every bundle, automatically
Ed25519 author signature	The bundle really came from you	Bundles you sign with your author key

You manage your identity and signing key from the Publishers panel in the top bar. That same panel is where you rotate your key over time and manage revocation if a key is ever compromised.

How recipients trust a bundle

On the receiving end, running a not-yet-trusted bundle brings up a “Confirm before running” dialog that shows the signature status. For example, it shows whether the bundle’s integrity was verified and, if it was signed, who signed it. From there a recipient can trust the publisher so that future signed apps from you launch without a prompt.

For the full picture of what recipients see and how trusting a publisher works, including trust on first use, pinning a publisher’s key, and revocation, see the Trust page.

Quick reference

Export from a card’s ⋯ → Export bundle…. The output is one .apptrope file.
The bundle carries the app files plus a manifest with a SHA-256 hash over the whole surface.
The integrity hash is checked before the app runs.
Optionally sign with your Ed25519 author key to prove authorship.
Dotfiles and secrets are always excluded.
Recipients trust bundles through the “Confirm before running” flow. See the Trust page.