Hah, no worries, such things happen to me regularly 🙂
The MonoGame setup is pretty similar to libGDX (a Java based thing like MonoGame). In libGDX, the file reading/writing APIs are abstracted across platforms, so we don't need to do anything special on desktop, iOS, and Android. It's all the same method. E.g. you'd do something like:
SkeletonJson().read(Gdx.files.internal("skeleton.json")
The respective backend (desktop, iOS, Android) would implement the actual internal() method and look the file up in the appropriate place.
For the MonoGame (or C# runtime in general), the abstraction is different. The constructor of classes requiring a file will take various (stream) readers, and the call-site (i.e. you 😃) are responsible to open that reader in the platform specific way. I'd love to have an abstraction like in libGDX for MonoGame, but it seems that's not easily achieved.
In your case, I'd strongly suggest not to have per-platform SkeletonJson/Atlas implementations, but instead create a small utility class that can return a reader for a file. You can then override the methods of that file i/o class per platform (single class with platform specific #ifdefs, or simple interface -> implementation hierarchy). When creating a SkeletonJson/Atlas, call the file i/o utility with some path, and it will magically return a reader constructed using the platform mechanism for file i/o.
This way, you can update the Spine Runtimes without having to backport your derrived classes all the time.
Anyways, thanks for all your feedback!
