Moving a reply from email to here. The question was: When do we plan to support dynamic texture loading for iOS?
Our APIs make it possible to manage textures however it's needed. For our most popular runtimes, like spine-unity, we provide more game toolkit specific functionality, since it helps such a large number of people. While we'd love to provide all of what spine-unity can do to all runtimes, we don't have short term plans to do it for spine-ios. Even with Unity you still have a fair amount of app specific work to do.
You could consider changing to Unity to use the utilities provided there. Otherwise you could implement it yourself, possibly using spine-unity as a guide. Basically, skeleton data is decoupled from textures. You can load the data without loading any textures.
First you decide which attachments your skeleton will use. To support thousands of attachments, you probably want to use templates in the Spine editor, then at runtime duplicate the templates and customize them to use images based on naming conventions. Eg, hat-red.png would duplicate the hat template and assign the hat-red.png texture region from an atlas (though we haven't loaded images yet). This means you don't need to rig thousands of hats in the editor. You rig one, then replace it with images -- adding new attachments is just adding new images.
You'll need to do the bookkeeping to know what images are available and which template they correspond to. Consider that some attachments may use multiple images. Eg, a shirt could have 2 sleeves and a torso. This bookkeeping is pretty app specific, so isn't something we can provide for you.
Once your skeleton has the attachments you want, you need to determine what are all the images you need to render it. Likely you already know the image each attachment needs, but you may need to consider which animations you will play, since animations can show new attachments. You could even download the images at this point, if you don't ship them all with the app.
Next you pack all those attachments into a texture atlas. spine-unity can pack for you, or you can look at its code. There are many ways to pack, eg libgdx provides a FOSS texture packer (NB, I wrote it, and it's similar to what Spine uses). Once packed, you can use the atlas to render your skeleton efficiently. For each attachment, you assign a texture region in the atlas. This must be done before rendering, of course.
In this way you can have an unlimited number of attachments and still render the outfitted skeleton efficiently. I don't think spine-ios lacking a few utility functions is a big blocker for doing this.
If you don't need to scale your number of attachments into outer space, then you can use a simpler approach. Maybe you don't use templates and just rig in the editor. Maybe you don't pack at runtime. Even if you have more images than fit on a single atlas page, atlas pages can be organized so a skeleton requires just a few draw calls, even a dozen or more could fine.
