Skip to content
assetlib

Questions

What can EAS Update change, and why didn't my image update?

EAS Update replaces the JavaScript bundle and the assets that bundle references, for installed apps whose runtime version matches the update. It cannot change native code, native dependencies, app icons, splash screens, or anything in the native project; those need a new build through the stores. When an image does not change after an update, the usual causes are a runtime version mismatch, an asset that kept the same content hash, a renamed asset the updater treated as already present, or a client that rolled back to its embedded bundle after a failed launch.

Updated October 9, 2026 · Assetlib

01

Is it only the JSX, or are npm packages included?

JavaScript and TypeScript, styling, and image or font assets required from that code are included. A JavaScript-only npm package is included too, because it compiles into the bundle. A package with native code is not; if it adds or changes native modules, the runtime version should change and the app needs a new build. Expo's own rule of thumb is that anything you would see in the native project in Xcode or Android Studio needs a build. The Expo documentation on runtime versions is the reference.

02

Why is my new or renamed image not shown after the OTA update?

Reported causes, from the Expo issue tracker and forums:

  • Runtime version mismatch. The update was published for a runtime the installed app does not have, so the app never downloads it. Check the runtime version embedded in the build against the one on the update.
  • Same content, different name. Assets are tracked by content hash. An image renamed without changing its bytes has been reported as skipped by the updater, so the new reference points at a file the client never fetched (expo/expo#44526, expo/expo#45527).
  • Rollback to the embedded bundle. If the updated bundle fails on launch, the client falls back to the bundle shipped in the build, and with it the old images (expo/eas-cli#1750).
  • Density variants not all shipped. Apps that only ship some of the 1x, 2x, and 3x variants can render blank images in release builds when the requested scale is missing (expo/expo#46878).

03

When is a separate image release workflow the better fit?

When the people who change images are not the people who run builds. EAS Update is an engineering tool: someone runs a command, a pipeline builds the bundle, and the update ships everything that changed, code and images together. If a designer or product owner changes a banner every week, each change is a ticket, a pipeline run, and an engineer's time.

Assetlib takes the images out of that path. An engineer connects a placement once, with a bundled fallback. After that, images and Lottie animations publish from a console to that placement, with release history and restore per placement, and the installed app picks them up on its next refresh. Each image is addressed by its content hash, so a replaced image is never skipped as unchanged or hidden behind a cached copy with the same filename. The same workflow covers SwiftUI and Jetpack Compose, where there is no OTA path for assets at all. The Expo SDK is a developer preview; the integration guide covers the first placement, and the source is on GitHub.

Keep EAS Update for code. Use both if you like; they do not conflict.