iOS build target? If so, turn off compression on the texture.
It would also help if you enabled the wireframe. The option is on the upper left of Scene view.

Select the .png file in project view. Your Inspector should show the import options for that png/texture. Make sure it's not compressed.
I think it should say "Truecolor" or something.

The limitation here is that iOS build target does not support compressed, not-POT, non-square textures.
So you either have to make the texture a POT-square, or disable compression. For sprites, disabling compression is the go-to option anyway.

Are you new to Unity?

Try setting the MaxSize to 4096 in the Unity texture settings, Unity might be reducing the texture size from its original.

If it is, you may want to scale down your texture sheet manually in Spine

Again, could you tell the dev to turn on wireframes so we can actually see what's going on?
Also just to cover our bases, the dev has a screenshot with the default tab open. Can we make sure the iOS tab isn't overriding those settings?

It's probably nothing, But it's strange that the texture atlas looks like that with those gaping holes.
Spine's TexturePacker usually packs everything to the left. I know the shadows are there, but that still seems like a lot of space for it.

I suspect it's not the texture size. If you see Mlesna's export settings, the max is currently set to 1024.

If you also want other people to try it out in Unity, you could share the exported files here in the forums. If you worry about it being stolen, you could repaint/recolor the exported atlas png or draw squiggles on them.

It was a file naming problem.
You had both a .atlas file (new version) and a .atlas.txt (old version). The runtime was using the old atlas with the new png so it had the wrong coordinates for the regions.

The Spine-Unity runtime seemed to fail to detect that you had two atlas files. (one extended .atlas.txt, and the other extended .atlas).
We can assume the first time you exported the atlas that Unity detected the .atlas file and automatically renamed it .atlas.txt. But after that, I think it just broke, as the case where it detects both ".atlas" and ".atlas.txt" hasn't been handled yet. Or has it? I haven't actually gone through the importer code myself.

USER SOLUTION:
Just delete all previous exports. Export a new set of files, and in Spine's Create Atlas/Texture Packer settings, change the atlas extension from ".atlas" to ".atlas.txt".
You shouldn't be getting this problem any more after that.

Note to the animator and the programmer:
Spine exports 3 files. A png, a json, and a .atlas (.atlas.txt for compatibility).
Spine-Unity's importer generates 3 more files (though not 100% true, think of them as having a 1:1 correspondence with the original Spine exports): a Material for the image. an AtlasAsset for the atlas, and a SkeletonDataAsset for the json.

That makes a total of 6 files with any regular set of Spine assets. Any more and you should be suspicious if you didn't have some kind of special setup. I know it just turns into a jumble of files most of the time. But it's handy when you need to figure out what broke.

Last tip:
You should trim/crop your Shadow.png image to remove the empty transparent areas.
That's extra work the GPU doesn't need to do, and wasted space in your atlas.

why does this happen when i export my file as JSON/ATLAS file? what do you think is wrong with my export?
the PNGs should be compressed without huge spaces between them? insted of exporting only 2 pages of PNG along my Json and atlas files?

Did you remove those spaces from your original images?
Ideally, that's the first step.
If you weren't using meshes, you can enable strip whitespace in the texture packing options. But note this can cause rendering errors otherwise.

thanks for the reply, I just found out that the clothing i placed was exported without using "LAYERS TO PNG" and was done with exporting using photoshop only. thats why every clothing took the whole canvas space.