How do I change an image in my app without users updating the app?
Serve the image from a URL the app already loads, instead of bundling it. The simplest version is to overwrite the file at the same URL; the better version is to give the app a small manifest that says which image each screen should show now, so a changed image gets a new URL and the old one can be restored. Either way the first version of the app that reads from a URL still ships through the store. Every change after that does not.
01
Why does the app still show the old picture after I replaced the file?
Because image loaders cache by URL. If the new image has the same name and therefore the same link, the device, a CDN, or both will keep serving the copy they already have. The usual fixes are a cache-busting query string, a short cache lifetime, or a new filename for every version. Each fix moves the problem: a query string defeats the CDN cache you wanted, a short lifetime means more downloads, and a new filename for every version means something has to tell the app the new name.
That last option is the right one. Address each image by its content, give the app one small file that maps each screen's image slot to the current content address, and let that file change. Cached images stay valid forever because a given address never changes its bytes; only the map changes.
02
Can I put the image URL in Firebase Remote Config?
Yes, and many teams do. Remote Config holds a string per key; the app reads the key and loads whatever URL it finds. Three things to plan for: Remote Config fetches are throttled by a minimum fetch interval, so a change can take hours to reach a device unless you tune it; there is no built-in check that the URL still points at an image of the right size; and there is no history of which image was live when, so "put the old one back" means finding the old URL yourself. If the images are few and change rarely, this is enough.
03
Doesn't EAS Update or CodePush already do this for React Native?
For Expo apps, EAS Update ships a new JavaScript bundle and the assets it references to installed apps with a matching runtime version. If an engineer is happy to run a build and publish an update for every image change, it works. The limits are that it is an engineering operation, it covers the JavaScript side only, and the asset is still identified by its place in the bundle. What EAS Update can change, and why an image sometimes does not update goes through the reported failure modes. Microsoft's CodePush service retired in March 2025; its forks have the same shape.
04
What does a placement-based workflow add?
It separates the engineering decision, which image slots exist and what size they are, from the content decision, which image each slot shows this week. An engineer connects a slot once, with a bundled fallback for when the network is unavailable. After that, a designer or product owner publishes a replacement from a console, and the app picks it up on its next refresh. Each release is signed, each image is addressed by its content hash, and an earlier release can be restored without finding files.
This is what Assetlib does. Images and Lottie animations publish to placements your engineers connect once, with SDKs for Expo and React Native, SwiftUI, and Jetpack Compose, all MIT-licensed developer previews. The first integration ships in an app release, like every other approach on this page. New screens, layouts, and behavior still need app development. Try it against the travel demo app before changing your own: create a workspace, publish a change, and watch the demo's image swap.
05
What should I check before shipping any of these?
- Turn the network off and launch the app cold. It should show a bundled or previously cached image, never a blank.
- Replace the image, then put the old one back. Both directions should work without a new build.
- Install an older version of the app and confirm it still gets an image it can display.
- Decide who is allowed to publish, and whether a second person must approve before production.