Update: please find the iOS Device Sales Statistics for Q1 2012 here.
Currently Cocos2D is being overhauled for a v2.0 release. It will only support OpenGL ES 2.x and thus games made with Cocos2D v2.x will not run on 1st & 2nd generation devices (iPhone, iPhone 3G, iPod Touch 1 & 2).
The two development threads in the Cocos2D forum here and here are full of users expressing their disappointment (among other emotions/criticism) not to support a rendering core that supports both GL ES 1.x and 2.x. Even though it was said that if you still need to support all devices, you can simply continue to use the Cocos2D v1.x branch.
I’ve run some numbers and came to the following conclusion: if your game only supports OpenGL ES 2.x and comes out in Q1 2012, you will lose less than 10% of customers!
Here’s why I think OpenGL ES v1.x is currently in the process of dropping dead, and close to hitting the ground within the coming ~6 months.
iPhone Sales Statistics Q1 2011
Wikipedia has a nice list of iPhone sales statistics (totals) as they were reported by Apple each quarter. These statistics range from Q3 2007 to Q1 2011. Unfortunately, sales by Apple are not reported by device, so some quarterly sales are combined sales of iPhone 3G + iPhone 3GS respectively iPhone 3GS + iPhone 4.
I tried to extrapolate individual device sales by making the assumption that over time periods where two different iPhone devices were being sold, the newer one was likely to have sold more. Since we’re talking about Apple I choose a 70/30 split, meaning I assumed that 70% of the sales were for the newer device. This seems about right since newer devices have always sold better than the previous generation, but also according to some developer statistics.
For example the Bump developers reporting an iOS 4 adoption rate of 90% in January 2011 across all iOS devices (1st generation devices can not install iOS 4). Or the Surgeworks iOS 4 Adoption report which contains usage statistics of 1st generation device users of only 2.5% for one app, and 5% iPhone 3G users for another app.
The left side of the following pie charts shows the total number of iPhone devices sold to that date, with sales periods of two devices combined. The pie charts on the right show the extrapolated sales statistics for individual iPhone device generations, and which OpenGL ES version they support.
Download the Excel sheet I used to create these charts:
Notice how in Q1 2010 about two third of all iPhone devices supported only OpenGL ES 1.x, but within a year the picture turned just the other way. In Q1 2011 two thirds of iPhone devices sold were capable of running OpenGL ES 2.x code!
This has a lot to do with two factors: the iPhone 4 sold like crazy, whereas the last OpenGL ES 1.1 iPhone being sold (iPhone 3G) was discontinued in June 2010. Meaning since Q3 2010 Apple does no longer sell OpenGL ES 1.1 iPhone devices. And OpenGL ES 1.1 iPod Touches stopped selling in Q4 2010 as well.
All iOS Device Sales Statistics Q2 2011
According to Unwired, Apple reported to have sold 200 million iOS Devices during the iOS 5 announcement. 25 Million of those were iPads. These are the most up to date sales stats, which I assume to be the Q2 2011 statistics.
Based on Wikipedia’s numbers which states 83 Mio. iPhone devices sold vs. over 60 Mio. iPod Touch devices sold, the remaining 175 Mio. should be 42% iPod Touch (74 Mio) and 58% iPhone (102 Mio).
The percentage of OpenGL ES 2.x capable iPhone devices to those only supporting OpenGL ES 1.1 was 31% in Q1 2010 and jumped to 64% in Q1 2011. Assuming the 1.1 to 2.x ratio is the same for iPod Touch, that gives us 137 Mio iOS devices (iPhone, iPod Touch, iPad) with OpenGL ES 2.x capability versus 63 Mio devices (1st & 2nd generation iPhone / iPod Touch) which don’t support 2.x.
This pie chart includes all iOS Devices and which OpenGL ES version they support:
That means 70% of all iOS devices sold to date support OpenGL ES 2.x. This leaves us with only 30% of iOS devices not capable of running OpenGL ES 2.x code.
I don’t want to lose 30% of my customers!
You won’t!
Keep in mind that these statistics are only about devices sold. They do not reflect what has happened to these devices since, or how they are being used today.
I can also assert that older devices are disappearing fast from the market. Even though 30% of the devices sold support only OpenGL ES 1.1, your potential customer base will be significantly less than the number of devices sold. This is for a variety of reasons:
- device has been lost or was stolen
- device broken beyond use/repair
- device simply no longer in use
- device owned by a person who is unlikely to buy new apps
Particularly the last item must be considered: the device user. Again, the user is your potential customer, not the device. And in general all of these items are more likely to happen the older the device is.
One commenter in one of the two GL ES 2.0 threads on the Cocos2D forum reported how happy users were to see a game running smoothly on their 1st generation devices. For me that is not proof that support for older devices is beneficial. To the contrary, I think it clearly shows us that old generation device users are much more selective about their purchases, are already giving up their love for their devices, and may be considering an upgrade because they may have stopped enjoying their devices. This contributes to the “less likely to buy new apps” factor.
You can also assume that users of older devices have less expendable income, or are satisfied with the device as it is. If a user is actually happy with an old iOS device, it’s likely that person prefers to use apps and plays few(er) games or just keeps using the apps & games already owned.
The number of potential customers you would lose - if you released an OpenGL ES 2.0 game right now - is maybe around 10% to 20% at most. Far less if your game is complex and visually rich, and would suffer some performance or visual degradation on older devices anyway.
What about the near future? (Q1 2012)
Considering that 6 months from now, in Q1 2012, we will have seen the release of new iPhone devices (iPhone 5, possibly iPod 5) and thus another boom in sales, it is a better deal to start making some cool visual effects with shaders that look great on iPhone 4 and 5 rather than trying to still support 1st and 2nd generation devices.
In particular if you need to put in some (or a lot of) effort to support the older devices, for example if you have to optimize the performance, reduce the feature set (eg no or limited Game Center support) or (god forbid) you need to ensure compatibility with iOS 3.0.1 or lower (CADisplayLink unavailable!). That time and effort are better spent on making a better OpenGL ES 2.x game!
Obviously the decision also depends on how visually rich your game is going to be and whether you can expect to run into performance and other issues on older devices anyhow.
Summary
I fully expect the market share of OpenGL ES 1.1 devices sold to drop to around 20% by Q1 2012. That puts the number of potential customers (for game developers) still using those devices and buying games to certainly much less than 10%. Then consider that the iPhone 5 may even already account for up to 5% (~10 Mio) of all iOS devices sold by Q1 2012.
By the end of 2012 the potential customer base (for game developers) still using 1st and 2nd generation devices will have become entirely negligible.
That means, if you start developing an OpenGL ES 2.x game within the next 3 months, and your game takes 3+ months to complete, you will lose very few customers by only supporting 3rd generation and newer devices. And you may actually be able to win more customers by cleverly supporting the new devices!
I think it’s wise to start using Cocos2D v2.0 as soon as it is production-ready, which may be in around 3-6 months according to the comments and current progress.
Game On, Cocos2D 2.x!
The most frequent questions I get from readers of my Learn Cocos2D book:
- “Where can I download the source code?”
- “Why do I get compile errors in CCLabel?”
- “Is there an updated version of CCAnimationHelper?”
They all boil down to the fact that the book was written against cocos2d-iphone v0.99.5 with some projects using v0.99.4 and a few even had used v0.99.3.
Unfortunately this is also why some readers deducted one or more stars in their Amazon book reviews. Even more unfortunate because the changes that break the code were entirely cosmetic (renamed classes, function parameters removed or re-ordered, deprecated functions in favor of others). All changes required only fixing the lines using one of these outdated classes (CCLabel, CCLayerColor) or functions (bitmapFontAtlasWithString, frameWithTexture, …).
Quick List of Changes
I kept track of the changes I made to the source code. This is what it boils down to:
- remove: EAGLView viewWith… -> remove last parameter: preserveBackBuffer:NO
- remove: CCSpriteFrame: frameWithTexture -> remove last parameter: offset:CGPointZero
- remove: CCAnimation: animationWithName -> animationWithFrames & remove last parameter: frames
- rename: CCLabel -> CCLabelTTF
- rename: CCBitmapFontAtlas -> CCLabelBMFont
- rename: CCBitmapFontAtlas: bitmapFontAtlasWithString -> labelWithString
- rename: CCXxxxxTransition -> CCTransitionXxxxx
- rename: CCColorLayer -> CCLayerColor
- rename: CCQuadParticleSystem -> CCParticleSystemQuad
- rename: particle system: centerOfGravity -> sourcePosition
- change: particle system: use NSUInteger instead of int for initWithParticleCount
These are the changes affecting the book’s source code. There were some more changes in the cocos2d-iphone engine, for example some actions have been renamed as well.
Good News: Updated Source Code for v1.0
I updated the book’s source code to use cocos2d-iphone v1.0.0 rc2. Once the v1.0 final is released I’ll make another update.
You can get the book’s source code from the Learn Cocos2D Book product page (scroll to the bottom), or via this direct download link. The download is about 100 MB and contains all the chapter’s source code plus some extra projects not mentioned in the book, and all of them (over 70!) are now using cocos2d-iphone v1.0.
Note: This code obviously differs slightly from the code described in the first edition of the Learn Cocos2D book, so you should get the unmodified v0.99.x book source code as well.
Upgrading to Cocos2D v1.0
I also recently wrote a tutorial outlining the steps to update an existing cocos2d-iphone v0.99.x project to v1.0 in case you have an existing project that you’d like to upgrade to the latest Cocos2D version.
Learn Cocos2D: Second Edition
All these changes will be reflected in the second edition of the Learn Cocos2D book.
The second edition will be released summer 2011, likely around July to August. This is my estimate based on the fact that my work is scheduled to be completed on June 27th, and I’m working hard to keep that (tight) schedule.
Actually, make that we are working hard. The second edition of the Learn Cocos2D book will have contributions from a co-author. Someone who is well-known in the Cocos2D community! To be unveiled. 
Upgrading cocos2d-iphone is a recurring issue for many developers but since it happens so infrequently during the lifecycle of a project, there’s just no routine to follow. Eventually you might want to upgrade cocos2d-iphone, so the question arises: how do you do that with the least amount of trouble?
As I’m going through the process of updating over 70 (!) Xcode projects for the second revision of my Learn Cocos2D book, I thought I should outline the steps to upgrade an existing Xcode 3 project which uses cocos2d-iphone v0.99.x to a Xcode 4 project that uses cocos2d-iphone v1.0.x.
Prerequisites: software update
Obviously, you want to download the latest cocos2d-iphone version and unzip it to any directory. Just remember where you unzipped it because that’s where you’ll copy the new library folders from.
You also want to make sure you’ve upgraded to Xcode 4 by now, by installing the iOS 4.3 (or later) SDK, if you haven’t done so already.
Caution: Make sure Xcode is closed during the first steps.
Step #1: delete libs folder contents
In your project’s folder, in this case DoodleDrop03, select all folders in the libs folder and delete them without mercy:
You’ll end up with an empty libs folder. In other words, don’t delete the libs folder itself or in case you did, make sure you re-create the libs folder.
Caution: The reason why I delete all the libraries in the libs folder instead of simply overwriting the libraries with new ones is simple: you can expect the updated cocos2d-iphone version to have removed or renamed some files. By first deleting all libraries you can be sure that no “zombie files” exist which are no longer used but might still be compiled when you later re-add the libraries. Such zombie files would screw up the build process and generate errors like “Duplicate defined symbols” and other such mishaps.
Step #2: copy the library folders
The first thing you’ll notice when you want to upgrade the libs (Box2D, Chipmunk, cocos2d, CocosDenshion, cocoslive, FontLabel and TouchJSON) is that they’re in different folders in the cocos2d-iphone project that you’ve downloaded and unzipped.
Make sure you select the exact same folders that are selected in the screenshot below:
This difference in folder layout can be a bit confusing. What you need to be aware of is that the Box2D, Chipmunk, FontLabel and TouchJSON folders are in the external folder in the cocos2d-iphone project. Furthermore, the Box2D folder that you should copy is a subfolder of Box2d. Note the difference in capitalization of the letter D. You want to copy the folder with the uppercase D: Box2D. The same goes for the CocosDenshion folder, you should select the CocosDenshion folder inside the CocosDenshion folder.
Caution: Make sure you don’t select the Box2D Testbed folder - if you do and copy that as well, Xcode 4 might lock up building the project, consuming 100% CPU power and requiring a force quit to shut it down.
Note: If you use only Chipmunk or Box2D physics, or neither of them, you can skip copying these folders of course.
To complete the copy opertation, go to the libs folder and paste the copied library folders so that you end up with a libs folder that looks exactly like the image in Step #1.
Tip: If you prefer drag and drop you can just drag the selected folders from one Finder window to another onto your project’s libs folder. This may be easier to do but you should remember to hold down the Option key while dropping so that you actually copy the folders instead of moving them. The copy operation is indicated by the green + icon underneath the cursor as you drag & drop while holding the Option key.
Step #3: Remove Library References
Open your project in Xcode 4 now.
Select all groups under the cocos2d Sources group and hit Backspace to delete these groups (or right-click and choose Delete). You will be prompted with a dialog like in the screenshot below.
Make sure you select the default option Remove References Only to avoid deleting the new library folders you just copied:
Once you’ve removed the libraries groups, the cocos2d Sources group should be completely empty. You just got rid of all the old references, saving yourself from any potential compilation errors caused by references to files which may not exist anymore.
Step #4: Add Library Folders
Next you want to re-add your library folders. Select and right click the cocos2d Sources group and select Add Files to “NameOfYourProject”…:
Browse into the project’s libs folder and select all the library folders that you need in your project.
You may have noticed that my project doesn’t use any physics engine, so I decided to not add them here. If you do use Box2D in your project you would want to also select Box2D of course. Likewise if you use Chipmunk.
Note: While it’s not a problem to add both physics engine folders, doing so might increase your App’s size.
Now, here’s where you need to be careful with the options! You want to make sure they’re set exactly as in the screenshot below. Most importantly, when adding files Xcode will default to add the files to the project’s main target (in this case DoodleDrop) instead of the cocos2d libraries target.
Make sure that only the cocos2d libraries target is selected to avoid any build errors:
Step #5: Build it!
You should now try and build the project. If you’re lucky, there won’t be any errors and you can continue with your work.
But most likely, depending on your project’s complexity and the changes made to cocos2d-iphone, you may have to fix any build errors that occur. Most of them are likely to be caused by classes that have been renamed or functions that have been deprecated. In this case you’ll have to find out through the API Reference and release notes what the changes are and how to fix them.
Fixing the “missing base SDK” message
One common issue that occurs specifically to older projects is the “missing base SDK” error. I think it was the Xcode version introduced with Mac OS X Snow Leopard (released Aug. 28th 2010) that eventually fixed this dreaded issue by adding a “latest iOS” option for the Base SDK Build Setting.
If you see a message like this (especially if it gives you a compile warning or error):
You should change the Base SDK Build Setting of your project to use the “Latest iOS” setting:
Note: In some cases it may be necessary to close Xcode 4 and re-open it to make the “missing base SDK” message go away.
Correctly Inheriting Build Settings
Normally, all targets in Xcode inherit the Build Settings of the project by default.
However, once you’ve made any change to any Build Setting at the target level this Build Setting will no longer inherit changes made to the same Build Setting on the project level. The default reaction by many developers is often to bite the bullet and check and re-check the Build Settings of the project as well as all targets, and to make the same change as many times as you have targets in your project.
Don’t do that, there’s a better and easier way!
You can have a Build Setting at the target level to default back to inherit the Build Setting defined at the project level. Likewise a Build Setting at the project level can be set to inherit from the OS default setting. In the screenshot below I have purposefully changed the Build Setting at the target level:
To have it default back to the project setting, which is Latest iOS (iOS 4.3) all you need to do is to select that Build Setting and hit the Delete key:
Tip: Switching from the Combined to the Levels view when reviewing the Build Settings makes it easy to see which Build Settings are inherited and which aren’t. You’ll also notice that any Build Setting that has been changed at the current level and doesn’t inherit its value anymore is printed in bold letters.
That’s it!
Happy coding with your newly updated cocos2d-iphone project! This upgrade tutorial will also be printed in the second revision of the Learn Cocos2D book.
Tip: With Kobold2D it will be even easier to upgrade your project because a simple copy & paste of the files in the kobold2d folder will suffice. If there are ever any additional steps to follow we’ll describe them in detail of course.
