Name the places images live.
A placement is a stable key such as travel.coast, with a screen and an intended size. An engineer registers it once and keeps a bundled fallback in the app.
From then on, anyone with console access can fill it.
Update your app’s images
without an app release.
Connect the image placements your team changes often. Publish optimized artwork, see it in the running app, and restore an earlier release when needed.
Developer preview for Expo and web, with Swift and Kotlin SDK previews. The first integration requires an app release.
A release process for the images in your app.
Three screens from the console, as it runs today. Engineers define the contract once; designers and product managers publish within it.
Publish a signed release.
Assign an image to a placement, write a note, publish. The console prepares an optimized WebP and signs a manifest that the SDK verifies before anything is shown.
Drafts stay private until you publish.
Keep a way back.
Every release stays in history. Restore an earlier one and connected apps receive it on their next refresh, as a new release number.
An image that any placement or release still references cannot be archived.
Try it in a demo app.
Roam and Daylight are small open-source Expo apps we built to exercise the SDK. They run live on this page. Open one, then connect your workspace to publish an image.
Travel demo
Roam
A small Expo app for saving weekend places. Two of its images are connected to Assetlib placements. Change the destination artwork from your workspace and watch it update here.
No account needed to explore. Connect your workspace to publish an image.Connected placement:
travel.coastA few lines in your app. The rest stays yours.
The SDK gives each placement a generated, typed reference. Layout, behavior, and the bundled fallback stay in your code.
import { parsePublicConfig } from '@assetlib/sdk-core';
import { createExpoAssetClient, AssetlibImage } from '@assetlib/sdk-expo';
import { AppAssets } from './assets.generated';
const client = createExpoAssetClient(parsePublicConfig(publicConfig));
await client.initialize();
await client.refresh();
<AssetlibImage
client={client}
asset={AppAssets.Travel.coast}
fallback={require('./assets/coast.png')}
pixelWidth={600}
pixelHeight={450}
contentFit="cover"
style={{ width: '100%', aspectRatio: 4 / 3 }}
/>From the SDK readme. This is the integration the travel demo uses.
- Typed referencesA checked-in catalog generates
AppAssets.Travel.coast. Compatible artwork updates keep the reference; renames are a migration. - Verified deliveryManifests are signed with Ed25519 and image bytes are checked against SHA-256 before use. The public key is pinned in your app.
- Fallback and cacheA bundled image ships with the app. The SDK serves a verified cached image or that fallback whenever delivery fails.
- PlatformsExpo for iOS, Android, and web, with Swift and Kotlin SDK previews. Validate native delivery in your own app before relying on it.
What you can use today.
This is a developer preview. We would rather you know the edges than discover them.
Available now
- Hosted workspaces with GitHub sign-in
- Image upload and WebP optimization
- Named placements with size contracts
- Signed releases, rollback, and guarded archival
- Expo and web SDK, open source under MIT
- Verified publish and rollback in the hosted travel demo
Planned
- Native device validation for the Swift and Kotlin previews
- Figma sync and per-placement renditions
- Usage telemetry and stale-asset evidence
- Experiment integrations
- Billing and production operations
Before you add another SDK.
The questions engineers ask first.
What does Assetlib change in my app?
Images in the places you connect to the SDK: a destination photo, an onboarding illustration, or a promotional banner. Your app keeps its layout and behavior. New screens, launcher icons, and system launch screens still need app development.
Can I try it before integrating anything?
Yes. Open either demo in your browser, with no account required. To publish your own artwork, create an Assetlib workspace using GitHub sign-in and paste its public configuration into the demo. Both apps are open source and already include the SDK.
What needs an engineer?
The first integration: choosing image placements, defining their dimensions, adding bundled fallbacks, and shipping the SDK in an app release. After that, compatible images can be published from the console. New placements or SDK changes may need another app release.
When does the app receive an update?
The app checks for a signed release and downloads images as their screens need them. In the demos, use Check for updates to request the latest release. An offline device receives new artwork after it reconnects and refreshes.
What happens if delivery fails?
The SDK uses a verified cached image or the fallback bundled in the app. You can restore an earlier release from the console; the app receives that rollback on its next successful refresh.
How is this different from EAS Update or a CMS?
EAS Update ships whole JavaScript bundles and is driven by engineers. A CMS manages content, not named image slots with size contracts and native fallbacks. Assetlib is narrower: a signed, versioned release process for the images already inside your app, with a typed reference per placement.
Start with one image change.
Open the travel demo, connect a workspace, and publish a different image. Then restore the original.