Cocos2D: A Blessing and a Curse

Our feature this week is from Alejandro Reyero, one of our Dad developers based in Spain. Alejandro runs a company called Todo Jeugos, and writes about how he started to develop mobile apps on Apple’s iOS. He shares his experience about using Cocos2D, a game engine for apps on the iPhone, iPad, or iPod touch. If there are other developers reading this who have experience with Cocos2D, we invite you to leave a comment to build out the conversation with your own opinions.

What would the iPhone-indie-game-developers’ world be without Cocos2D?

I am the owner of, a prominent gaming news website based in Spain. As a game critic for more than 13 years, I always wanted to make my own games.

I decided to make an app using my experience and resources in the gaming world, which is how “Achievements & Trophies” was born (an app to connect to PlayStation Network and Xbox Live to see your games, friends and achievements). I launched it initially on Android because of my experience in Java and the development tools were free. I planned a port to iOS hoping to find a nice development environment and a rich ecosystem. The ecosystem is great, but what a letdown using XCode and Objective-C.  After years of Eclipse and Visual Studio, developing in XCode was like going back to vi (ok, I know that’s an exaggeration, but you get the point). And don’t make me start with Objective-C (no garbage collector for iOS, really?). I made a partial port of the app while learning about provisioning, interface builder, and Memory Leak Finder tools, reminding me of Purify on a Solaris.

The Blessing

During a conversation with my close colleague about mobile phones and tablets, we thought about making a game for our children. Apple’s iOS was not an option for me at the beginning. Making a game was hard enough, and my experience with Java and Android was much more substantial. Then I started to look for Android 2D frameworks, and found almost nothing free, full-featured, and with a great community. Making a 2D engine from scratch, even with a very limited set of features, was ambitious. I tried some samples for Cocos2D (Ray Wenderlich – his tutorials are a heaven-sent) and was amazed. The engine is easy to learn, the API made a lot of sense, and the community and samples are GREAT. I was able to make a prototype of the puzzle and match games in just one week, with a very little experience in Objective-C.

The more I explored Cocos2D, the more impressed I became. Do you want to access the photo library? No problem, here is your example. But, accessing the photo Library on an iPad doesn’t work! No problem, use a UIPopoverController to display your UIImagePickerController like this. Every problem that I faced was already resolved by someone in StackOverflow or in Cocos2D forums, what else could I ask for?

In the development of my children’s game, Sage Kids, I only faced two issues of minor annoyance: iPad support and API version upgrades.

Cocos 2D has a great support for Retina Display. From version 0.99.5, you make high resolution assets and Cocos2D uses them depending on the device, with the coordinate system automatically translated for you. Everything that you move, or position, on a Retina Display is translated with zero effort in non-retina devices. In my source code there is not a single line of code that refers to Retina Display, other than the one to enable its support.

iPad support is more troublesome. I understand that the aspect ratio is different from the iPhone, and that an automated system that works 100% is not possible. But at least have something that uses Retina assets and adjusts to the iPad screen for apps that don’t need pixel perfect translations. Having your code full of “if iPad do this if not do that” is ugly and the maintenance is a nightmare.

The API version upgrades is not 100% hassle-free either. The documentation of changes between versions is not as complete as should be, and the process of migration is basically “remove old API directory. Add new one. Compile. Pray.” Backwards compatibility is not assured (not that I have a problem with that, but the amount of source code of Sage Kids is not as big as other projects out there) – so keep that in mind.

The Curse

I have a problem nowadays: I don’t know how to “live” without Cocos2D. I want to migrate Sage Kids to Android and Windows Phone 7, but I don’t know where to start. There is a project to migrate Cocos2D to Android, but right now it’s not really usable.

Develop my own little Engine? Yeah, right, I’d rather make another game with Cocos2D for iPhone in less than half the time it would take me to have a version of Sage Kids in Android.

So there you have it: Being an indie developer is easy with these tools and frameworks, but once you try it, it’s tough to live without it.

11 Replies to “Cocos2D: A Blessing and a Curse”

  1. Hi Alejandro, thanks for the interesting blog post. I can certainly understand what you mean. You mention the curse of totally relying on Cocos2D and also mention that it’s not practical to write your own graphics engine. For me, I try to strike a balance.

    I basically use Cocos2D as a graphics delivery engine and that’s it. In other words, I only use it to create sprites and display them on the screen. I don’t use any of their transitioning, camera, retina tools, etc. I write everything else myself using my own code libraries. This way I’m only “married” to the bare bones features of Cocos2D (which are the same generic features that any graphics engine would provide)


  2. Alejandro, I read your article with great interest. I followed a similar path in my development: from obj-c/XCode to Cocos2D and got stuck with similar issues. One in particular for me was maintaining a landscape rotation when a movie completed playing , which combines subview root controller code; and porting to other devices. I found a solution that is taking the pain out of programming, Corona SDK. As for porting to popular iOS & Android devices, it just scales the assets to conform to the device. Only drawback is that it is not free. You have to pay an annual subscription fee, but for me it is worth it.

  3. XCode is okay but I can’t stand IB. I do most of the coding in a text editor and then pull it into XCode to test, debug, and package.

    Obj-C is really no worse than using C or C++ although I’m wary of using it for most of my own code because most libs are so tightly tied to Apple. Like using Cocos2D it really ties you to that platform. The lack of garbage collection really annoys me too as I hate messing up clean logic with a bunch of gc code. I’d like it to be easier to make Mac OS ports of apps too but even that is difficult as many libs aren’t on OS X and iOS both. That seems a bit silly.

    Even with a couple different screen possibilities working with iOS isn’t near as much work in that area as Android.

    I’ve experimented some with tools for translating Android apps to iOS and such but none are very polished.

    I’ve experimented with writing my own Python-like language designed from the ground up with writing mobile apps and games and having it output code for Android, iOS, etc and that seems a better way forward but it’s probably to much for one person to keep up with. I’m not a fan of Java or Obj-C though so I’ll probably keep working on my own language. Leave the details to the compiler.

  4. Hi, this is Alejandro, the author of this post.

    I know about cocos2d for Android, the version in google code is a little bit updated and not very usable.
    Cocos2D-X looks good, but you have to deal with the NDK directly, and you know what that means:

    Mike, you idea about a Python-like language looks great, you should take a look at Wax, a framework to write iPhone apps in LUA:

    For me, a dream, would be to have Visual Studio 2010 and C# and develop for iPhone (best IDE, modern language), but if you go the Mono Touch route you risk being left outside if Mono project ends or Apple changes it’s mind about allowing apps done in Mono.

  5. Alejandro,
    take a look at, a game engine comparable to Cocos2D based on OpenGL. You can download a sample application showing all the features from the market (Sprites, Multitouch, Box2D-Integration etc.). The documentation is still rare but you can learn from the forums tutorials and from the samples sourcecode. Programming is entirely done in Java (usually using Eclipse).

  6. I’ve been working lately with a new programming language called “Monkey”. It uses basic syntax and is object oriented. The nice thing about it though is that you write your code once and it will create projects for any platform you choose, iOS, Windows, Mac,Android, HTML5, Flash and XNA. The speed is not bad either because it creates customized functions for each platform. Its 120 bucks and the site is
    This kind of route might be a way for you to solve your issue with relying on one toolkit that is only tailored to a specific platform. Cheers.

  7. I’ve been playing with E3Droid for Android (Java based) and found it to be very easy to work with. I can’t compare to Cocos2D since I haven’t used that library, but some of the features of E3Droid I liked:

    Screen/Scene Management
    Javascript/Lua scripting
    TMX (Tilemap support)

    Disadvantage is that is highly based on Android. You aren’t going to make an iOS application with it.

    Which brings me to the point that I too have been playing with Monkey. It ships with an abstraction API called Mojo. The demo version of the language is a bit limited (some of the issues are fixed in the $120 version: Interfaces, yeah!). As a “low level” (think SDL / DirectX / XNA) api, Mojo is nice. However, monkey is lacking a true game library at the present time. (There are a few in development, look on the modules page for more information).

    I’ve been contemplating porting either E3Droid or Cocos2D to Monkey, but I haven’t picked a direction quite yet.

  8. I have to disagree with some of your points. First, you mention that the Android dev tools were free (suggesting that Apple’s were not.) Xcode is free, all the tools for iOS development are free. As far as no garbage collection on iOS devices, there’s a pretty simple reason for that: performance. The problem with garbage collection is that memory usage grows until it’s collected, so there might be more memory allocated than necessary. That’s bad for devices with restricted memory and no option to swap. When the garbage collector runs, it scans the heap to find memory that’s no longer being used, and that’s an expensive process, that will slow down your device until is has completed. iOS puts garbage collection into the hands of the developer, which allows the developer to optimize applications prior to compiling rather than wasting runtime resources with garbage collection. As far as your dream setup coding iOS on Visual Studio 2010 — I have to say you’re being inconsistent — Visual Studio 2010 costs $799!! You mention that Android tools were free and yet you want to use a $799 program for iOS? Visual Studio 2010 Ultimate is a $12,000 program.

  9. MikeFM,

    Did you anywhere with your new programming language?


    There is a free edition of visual studio. Tons of games are made using Lua, Python, or java on mobile… with garbage collection. The performance hit isn’t a deal breaker for most apps.

Leave a Reply

Your email address will not be published. Required fields are marked *