How Releaseyour.App works

Everything in Releaseyour.App hangs off an organization. An organization holds your apps, their store assets, localizations and releases — and it is the unit your plan, your seats and your permissions attach to.

Your first sign-in lands you on onboarding: give the organization a name and a slug (derived from the name, rename-stable afterwards) and the workspace exists. If you were invited before you signed up, the pending invitations are shown on the same screen and accepted straight from there.

There is no limit on how many organizations you join. Each one keeps its own apps, members and subscription, and you switch between them from the header or the workspaces page.

Add each app once. Name, bundle identifier and platform are enough to start; everything else — assets, store copy, releases — hangs off that record rather than off a folder somewhere.

Each app moves through an explicit lifecycle: draft, in review, live, retired. The app overview shows the strip with the current stage highlighted, so the state of an app is answerable at a glance instead of inferred from filenames.

If the app is already published, link it instead of retyping it. Linking a Play Store app searches Google's store and records the live listing; linking an App Store app goes through Apple's public lookup API. Either way the name and icon are re-read from the store at link time, and 'Sync latest from store' pulls the current listing and version back into the record whenever you need it.

Artwork lives against the app, grouped the way a store review reads it: icons, feature graphics, then screenshots. Every upload is versioned per app, attributable to the person who made it, and kept — an earlier version is never overwritten, so the icon you shipped in March is still one click away in December.

Uploads go direct to storage with background processing behind them, so dragging in a full screenshot set does not tie up a request while the bytes move. Device class, pixel dimensions and version number are recorded as each file lands.

The icon generator takes one square master and renders it into every App Store, Play and browser size by name. It flattens transparency to white — the rule both stores reject you over — never upscales past the master, and tells you which target sizes are still missing rather than quietly returning something blurry.

Stores want screenshots at exact device classes — phone, 7-inch tablet, 10-inch tablet — and the gap that only shows up at review is the tablet set nobody took. The screenshot studio tracks those classes as explicit slots, so a missing size is visible before the release is, not after the rejection email.

Resizing and conversion happen in your browser. The image never leaves your machine to be processed; only the finished files are uploaded, already at the right size for the slot they are headed to.

The slot list is derived from the requirements for each store, so the studio shows exactly what is required for the app you are preparing rather than a generic checklist.

Store copy is held per language, side by side: title, subtitle, keywords and description for each locale you publish in. Because the languages sit next to each other, a missing translation is a visible gap in a table rather than a surprise in a store console.

Each save is versioned, so a listing rewritten the night before submission can be read back the morning after.

Placeholders are checked, not trusted. If your source locale uses a token like {price} or {app_name}, every other locale is validated against it — a translation that dropped the token is flagged before release, because a description that ships with a literal brace in it is a support ticket you find too late.

The release center is where the previous steps are proved. A stage strip shows where the release is, and a readiness checklist shows what is still missing — computed from the actual assets, copy and notes on the app, not from a checkbox somebody ticked months ago.

Because the checklist is derived, it cannot drift out of date: upload a screenshot and the line it was blocking turns green on the next render. The same computation is re-run inside the submit action, so a release cannot be pushed through by racing a stale page.

Releases are deep-linkable with ?release=<id>, which makes the exact state you were looking at shareable with the person who has to fix it.

Release notes are kept per release and per language, and the list of languages is taken from your listing copy — you can only write notes for the locales you actually publish.

They sit with the release rather than in a document somewhere, so the text that ships with version 3.2 is reviewable alongside the assets and checklist it belongs to.

The Team page is members and invitations for the active organization: who is in, what role they hold, what invites are outstanding. Roles decide what a person can do — approving a release, deleting an app and managing billing are not open to everyone by default.

Settings covers the organization (name and slug) and your own profile. The account page holds the personal side: profile, security, notifications and API keys. Workspaces lists every organization you belong to and is where you start a new one.

Basic includes a 30-day card-backed free trial, then costs $8.99 per workspace per month. Team is $49 per workspace per month and lifts the caps — more apps, more seats, more screenshots per app. Enterprise is sold by contract and adds SSO, a custom SLA and a dedicated account manager.

Limits are enforced server-side from a single catalogue, so the number on the pricing page is the number the application applies. Billing runs through Dodo Payments as merchant of record; the billing page shows current status, and the plans page spells out what each tier includes.