Looking for a Sprite Kit Game Engine? Check out Kobold Kit!

In case you missed the news: Sprite Kit is Apple’s 2D rendering engine for games, announced with iOS 7 at WWDC 2013 by merely mentioning it among other new APIs. A small step for Apple, a giant leap for gamedeveloperkind. This changes everything!

Many compare Sprite Kit with cocos2d-iphone. Don’t ask me why, they just do. 😉

If you’re a registered Apple developer you can check out the Sprite Kit Programming Guide and the SpriteKit.framework reference yourself.

Sprite Kit is under NDA, like the rest of iOS 7, so I won’t spell out any details here. I posted my list of strengths and weaknesses of Sprite Kit on the developer forum, where we can freely discuss such details.

Here let me just try to answer the questions: why did Apple create Sprite Kit, and why now?

The Biggie: Apple acknowledges games!

Apple finally understands the significance of games for their platforms! Sprite Kit is acknowledgement of that fact. Rejoice!

Especially if you consider the rumored Apple TV set: imagine a television set that runs iOS with an App Store to download and buy YOUR games. Interestingly, iOS 7 also adds an API for 3rd party game controllers, think of joypads, like those you get with an Xbox or Playstation.

Combine it all: Apple’s television device, an App Store, and game controllers and – tadaaa – you get Apple’s competitor to Xbox One and Playstation 4!

For Apple the influx of Indies is great, they don’t care about established business models, so they don’t have to lock out the indies from a closed platform to keep the big publishers happy which simply don’t want to compete with their AAA million $ budget titles with garage games.

The great thing for Apple is that within the mass there’ll always be a few outstanding, innovative, marketable, sales-driving titles being delivered, and incidentally won’t be available on any other platform.

If the Apple TV also turns out to be technically capable enough and manages to gain acceptance by big game publishers as a competitive gaming device for AAA titles, then Microsoft, Sony and especially Nintendo will have a big problem.

Hardware & Software Compatibility

I believe this is one of the main reasons why Apple needed to make sure Sprite Kit exists, because it will work with any new Apple hardware from day one. Existing Sprite Kit games published by then will likely be very easy to port to “iTV” and whatever other devices are coming.

And you will not have any compatibility problems with new software releases either, Sprite Kit will work flawlessly with new versions of Xcode, iOS, OS X, and whatever other software Apple changes. It doesn’t happen too often either and comes with prior notice and lots of time to adapt.

For cocos2d-iphone it regularly took several months to adapt to SDK changes and to add support for new devices and for these compatibility issues finding their way into an official (stable) release.

Particularly off-putting is that cocos2d still labels released with “stable” vs “unstable”, yet the meaning is frequently lost while the stable version doesn’t work with current technology, but the unstable version does.

I’m glad we won’t be having any of these issues with Sprite Kit.

Dependable API

Despite cocos2d-iphone not having added any significant feature for years, it was constantly being changed. Practically every new version introduced some changes that forced developers to change their code.

The individual refactoring choices of the past years were mostly good ones, and appreciated, but delivering them incrementally among other things instead of doing one complete overhaul is just annoying for a publicly serviced game engine. It’s tiring and frustrating.

Now consider that Sprite Kit will largely remain as is. If you expect Sprite Kit to improve frequently, think again. What you see now is the near final API, and it will likely be 90% of what Sprite Kit will be 3 years from now.

This is a good thing! It means the half-life of knowledge, tutorials and books will increase, perhaps tremendously so. I’m thinking from perhaps 3-9 months up to 1-3 years or more! This makes it easier to pick up on Sprite Kit, and developers are even more likely to service it by writing tutorials, answering questions, building support frameworks, etc.

Stay native, dammit!

Sprite Kit is Apple telling developers to use their native APIs, and now in particular for games. Cool 2D games only available on iOS, ideally those only possible on iOS is what Apple wants to see from us.

Apple knows how loyal developers are to their platform – just as much as the users of Apple devices and systems – so Sprite Kit is an investment in a growing game developer base.

Now Cocos2d-iphone still is currently the most popular, iOS-only game engine – but in recent years Zynga pulled it towards cross-platform with a Javascript extension and shifted development focus towards cocos2d-x. This is neither in the interest of the cocos2d-iphone users, nor can I imagine Apple being happy about the most popular iOS engine being diluted with cross-platform developments.

Sprite Kit is Apple’s way of reassuring, convincing and funneling game developers to stick to iOS and OS X. It is Apple taking control over how game developers create games for Apple devices and computers. Meaning: elegantly and efficiently, but also “locked-in” with no source code.

There are still reasons for using other game engines, but this is now a desire only shared by hardcore programmers. Not the ones Apple is targeting with Sprite Kit.

If you still want to be able to port your Sprite Kit game to Android, there’s Apportable. No doubt they’ll chime in quickly to make their service compatible with Sprite Kit, especially since Sprite Kit will be a ubiquitous and stationary target.

So why now? Doesn’t make sense now, right?

Why now? Well perhaps Apple felt Zynga is pulling the rug right out from under them ever since they started directing cocos2d’s development (sometime in 2010-2011). Sprite Kit could have come earlier but I guess cocos2d’s shift towards cross-platform had to happen first.

That and acknowledging how important games are for iOS and how instrumental it was for iOS’ success – ironically that’s something Apple might not have been so quick to accept under Steve Jobs.

The other thing is Apple having this TV device in their pipeline that would greatly benefit from a native rendering engine, especially if it means many existing games can be ported easily and considering that it will compete with Xbox One, Playstation 4 and Wii U. Then consider how long it might have taken cocos2d-iphone to deliver Apple TV support, if at all.

The timing makes a lot of sense. Apple isn’t here to do us a service – that’s just a neat and desirable side effect we happen to benefit from. They aren’t evil either. Now is simply the time for Sprite Kit because Apple is preparing to innovate on a new market (TV & game consoles), for the first time since 2007, and success in that market depends on games to a large degree.

Sprite Kit and the time of its release are nothing but pragmatism. This I love about the post-Jobs Apple.

Cocos2d, not nearly as beginner-friendly as it could be

How cocos2d became known to be beginner-friendly is because originally it could only be compared with OpenGL. In that case, yes, far easier than OpenGL, undisputed.

If you’ve been working with other game engines in the past, you know the cocos2d API leaves a lot to be desired, and there are far easier, more elegant ones out there. I see cocos2d developers struggle with the exact same issues or concepts nearly every day – many are the same ones I faced back in 2009. Concise, consistent and complete documentation does not exist anywhere, and new user experience varies greatly depending on what and who they learn from. That’s just sad.

Sprite Kit is beginner-friendly. It has the typical well-designed, trimmed, sleak API you’d expect from Apple. It’s got excellent documentation that’ll stay up to date and is complete.

But the greatest benefits are in the things you don’t really need to consider anymore. Things that Sprite Kit takes care of for you. Things many beginning cocos2d developer isn’t aware or capable of, or interested in doing – those are the tasks a truly beginner-friendly framework takes over from the user. That’s what Sprite Kit does.

Apple started with a clean slate and took great care in designing the Sprite Kit API. Everything falls together as neatly as possible. I’m heavily impressed, and convinced that Sprite Kit is to cocos2d-iphone what ARC is to manual reference counting.

The Stepping Stone Theory

Don’t get your hopes up that Sprite Kit will be a stepping-stone for a coming generation of cocos2d developers “upgrading” from Sprite Kit.

Anyone who will have started with Sprite Kit and then tries out cocos2d will find it confusing, inconsistent, archaic, badly documented, unnecessarily complex and requiring a lot more dreadful handiwork. This is not an upgrade, it’s a step backwards.

As iOS 7 adoption reaches the 90% mark there will be little reason to stick with cocos2d-iphone. We’ve seen cocos2d-iphone rise slowly to ubiquity in the past 5 years, it may only take 5 months for it to become a legacy project. In a relatively short time the great majority of cocos2d-iphone will have moved on, to Sprite Kit, to cocos2d-x, or elsewhere.

The only way for cocos2d-iphone to stay relevant is to focus on the strengths it has over Sprite Kit while adapting Sprite Kit’s convenience. It would be huge time investment, and not getting paid to do this makes it highly unlikely.

What about 3D games?

Sprite Kit, as the name implies, is 2D only. So why not 3D?

Because that field is really not for beginners – and this goes both ways: Apple developers and Apple’s developers. 3D renderers will immediately compete and be compared with Unity or Unreal technologies and their excellent tool chains. It’s extremely hard to compete with them from scratch, even (or especially) for Apple who are new to the game development field and not that interested in it either.

And let’s be honest: there aren’t that many great 3D apps on either App Store – especially not from indies. The 3D games I remember the most are from id Software, Epic, Ubisoft and EA.

I wager that 80% of iOS games are 2D and even among the 3D games, few are truly 3D in that you can actually move in 3 dimensions. 3D games are a factor of three dimensions more difficult, more expensive and time consuming to create. 3D games are notoriously hard to make visually appealing, especially when compared to an alternative 2D version of the same game.

2D games have had a renaissance since the introduction of the iPhone in 2007. TV sets and newer mobile devices aren’t going to end that trend. 3D games are dominated by big game developers and publishers, it’s one way they can distinguish themselves most easily from Indie productions.

Sprite Kit Adoption

With Apple implementing a rendering engine for games, everyone is going to adopt Sprite Kit and in a short time there’ll be more Sprite Kit experts and code add-ons and tools than there ever were cocos2d experts and code add-ons and tools.

Zynga isn’t in it for making a great game engine, for them the engine is as a means to their end to efficiently develop cross-platform games with technology they own (or at least control). So they’re unlikely to chime in and support cocos2d-iphone or a Sprite Kit based engine.

Given the usual iOS adoption rate and the growth of new iOS device sales most developers will inevitably cut support for iOS 6 in 2014. So the backwards compatibility issue is (once again) not going to be an argument for long.

Programming-oriented game developers will then have these choices: use Sprite Kit and go entirely Apple-native with all the goodies (Objective-C, ARC, native APIs) or saddle an elderly cocos2d-iphone horse in “maintenance mode”. What will you choose to do a year from now?

The alternative: bite the bullet and develop cross-platform – either using overpowered 3D technologies like Unity or Unreal, using a low-level and cumbersome C/C++ game engine or one using Javascript or Lua with severe performance penalties.

I believe the choice to use Sprite Kit will be rather obvious for many, especially with Sprite Kit being an “Apple product” and inevitably surrounded by a host of contributing software and tools. Which brings me to my last point.

Kobold Kit: the Sprite Kit game engine!

I started working on Kobold Kit, a game engine built on and extending Sprite Kit! The upcoming KoboldTouch 7.0 will use Kobold Kit as its rendering engine in place of cocos2d-iphone.

Kobold Kit will be available the day iOS 7 is released. KoboldTouch 7.0 should be available the same day or very soon after that. Needless to say, KoboldTouch 6.x will continue to evolve and be supported and work with iOS 7 and will continue to use cocos2d-iphone.

I know one thing with conviction: Kobold Kit is a once-in-a-lifetime opportunity to build something great, it has to be done, and I want to do it like nothing else. If there was ever one thing I was deeply and utterly convinced of, this is it! Having built two engines on top of cocos2d-iphone, I’m so glad to get the chance to start from a clean slate and apply everything I’ve learned while avoiding all the nasty things I had to do to conform to cocos2d and being able to do the things I just couldn’t do with cocos2d.

More details for registered Apple developers here.

This article was brought to you by ...

I very much enjoy the learning process, the pushing of boundaries (mine and yours and that of technology), having the freedom to pursue whatever is on my mind, to boldly program what no one has programmed before, and to write about what I've learned. Help me help you by browsing the products in the Learn Cocos2D Store.

49 Responses to “Why Apple Created Sprite Kit And What It Means For Cocos2D”

  1. Kim Pedersen says:

    Hi Steffen,

    This is a very nice write-up. I fully agree with a lot of your points and while I have enjoyed working with Cocos2d-iphone for many years I will be moving to SpriteKit for my next game. Why? Because I like what I have seen in SK so far wrt API and especially the easy physics and effects build right in – and I generally like to stick to Apple’s own frameworks as they tend to utilize the hardware to the best extend possible.

    I am not sure I agree with your comments on 3D rendering though. Yes, it is not as easy as 2d and yes you really have to know a lot of OpenGL ES and math to really make it work. But take a look at SceneKit on OS X. It is actually extremely easy to use and it really takes away a lot of the 3D pain. I was really hoping that Apple would have put SceneKit on iOS for iOS 7 but that was not the case .. too bad :) But have you played with SceneKit? OK, it is not Unity3D but in most cases Unity3D would be overkill for simple 3D games – and you have to move away from Obj-C and learn a new language (unless you already know JS or C# that is) plus all the Unity3D specifics (tools and API). Therefore, I think something like SceneKit would be excellent to get more 3D games on the AppStore – even simple ones :)

    • Honestly, I just discovered Scene Kit this week. I was surprised I had not heard of it for a whole year. Perhaps indicative of how important it is to developers?

      I want something like Unity, but for 2D games using Sprite Kit and using Objective-C and with a (fairly priced) full source code option. That would be awesome! Perhaps one day Kobold Kit will get there …

      • Kim Pedersen says:

        I think the reason it is not better know by developers is that it is a OS X exclusive at the moment. I would argue that most developers targeting Apple platforms go for iOS and ignore the Mac part (at least – I have). I do not think it is indicative of the importance of SceneKit. I am pretty sure we will see SceneKit on iOS at some point for several reasons: Apple is focusing on making the development of Apps across iOS and OS X – Similar frameworks and OS X development moving towards a more similar way of working as iOS etc. Second, the easier it is to develop for a platform the more developers you will get. As it stands now, 3D game programming for iOS has a high barrier of entry due to the need for good understanding of math and OpenGL ES/GLSL programming. This barrier of entry can be brought significantly down by introducing SceneKit on iOS as SceneKit “hides” most of the advanced 3D stuff – but still makes OpenGL ES and GLSL accessible for the more advanced 3d programmers.

  2. IKonrad says:

    So KoboldKit will be working along with existing cocos2d projects as well? And obviously that would be cocos2d 2.0 version right? Which opengl will it support? There are too many questions and debts, i’d appreciate an FAQ or something.

    • Kobold Kit / Sprite Kit are not compatible with cocos2d-iphone. They can’t be combined. Can’t do a FAQ, Sprite Kit is under NDA until iOS 7 is out. Check the iOS 7 prerelease documentation, accessible via the developer portal.

  3. jack says:

    Great post! Looking forward to see the new Kobold Kit

  4. Alexander Damhuis says:

    Hello Steffen,

    as already wrote on twitter ! I could not more agree with you and I am excited that you look at things the way you describe it here – the future of Koboldtouch could be really great by being an early adopter.

    With all the changes you will probably have to make the next months – does “using SpriteKit as view” mean that we could in theory work with KT and when you are ready just “switch” ?

    I mean as long as we did not “hack” into the Cocos2d View/Nodes but only used your APIs?

    That would be very interesting to know for me, since I am currently in the middle of moving from prototype to a real project and I would consider to wait for KoboldKit if a switch will break everything.


    • KT 6.0 and KT 7.0 / Kobold Kit will not be compatible, that much I can say by now. I’m starting from a clean slate, it’s as if Apple handed me this opportunity on a silver plate. All the things I had to work around cocos2d to make it interfere as little as possible are gone.

      For example I can now just hook the controller and model onto the node, and make them descendants of the node itself yet you’ll still be subclassing the model/controller/behavior and not the node. The cool thing being as in KT that you can move the code from one node to another. At the same time for those who are so used to cocos2d’s way of subclassing nodes, this will still be possible, and the controllers and models are still there for you to use them if you want to. This covers all the coding styles, and they’re not mutually exclusive so you can mix and match.

  5. Kyle Newsome says:

    Thanks for writing this. After reading over the docs of SpriteKit one of my first thoughts was ‘What will this mean for Kobold?’. Glad to hear you are already working on a toolkit.

  6. deeeds says:

    Everything you say in this I’m 110% in agreement with. And then some.

    But… can I ask a favour?

    Can you explain how input is handled in Sprite Kit?


    Over here, behind the NDA wall, if you would be so kind, good sir!


  7. Opus says:

    This is a game changer indeed! I didn’t think you could publish to Android, but if you can than it definately makes it more attractive for game developers.

  8. Tom says:

    Hi Steffen,

    I read this article and your post on the Apple Dev Forum.
    Kobold Kit sure sounds like a sweet set of additions to Sprite Kit.
    I was wondering if there is somewhere a sort of comparison table between your projects: features, scope, relationships, etc.

    Right now I find somehow hard to remember the differences between:
    – Kobold 2D,
    – Kobold Touch,
    – Kobold Kit

    I understand KT6 uses CC2D as rendering engine, and KT7 will shift to KoboldKit… but a clear explanation would be awesome!


    • Consider Kobold2D deprecated. I’ll make a final update with cocos2d 2.1 and then that’s it.

      Kobold Touch puts an MVC framework around cocos2d. KT 6.0 is still supported and maintained to ensure developers can complete their current projects.

      Kobold Kit (KT 7.0) will take most of Kobold Touch’s code and everything I’ve learned from making it and re-applies it. I’m actually glad that there’s no source code for SK, so I know exactly where the boundaries are, what’s possible and what isn’t. With cocos2d it was always very tempting to go in and change things, but I tried hard to never ever have to do it because those changes break with nearly every update. Plus users changing the code themselves could easily and utterly break the connection with Kobold Touch, which is why it’s designed the way it is in order to make it the least breakable, and allow cocos2d to interfere as little as possible. It’s a great relieve that this problem just went “poof”! It also opens up new possibilities, a new direction that I had originally considered but ultimately dismissed, which is adding the controllers and models to the nodes themselves.

      • Tom says:

        I see. Thanks.

        Will you also benchmark cocos2d against SpriteKit?
        I really liked your past benchmarks about NSMutableArray Vs CCArray, or the “creation costs” of classes like CCNode, CCSprite, NSObject, etc…

        • deeeds says:

          Yeah, I second and third this. And tests on all manner of approaches to doing things in Sprite Kit.

          Would happily sponsor you with some drinks to help you get through this.

        • Synthetic tests would be doable (ie number of batched sprites drawn) but the significane of synthetic tests is often overstated and misleading.

          “Fast enough” is good for me. If in theory you can draw 20% more sprites or less is irrelevant. When you start a project with one engine, you’re locked in. If the engine (or your code) doesn’t perform to expectations, you scale down or, at worst and very rarely, you have to scrap the concept entirely.

          The more interesting part will be the new best practices for Sprite Kit. Things we still need to discover, for example how autobatching works in detail and how a single batched call can be split into two, for example by adding a different node to a specific place in the hierarchy. And whether there’s a workaround, like moving non-batched nodes to their own branch of the tree. How does autobatching take zPosition, child order, grandchildren, and so on into consideration.

  9. Andy says:

    How can Kobold Kit supplement an APPLE FRAMEWORK? It doesn’t seem to make sense.
    In my mind, cocos2d WAS the missing framework that Apple didn’t create.
    Now with SpriteKit, the framework exists, so cocos2d is not needed anymore….
    I can understand an instruction book on how to USE SpriteKit.
    Or helpful tips. Additional documentation.

    But what software are you going to WRITE that will supplement an Apple Framework? Am I missing Something? Please explain.

  10. Andy says:

    Let me clarify. Because I am really curious about this.
    Cocos2d WAS like the missing SpriteKit framework but it was OPEN SOURCE…..
    So you improved on cocos2d with Kobold2D. OK Awesome.
    But SpriteKit is NOT open source.
    How are you going to improve on it?
    Documentation would be spectacular., I would actually buy your product just for the documentation alone.
    But how are you intending to improve on a closed-source Apple-protected framework?

    • We build all the great software based on Apple’s closed source frameworks. Why does that rule out building on, extending and improving the framework(s)? With categories and method swizzling you can do a lot. Both Kobold2D and Kobold Touch include practically no code modifications to cocos2d, perhaps 10 lines tops.

      Cocos2d is still useful if your game has certain requirements. I can’t make comparisons to SK because it might indicate what’s in or missing from SK which would be a breach of NDA.

      Suffice it to say, cocos2d is not perfect, and developers have been extending and improving Apple frameworks or individual modules and classes since ever. You don’t need the source code to build something better on something that’s already good, especially if that thing lacks in breadth and specialization.

      • Andy says:

        I guess I’ll wait and see. Very interesting and best of luck. You have undertaken quite a task here.
        But the rewards could be astronomical if you are successful.
        Good luck.

  11. Tony says:

    Would certainly be following your work on spritekit. Have followed your teachings on cocos2d for a few years now.
    Cocos2d seems an little lost at the moment. Riq has followed the wrong path IMO, can’t be doing with coding wrappers, but apportable may just keep me for the moment.
    I agree with your comments on needing the source code. I originally made a lot of changes but they have all but gone now and I have over 100k lines of source.
    What I’m excited about is how similar Sk is to cocos2d. If there is not hit on performance, then it’s a no brainer to migrate.
    Looking forward to your wisdom Steffen.

  12. […] 21/06/2013: hemos encontrado un post de LearnCocos2D.com mucho más extenso tratando este mismo tema por si queréis ampliar […]

  13. […] about Apple’s Sprite Kit launch, games developer Steffen Itterheim notes that, in possessing its own framework, Apple can make sure developers don’t suffer through […]

  14. BaSha says:

    Hi, thank you so much for this information. and what about Box2d? can we make use of it with spriteKit?

    • Well, it’s like with UIKit. It isn’t integrated but you can make it work. After all you really only need to apply a body’s position & rotation to make it work with any view.

  15. […] Two weeks ago I blogged about Why Apple Created Sprite Kit and What It Means For Cocos2D. […]

  16. Quan says:

    So Cocos2D-iphone will not be able to compete with SpritKit.
    What do you think about Cocos2D-x ?

    • It may be able to compete IF it can build on the unique features Sprite Kit can’t offer and also offer an upgrade path. That means copying the Sprite Kit API and behavior.
      Sprite Kit is initially missing some features but we’re already seeing any gaps closed by the developers, such as tilemap support.

      What do I think of cocos2d-x … I have no use for it, and I’d hate to have to program in C++ in a really weird (Objective-C) way. I really never felt the desire to give it a try in the first place. It’s got its place but for cross-platorm development there are many viable alternatives.

      • Benny says:

        Hi Steffen,

        I thought your original root is from C++. C++ also enjoys wide and extensive support from the community.

        • My root, hmmm. Definitely not C++, that came later. I started with C very early, also some AmigaBasic. I grasped most programming concepts with scripting languages actually. Proprietary, Python and most importantly Lua. I always preferred C# over C++ too. And now Objective-C.

          C++ is a much more difficult language to learn, and even more difficult to master, than most other high level languages (including C).

  17. Jake says:

    Looks very interesting. Will the ad networks such as revmob and chartboost integrate into the new Kobold Kit easily? Look forward to having a play around with it once officially released.

  18. Steve says:

    Hi Steffen, Very convincing post… I have not yet looked at Sprite Kit, but will do now. So far I was working with cocos2d + box2d with TexturePacker and Physics Editor. Do you know if I will be able to use Texture Packer&Physics Editor (by Andreas Löw: http://www.codeandweb.com) with Sprite Kit?

    • Yes, Andreas’ tools (TexturePacker, PhysicsEditor), Mike’s tools (Particle Designer, Glyph Designer) and probably most other popular tools will work with Sprite Kit and Kobold Kit.

  19. Stefan says:

    So the september keynote happened without a single word on controller support, Apple TV or any plans for consoles. I am not sure if Apple has any further intentions in this field. Maybe SpriteKit is what it is, a framework for 2D games. Due to the imense pupularity of the iOS platform Apple can still earn enough _without_ investing in a completely new field (tv and consoles). The most sensible thing for Apple to do is not what we deem sensible but what Apple thinks is right. And their track record proves that they can focus on few things and execute them very well.
    It is a pitty though. An Apple TV combo would kick ass and further deepen the gamification trend that has increased lately. Even the most casual of gamers could be hooked when suddenly controlls don’t suck and the game is displayed on a big screen.

    • Controller support is simply not too important to mention in a media event. Apple barely even mentioned Sprite Kit in the WWDC keynote. Apple TV set was always rumoured to be announced not before way into 2014. So there’s nothing unusual happening. 😉

  20. […] ile Sprite Kit karşılaştırılır durumda. Bu konuda  Steffen Itterheim ‘in yorumuna buradan […]