Releasing

Release checklist

Step-by-step process for shipping content to mobile apps.

Before you start

Make sure you have at least the CONTENT role (for creating snapshots) or DEV role (for the full workflow including schema changes).

1. Verify content

  • Check statement counts per schema type – do the numbers match what you expect?
  • Verify translations are complete for all target locales (check the Translations tab for missing entries)
  • Confirm all statements that should be active are marked active
  • Review platform visibility flags – are the right statements hidden on iOS/Android?

2. Check category filters

  • For each category, click the test button to preview which statements match
  • Verify the matched statement count makes sense
  • Check that no category is empty (0 matches) unless intentional
  • Remember: filters are resolved at snapshot time, so what you see in the test is what the snapshot will contain

3. Create snapshot

  1. Go to Release Manager → Create Snapshot
  2. Select the target app
  3. Add a descriptive comment (e.g., “v1.3 content: 50 new party questions, updated translations”)
  4. Click Generate to build the payload

4. Preview and verify

After generation, check:

  • Category count matches expected
  • Statement count matches expected (may differ from total active statements if some aren’t matched by any category filter)
  • Locale list includes all languages you need
  • Review validation warnings – statements with invalid metadata are excluded from the snapshot
  • Payload byte size is reasonable (compare to previous snapshots)

5. Publish

  1. Move the snapshot from Draft → Ready
  2. Do a final review
  3. Move from Ready → Published

The snapshot is now immutable and available to the client API.

6. Create or update version mapping

Go to the App Releases tab:

For a new app version:

  1. Click Create Release
  2. Select the app, enter the new version (e.g., 1.3.0), select the published snapshot
  3. All app builds at version 1.3.0+ will receive this content (until a higher version mapping exists)

For an existing app version (content update):

  1. Find the existing version mapping
  2. Edit it to point to the new published snapshot
  3. The change takes effect after the Redis cache expires (up to 4 hours) or for new requests not yet cached

7. Verify via API

Test that the content is accessible through the client API:

  1. Make a signed request to GET /v1/categories with the target app’s bundle ID and version
  2. Check the X-Resolved-Version header – does it match your expectation?
  3. Decrypt the response and verify category names and statement counts
  4. Spot-check a few statements via GET /v1/statements?categoryId=...

Updating content for an existing app version

If you need to update content without releasing a new app version:

  1. Create a new snapshot (the old one is immutable)
  2. Generate, review, and publish it
  3. Update the existing version mapping to point to the new snapshot
  4. Cached responses will serve the old content for up to 4 hours

Rolling back

If something is wrong with a release:

  1. Go to App Releases
  2. Edit the version mapping for the affected version
  3. Point it back to the previous published snapshot
  4. The rollback takes effect after cache expiry (up to 4 hours)

Published snapshots are never deleted, so you can always roll back to any previously published snapshot.

Multiple apps, same content update

If you have multiple apps sharing the same schema type and you’ve updated shared statements:

  1. Create and publish a new snapshot for each app separately
  2. Update version mappings for each app
  3. Each app can be on a different snapshot schedule – they’re independent