Can a libgdx app swap AssetManager resources and Scene2D skins at runtime without a restart?

Yes — a running libgdx app can swap atlases and skins without restarting, but the safe sequence is: load the new assets fully, re-point every actor's style, and only then unload the old atlas. The two traps are disposing too early (one frame of missing textures) and assuming a reloaded Skin propagates to existing widgets (it does not).

The ordering that avoids missing textures

1. Call assetManager.load("ui-new.atlas", TextureAtlas.class) and load("skin-new.json", Skin.class) (with a SkinParameter pointing at the new atlas if the skin JSON references it).
2. Keep calling assetManager.update() from your render() method each frame until it returns true for the new assets. Do not touch the stage yet.
3. On the frame where loading is complete, build the new Skin (or fetch it via assetManager.get()) and walk the stage, reassigning styles: button.setStyle(newSkin.get("default", TextButton.TextButtonStyle.class)), and so on for every widget type you use. Actors that cache TextureRegion or Drawable references directly (custom widgets, Image built from a region) must be given the new regions explicitly or recreated.
4. Only after every actor has been re-styled or replaced, call assetManager.unload("ui-old.atlas"). AssetManager is reference-counted: if the old skin was loaded through the same manager, unloading the skin plus atlas releases the textures once nothing else references them.

Because the swap of styles happens inside a single render pass, the user never sees an intermediate frame: the old textures are still alive while the new ones are assigned, and disposal happens afterwards.

Skin reload does not propagate to existing actors

This is the confirmed behavior, not a guess: Scene2D widgets copy their style object at construction or setStyle time. Replacing the Skin instance — or even mutating the skin in place — does not update widgets that already hold the old TextButtonStyle, LabelStyle, etc. Every existing widget must be re-styled or rebuilt. Newly created widgets that pull styles from the new skin will look correct automatically, which is why a partial swap often looks like it works until you notice stale screens.

A practical pattern is to keep a registry of style consumers (or rebuild the current screen's root table from a layout method) so the re-skin step is one loop rather than ad-hoc fixes per widget.

Threading

AssetManager.load() may be called from any thread, but update() and finishLoading() must run on the render thread — that is where GL texture uploads happen. The style reassignment and stage rebuild must also happen on the render thread, since Scene2D is not thread-safe. If your upgrade arrives via a network callback on another thread, hand it off with Gdx.app.postRunnable() and do the whole swap (steps 3–4) inside that runnable or at the top of the next render().

1.11.x vs 1.12.x

There are no AssetManager, Skin, or Stage API changes between 1.11.x and 1.12.x that alter this workflow; the same sequence applies to both. (Verify against the 1.12.x changelog before shipping, since this is based on the stable API surface rather than a live check of the latest release.)

Verification checklist

• Trigger the swap in a debug build and confirm every visible widget changes appearance in the same frame — no flicker, no white/missing regions.
• After unload(), check assetManager.getReferenceCount("ui-old.atlas") is zero and no "texture disposed" warnings appear when old screens are reopened — a stale region reference will surface as a crash or black quad.
• Force a slow load (large atlas or artificial delay) to confirm the UI keeps rendering the old skin correctly until update() reports completion.