SpriteKit is Apple’s native game development engine for the iOS platform. We here compare its features with those of Cocos2D – a third-party framework which is also extensively used for creating mobile games.

Among the third-party game development frameworks available prior to the launch of iOS 7, Cocos2D was easily the most popular. The arrival of Apple’s very own game development tool, SpriteKit, has changed the equation somewhat though – with many iOS app developers preferring to use it. Customized for the creation of 2D/2.5D games, SpriteKit has emerged as a serious challenger to Cocos2D – as far as the debate for the best game development engine on the iOS platform is concerned. We here compare the two, on the basis of multiple key parameters:

1. The learning curve – Nothing much to choose here. Getting the hang of Cocos2D and SpriteKit is fairly simple, and working with either of the frameworks does not require any advanced programming knowhow. Easy-to-understand ‘Methods’ are generated from the low-level APIs included in both the tools. If one were to really nitpick, SpriteKit, with its built-in Physics simulation, is just a tad more user-friendly. App developers need to use Chipmunk/Box2D on the Cocos2D tool for the same simulation purpose.
2. Texture generation and management – With the release of iOS 8, Apple has upgraded SpriteKit big time. While the texture management system in Cocos2D is sound enough, SpriteKit offers more options for making custom textures from raw pixel files, pictures, and sound textures. For creating iOS games, developers often need to use a wide variety of textures (including those from map editors), and SpriteKit comes across as the more resourceful tool for that.
3. Using Particle Editors – This round would go in favor of SpriteKit too. Since there are no particle editors embedded in the Cocos2D framework, iPhone game developers have to first create particles with an external application, and then modify its behavior with the ‘CCParticleExplosion’ method. SKEmitter, in SpriteKit, does away with all such complex tasks . Particles can be added to the game development project in Xcode by following these steps: New → File → Resource → SpriteKit Particle File. After the particle type is chosen, two separate files are directly created in Xcode.
4. Using Lights in 2D games – Both Cocos2D as well as SpriteKit allow mobile app development experts to add customized light effects to their 2D games, to add a touch of realism to the latter. The CCLightNode class is an integral part of Cocos2D – and although there is a section of developers that feels that it needs some more work – it serves the purpose of adding light effects to game projects well enough. The counterpart of CCLightNode in Cocos2D is SpriteKit’s SKLightNode (yet another iOS 8 addition to the tool). Both the classes are equally good, and they provide more than enough features as well.
5. Open Source vs Closed Source – A big #win factor in favor of Cocos2D. The third-party framework is open source (unlike SpriteKit), has been available for game developers for far longer (the first release was in early-2008), and it is constantly updated (v.0.6.0 was launched about a year ago). Thanks to the availability of the paid Apportable support, Cocos2D can be used on the Android platform as well. Since SpriteKit is closed source, it lacks the same level of flexibility. What’s more, it can be used for developing games only on iOS 7 and iOS 8. If a game has to be made compatible with the earlier versions of Apple’s mobile platform as well, Cocos2D would be the go-to tool for developers.
6. Labels and Sprites – The methods are different, but adding sprites (mostly images) and label objects (mostly text) is almost equally simple on SpriteKit and Cocos2D. With SKSpriteNode (in SpriteKit) and CCSprite (in Cocos2D), a vast range of effects – right from rotations and frames, to scales and positions – can be created and displayed. Coders have to use SKSpriteNode* and CCSprite* to implement sprite objects in SpriteKit and Cocos2D respectively. For label objects too, developers can use either SKLabelNode in SpriteKit, or CCLabelTTF in Cocos2D to show text, and add attributes to it (like color, size, position, etc.). Comparatively speaking, this is a tie between the two game development frameworks.
7. Overall performance – SpriteKit is a native iOS tool while Cocos2D is a third-party framework – hence it is hardly surprising that the performance of the former is a couple of notches higher than that of the latter. Of course, the new feature additions in Cocos2D do negate some of this advantage, and for cross-platform mobile game development, it is obviously the preferred tool. However, if we concentrate on the native performance of the two tools on the iOS platform only, SpriteKit is better.
8. Working with Scenes – Most app and game developers feel that Cocos2D offers a more intuitive scene-creation and management option than SpriteKit. The reason for this is simple enough – on SpriteKit, two different classes (SKScene and SKView) have to be managed. In the Cocos2D framework, a single class – CCScene – has to be called. This makes things just a bit easier for coders, particularly those who are working on large projects.
9. Atlas creation – SpriteKit comes with automatic built-in support for the creation of atlases (alternatively known as sprite sheets). While working with the Spine animation tool, developers get the ‘Create Atlas’ option – and the .atlas file contains all the information about the smaller image files (in essence, the atlas is a large image file that is made up of several smaller picture units). There is no similar way to group the same type of graphic files together in Cocos2D. As a result, Cocos2D games might have memory-related issues – a risk that is not present in SpriteKit games.
10. Shaders – Till the launch of iOS 8, the lack of shaders and camera effects used to be a major drawback in SpriteKit. Apple has addressed this issue now, with the new SKShader class in the tool. It can be used to add shades with lights in game scenarios, to lend a more interactive feel. The updated CCShader class in Cocos2D performs the same task – and to be fair – the shaders generated by it are more or less at par with Apple’s tool. Another stalemate between the two engines.
11. Implementation of transitions – The slide/scene transition properties of Cocos2D are fair enough, but they do come up short when compared to the transition options in SpriteKit. doorwayWithDuration, doorsCloseHorizontalWithDuration and doorsOpenVerticalWithDuration are some of the transition effects that iOS game development professionals often use to personalize their 2D/2.5D game projects. In Cocos2D, the transition options are relatively limited.
12. Including sound effects – While working on either mobile games or multimedia applications, custom sounds have to be included by developers. Doing this is simpler in the SpriteKit environment. All that coders have to do is call SKAction* soundAction = [ ]; On the other hand, in Cocos2D, two steps are required to call audio files in the project. First, the ‘SimpleAudioEngine’ header has to be called (with #import). Then, the [[SimpleAudioEngine sharedEngine] command lines are used to include music/sound effects. There are no qualitative differences in the audio effects – but adding them is just a shade easier in SpriteKit.
13. Menu creation – Most game developers opine that the menu-creation procedure in Cocos2D is less complex than doing the same thing in SpriteKit. The latter, in fact, does not have any designated object for creating menus in game scenarios – and coders have to declare separate event handlers on objects. In the third-party Cocos2D tool though, the CCMenu and the CCMenuItem objects are present for the creation and display of custom menus. There are less chances of errors cropping up while adding menus in Cocos2D.
14. Adding Actions – Another point where both the game development engines have almost equal merits. The Action class in Cocos2D and the SKAction class in SpriteKit are both easy to implement, although the total number of effects (from even nodes and sprites) available is slightly more in SpriteKit. Countering this fact is the larger number of classes in the Cocos2D framework. For practically every type of action, there are methods available in each tool. None of them offers any clear advantage over the other.

When SpriteKit was initially released by Apple, the lead developer of Cocos2D – Ricardo Quesada – had referred to its features as better than that of Cocos2D. The built-in physics integration had also come in for special praise. For native iOS development, SpriteKit definitely holds the edge over Cocos2D. The latter, however, has several high points of its own, and is backed by a larger online community support. It’s a close fight between the two tools, with SpriteKit being ahead by a whisker.

Which game engine do you use – SpriteKit or Cocos2D?