SEB It is possible to pack the images for each skin into a specific texture atlas page, but the skin information itself cannot be exported separately and is always bound to a single skeleton data. In other words, in the usual way, all atlas texture page images associated with a skeleton are loaded when that skeleton is loaded.

If you are concerned about load times for a skeleton with a large number of skins, we recommend using Spine Addressables Extensions. This module covers all necessary steps to automatically replace your textures with low-resolution placeholder textures and loading the high-resolution textures upon request. The textures are automatically replaced with the low-resolution texture when building your game executable via a pre-build step (and reset to the high-resolution textures afterwards in the post-build step). It requires no additional coding and is easy to use, so please give it a try.

SEB To reduce memory consumption, you can reduce draw calls by using the Skin.GetRepackedSkin() method, which allows you to combine used texture regions of a collected skin to a single texture at runtime. See the Runtime Repacking section of the documentation for more information:
https://esotericsoftware.com/spine-unity-main-components#Runtime-Repacking

Please also have a look at the example scenes as recommended in the documentation.: Spine Examples/Other Examples/Mix and Match and Spine Examples/Other Examples/Mix and Match Equip.

SEB Thanks for the clarification. As mentioned before, it is possible to pack each texture atlas page for each skin. However, this does not mean that the textures can only be loaded when the skin is applied. Since Unity loads all indirectly referenced assets, indirectly referenced by the SkeletonDataAsset, which references the Atlas asset, which references all atlas pages as materials with the atlas texture page texture. Thus, by default, all exported textures are referenced and thus loaded by Unity when the skeleton is used in a Unity scene.

To dynamically load only the atlas for the selected skin, using Addressables is the recommended approach. This allows you to manage memory effectively by loading and unloading textures as needed.

SEB

You can read more about our Texture Packer here. In the example, the same skeleton's textures are packed first into a single sprite; then into two separate sprites, once per skin.

But as Misaki said, even if you pack skins into different sprites, the atlas text file (the one that ends with .atlas) will hold references to all the sprites. This implies that once the .atlas file is loaded, all sprites are loaded too.

Addressables provides a strategy to have a better control on sprite loading.

SEB Since you seem to be trying to understand the exact information, let me correct you on a minor detail.
In Spine, we do not usually refer to them as "skin sprites". The packed images used in the skeleton are called atlas “page images”.
If you simply say "atlas", it would be confusing with a text file with the .atlas extension. Since only one text file with the extension .atlas is exported per skeleton or multiple skeletons, it is not split per page image. Rather, it serves as a guide to identify the split page images as all being for a single skeleton.
Putting these together, your following sentence would be correct if you had said "texture atlas", but incorrect if you just said atlas, because it looks as if you are splitting a text file:

Skin sprites can be packed on different atlas

The following sentence should likewise say "texture atlas", not simply "atlas".

Using Addressable Extension those atlas can be loaded on-demand

If what you were imagining in your head was a texture atlas, then your understanding is correct.

If the terminology is not consistent, we will inevitably need this extra explanation of what each other stands for, and I think it is a good idea to read the user guide again carefully, as Davide recommended.

If memory consumption becomes a problem after testing, feel free to ask us again.