Connect one placement.
Verify the whole release.

Create a preview workspace.

1. Open the Assetlib console and choose Continue with GitHub. Use a GitHub account with a verified email.
2. Choose Create demo workspace, name it, then confirm Create & publish demo. Assetlib creates three image placements, adds sample artwork, and publishes the first release.
3. Choose Get SDK configuration, then Copy configuration.

The current hosted preview uses those onboarding labels and seeds three starter placements. They are a starting point; choose and register the placement you intend to use in your app.

The SDK configuration identifies your app and its verification key. It contains no password, private signing key, or admin token. Keep account credentials in the console.

Give one image a stable reference.

1. Choose a non-confidential image and define its placement key, dimensions, fit, and bundled fallback. Keep screen behavior and layout in your app.
2. Install matching SDK packages using the versioned SDK instructions. Generate typed references from a checked-in placement catalog; normal app builds do not need a network request to Assetlib.
3. Configure a client with the public SDK configuration and render the placement with its fallback. Add an explicit refresh action and inspect the selected image’s source and release number.
4. Build and run your app on its target platforms. Confirm it still displays the bundled image before a remote image is available.

The initial integration requires development and an app release. Later compatible artwork changes can be published separately. New screens, layouts, behavior, and placement contracts still require app development.

Native integrations have separate instructions: Swift SDK preview and Kotlin SDK preview. Use the documentation that matches the installed release.

Publish a different image.

Prepare a visibly different replacement that meets your placement’s dimensions and aspect ratio. Check its crop and fit in the actual component.

1. In the console’s Assets section, choose Choose image and upload a still PNG, JPEG, WebP, or a supported static SVG. Assetlib keeps the original and prepares sizes for delivery: PNG and lossless WebP for artwork, compressed WebP for photos. Web can use the normalized SVG; native apps use raster versions.
2. Open Placements. Under Draft image, assign the uploaded image to your connected placement.
3. Choose Publish release, review the confirmation, and confirm Publish release.
4. Refresh your app’s client, then open the placement’s screen. Confirm the replacement is displayed and record its release number and source.

A published release and a displayed image are separate checks. The console’s release number alone does not establish what a device has downloaded or rendered.

Raster inputs are limited to 4 MiB and 20 megapixels; SVG has additional format limits. Prepared images must fit within 1 MiB. The preview’s 8 MiB workspace storage quota includes retained originals and prepared versions. Updates need a successful refresh and download.

Restore an earlier version.

1. Open Releases in the console and find the earlier release.
2. Choose Restore this version, then confirm Restore and publish.
3. Refresh the client again and return to the placement’s screen. Confirm the earlier artwork is displayed with the new release number.

Rollback publishes the earlier content with a new release number. It preserves the release history and leaves your draft placement bindings unchanged.

Record what the app actually displays.

1. Record the installed app build, SDK version, placement key, current image, and selected release.
2. Publish a visibly different compatible image. Refresh the same running app and capture the replacement, its source, and its release number.
3. Restore the earlier version in the console. Refresh again and capture the earlier image under a newer release number.
4. Disable networking and restart the app. Confirm it renders an eligible verified cached image or its bundled fallback. Also check a fresh installation offline, where only bundled artwork is available.

Run these checks on each platform you intend to ship. Record fallback and download failures separately from successful remote delivery; a source-selection callback is not an impression or a visibility measurement.

Use the sample apps to test delivery.

Roam, the travel demo, and Daylight, the to-do demo, are small open-source apps we built with bundled artwork and the SDK already integrated. They are the same apps that run live on the homepage. They are integration references, not customer deployments.

In either demo app, open Connect, paste the console’s public JSON into Public SDK configuration, and choose Connect and check release. After publishing or restoring artwork, choose Check for updates and inspect the relevant screen.

The seeded travel.coast and travel.ridge placements use 4:3 images, such as 1200 × 900 px. The seeded tasks.garden placement uses 3:2, such as 600 × 400 px. These demo apps do not establish availability of newer local state-set or catalog features.

• SDK source and installation — typed references, signed delivery, cache, and fallback behavior.
• Travel demo source and to-do demo source — Expo integration references.
• iOS demo source — a SwiftUI integration reference.
• Android demo source — a Compose integration reference.

The MIT-licensed SDK previews are available on GitHub. Follow each repository’s installation instructions and use matching versions. JavaScript SDK packages are distributed through versioned GitHub releases. The read-only asset audit is on npm as @assetlib/audit and as the assetlib-audit plugin for Claude Code and Codex.