I have opened this thread to discuss the features of a cocos2d-pureswift version. Please feel free to chip in with both positives and negatives.
The benefits of making a pureswift version, would be to get a native cross platform version of cocos2d, build on the absolutely latest in programming languages.
The drawbacks would be, that we would have to start from scratch, and that pureswift for some time would lack behind.
Would be to create at least a 0.9 version, within a 6-9 month time frame.
So how do we do this?
The key to building a true cross platform Cocos2D-PureSwift, is to isolate anything OS / hardware specific, from the basic API. As Swift is a non platform specific language (unlike ObjC), and with the language going open source later this year, it will only be a matter of time before we see Swift compilers for Android.
The main problem for ObjC cross platform support, has been to build the runtime / GCD for other platforms. This is an almost impossible task because the user is in no way or form restricted in accessing any of this, and because Apple can and will change anything, at any time. While it certainly is possible to compile iOS for Android, as a full cross platform API, it has proven to be very fragile.
Swift on the other hand, would be extremely robust. With OS / hardware isolated in thin wrappers, access to platform specific functionality would now be controlled through the API, and not by the user. This makes all the difference.
The two main problems I see, will be performance and time schedule. The later is a flexible thing, and as all aspects of the API are well documented and understood, I would not worry too much. It would still be something to watch closely though. Which leaves us with performance.
Swift is currently in development, so there might be performance issues. In the long run I am not worried, but for a 0.9, we might run into problems.
However, there is nothing stopping us from moving time critical code from the basic API, to the platform specific code of the thin wrappers.
Cocos2D-PureSwift main design
As cocos2d should always be heavily focused on user support, and the users ability to customize the API, the most important thing to keep in mind would be to keep the core engine simple and transparent.
Classes should be well isolated, and easy to understand.
It should be very easy to expand on classes.
Data driven design
Any class should support loading and storing from data structures. This includes anything from setting up device resolutions, to loading entire scenes.
I do not know how well the SpriteBuilder format is documented, but that would certainly be an option.
Full native support
Full access to native functionality like openGL, or whatever the platform you are working on provides, meaning ex. full ability to override any part of the render engine, for custom usage.
A modular design scheme should be implemented, allowing specialised functionality to be moved away from the core classes. This could be anything from advanced layout functionality, to automatic render batching.
Resolution free design
Design should be completely independent on device resolution, unless the designer specifically wants otherwise. In resolution free design, only aspect ratio would matter. The user should be able to set up more of such viewports, to allow for running ex. gameplay and HUD in different resolutions.
One size fits all
Only one set of assets would be required for all devices, unless the designer specifically wants something else. We also need a much easier and more transparent way of loading assets. Full interchangeability between folders and sprite sheets, and automatic placeholder artwork for missing files.
The core will not support multithreading, but will support synchronised access of classes from other threads. This could ex. be controlling sprites from a free running AI or animation thread. Also, the resource handling system will support async access, like creating textures in different threads.
Sprites will natively support multi pass rendering, and rendering to off screen surfaces, even if added to a visible node chain.
Replace fillrate with bandwidth
Cut down number of pixels rendered, by breaking sprites into smaller pieces.
Simpler and more flexible action system, with the ability to easily override transfer function. Camera node. Faster and more flexible scheduling.
And finally. What are these thin wrappers?
Thin wrappers is a simple and well proven way of isolating OS and hardware from an API. Imagine the NSUserData in iOS. To use that for cross platform, we would have to build a CCUserData class, which basically just called NSUserData. Many of the calls would be 1:1. The implementation of CCUserData would be compiled for iOS, and provided as a link library.
For Android, a similar implementation of CCUserData would then be made.
More complicated classes like an image class, would require a little more glue and interface, but all the heavy lifting would still be in the OS specific calls.
As always, let me know what you think, and please dont hesitate to ask if anything is unclear. I am not the best at explaining things.
Some comments can also be found here