Hi,

I bought Spine few days ago and it's a great editor. Very high quality.
I can't say the same for the cocos2d-runtime though.
I know the runtimes are still under heavy development and that's why I'd like to suggest a few points to improve the cocos2d one.

I'm an experienced Objective-C and Cocos2d programmer (4+ years) and I know very well how long it takes to get used to Objective-C and its design patterns. Especially if you come from C/C++, you tend to write classes the "C++ way" which is suboptimal in the iOS/OS X world.

So, please, don't take any offense with this post, I'm just trying to "guide" you towards a cleaner and more useful interface for the cocos2d-runtime. I'm not going to talk about the internal implementation of Spine-c because that's not my business.

Points I think you should really consider for the next refactoring:

Both class and instance methods need to follow Apple guidelines in regard to naming conventions
Class methods that return instances (basically factory methods) should always return "id" and not a strong type (all the "create:" methods in this case). If you don't do that, then it's very hard to subclass your class
All relevant data that is supposed to be accessed should be exposed through properties. This is very important: doing something like _skeleton->state->time in ObjC is really really bad. It breaks encapsulation and a thousand other conventions. You should have a @property (nonatomic, readwrite/readonly) for each of this data and return ObjC types and not C types (don't return const char *, but return NSString *)
Delegation pattern: it's probably the main design pattern used on iOS/OS X and every ObjC programmer is expecting this in a class like CCSkeleton. I'd like to be notified when an animation ends or when it loops over or when an event occurs... all these things must be implemented through a delegation pattern
Expose the main features of the spine-c in the CCSkeleton interface. If there's a setAnimation method, there should also be a stopAnimation

Those are my main suggestions.
I understand you're writing many runtimes at the same time and you're probably overwhelmed, but I strongly disagree with you when you say that writing a complete ObjC wrapper is not worth it.
I think it's exactly the opposite: you have a professional tool like Spine which is supported by a poorly written runtime (at least the Cocos2d one), and this doesn't make any sense at all. Games require a lot of features when handling animations (stop/pause/events/blending...) and these must be implemented in the runtime.

Thanks for reading this long post!

Marco