Developer docs.

Cocosign reads standard AltStore/SideStore-format repos — the same JSON shape you'd publish for AltStore, SideStore, Scarlet, and similar clients. Any repo that already works in those apps works in Cocosign with zero changes.

On top of that, Cocosign recognizes a small number of extra, optional fields for Cocosign-specific features. These are additive: a repo that includes them still parses correctly everywhere else — clients that don't recognize a field just ignore it. You never need a separate "Cocosign-only" repo; add these fields to your existing repo JSON and Cocosign will pick them up, everyone else won't notice.

This is the running list of those fields. New ones get appended here as they're added.

Where these fields go

All fields below are per-app, meaning they live inside each object in the top-level apps array — as siblings to standard fields like bundleIdentifier, name, version, etc. Not at the repo (top-level) level.

Custom fields

Every field below is optional. Set only the ones relevant to a given app — omitted fields are treated as unset/false, never as an error.

Demo video — demo_mp4 / demo_youtube_url

If either (or both) is set, Cocosign shows a "Watch Demo Video" row on the app's detail page, right below Screenshots.

• demo_youtube_url — a YouTube video link. Tapping the row opens it externally (YouTube app if installed, else Safari). Shown with a play/video icon.
• demo_mp4 — a direct link to an .mp4 file. Tapping the row plays it in an in-app video player, no external app needed. Shown with a film icon.

If both are set, Cocosign prefers demo_youtube_url and ignores demo_mp4 for that app — only set both if you want a fallback ready for a future change, since today only one is ever shown. Neither field is validated beyond "is it a well-formed URL"; a broken link just won't do anything useful when tapped.

Get Support — support_url

Adds a "Get Support" row to the Information section on the app's detail page — tapping it opens the URL externally. Use this for a contact page, support form, or a Discord invite specific to that app.

Before You Install — install_notes

Plain text — no markdown/HTML support today. Shown in a "Before You Install" card near the top of the app's detail page, above the download button's fold. Meant for setup steps a user needs to know before they tap install, not general app description — that's what description/localizedDescription are for.

Compatibility warnings — requires_trollstore / requires_jailbreak

Both default to false if omitted. If either is true, Cocosign shows an orange warning banner on the detail page explaining the app can't be installed through a normal sideload.

If both are true, Cocosign treats it as jailbreak-required — a jailbroken device is a strict superset of what TrollStore needs, so that's the more accurate/severe warning to show. This is purely informational: Cocosign does not block the download/install action, it just warns the user up front instead of them finding out after a failed install.

Developer link — developer_url

Distinct from the repo-level website field — this is the app developer's own link (GitHub, personal site, socials), not the repo's. If set, the "Developer" row in the Information section becomes tappable and opens this URL; if not set, it's shown as a plain text row same as today.

Tags — tags

An array of short, freeform strings, shown as a row of small chips right under the version/size pills near the top of the detail page. Cocosign doesn't validate or normalize casing/spelling, so keep them consistent within your own repo.

Not currently wired into the app-list category filter — that still uses the standard category field. Tags are detail-page-only for now.

Full example repo

A complete, realistic repo document — standard AltStore-format fields plus every Cocosign-specific field from above, all in one place. Copy it as a starting point and swap in your own values.

Only name, apps, and each app's bundleIdentifier/name/version/downloadURL are truly required — everything else (repo-level branding, screenshots, and all the Cocosign-specific fields) is optional. Delete whatever you don't need.

This list grows over time as new Cocosign-specific fields ship — every one of them will stay optional and additive, so a repo you publish today keeps working unchanged as new fields are added.

Cocosign registers the custom URL scheme cocosignapp://, which lets your website (or any other app) trigger specific actions inside Cocosign directly — for example, an "Add to Cocosign" button on a repo's page.

If Cocosign isn't installed, links using this scheme will silently fail to open — that's standard behavior for custom URL schemes (no universal-link fallback today), so don't rely on it as the only way to reach a page/action. See the fallback pattern below.

Add a Source / Repo

Two equivalent ways to open Cocosign and add a repo.

Path-style

The repo URL is appended directly after /source/, not percent-encoded — it must be a well-formed https:// URL starting immediately after the marker.

Query-param style

The repo URL goes in the url query parameter and must be percent-encoded.

Both forms do the exact same thing. The query-param form is generally safer to build programmatically since it handles encoding via a standard URL library instead of string concatenation.

Install an App

Same rules as the path-style source link: the IPA's direct download URL is appended after /install/, not percent-encoded, and must start with https://. Starts a download inside Cocosign; the user completes signing/installing from there.

Copy a Shared Cloud Library App

Opens Cocosign's Cloud Library "Copy from Link" sheet with the share ID already filled in — the user just confirms (and enters a password if the shared app is protected). id accepts either a bare share ID or a full cococloud-signing.vip/<shareId> share URL, percent-encoded if you pass the full URL.

Copying a shared app is a Pro feature — if the user's account isn't eligible, they'll see the same error inside the sheet they'd get from the in-app flow.

Save a CocoCloud API Key

Saves a CocoCloud Signing API key directly into Cocosign — useful for an "Open in Cocosign" button on your API key dashboard so the user doesn't have to copy-paste it manually. The key is written to the device Keychain immediately and a confirmation alert is shown.

Security note: this puts the key in a URL, which browsers can retain in history. Only surface this link from a one-time "reveal/copy key" action, not a page a user might bookmark or share.

Don't have a key yet? Create one and import it into Cocosign in a single tap — unlocks Cloud Library, Sources, and automatic access to the newest enterprise certificate. Create API Key

Open a Community Repo

Opens a specific repo's detail page in the Community Repos browser, using its identifier (a stable string like vip.cococloud-signing.repo.1.16, not the numeric ID). If the identifier doesn't match anything, the user sees a "repo not found" alert.

Open a Specific Tab

Switches Cocosign directly to one of its tabs. Valid values for <tab>:

On iPhone (or any compact-width layout), the Certificates tab is hidden from the tab bar regardless of this link — cocosignapp://open/certificates will simply have no visible effect there.

Building a link on your site

Plain anchor tags work — no JavaScript needed. Include the Cocosign icon so the button is instantly recognizable:

Make sure the url value is percent-encoded when using the query-param form (e.g. via encodeURIComponent() in JS) — an unencoded URL containing characters like & or ? will break the query string. Hotlinking the icon URL above is fine, or download and host your own copy.

Rendered example

Add to Cocosign

"App not installed" fallback

Custom URL schemes have no way to detect success or fall back automatically. The standard pattern: attempt the cocosignapp:// link, start a ~1–2s JS timer, and if the page is still visible when it fires (nothing intercepted the navigation), redirect to the install page. Without this, a user without the app installed just sees nothing happen.

Not part of this scheme

Opening a downloaded .ipa/.tipa file directly (e.g. tapping one in Files or Safari) is handled separately, through the app's registered document types — not through cocosignapp://. No link is needed for that; it's automatic once Cocosign is installed.