I got the Mac sales numbers from Apple’s quarterly Earnings Press Releases dating back to Q1/2007. Nearly all Macs sold from 2007 onwards are capable of running at least OS X 10.7 (Lion). The Mac numbers include both desktop (iMac, Mac mini, Mac Pro) and portable (MacBook series) machines.

This puts things in perspective from sheer numbers. There are now more iPads in the world than there are (relatively up-to-date) Macs!

On the other hand, given that most Macs cost over $1,000 the sales numbers aren’t reflecting revenue. But you can argue that making a Mac OS X (Mountain) Lion app has the potential to reach the same number of App Store users than an iPad exclusive app.

Apple’s Quarterly Results Reports have one big flaw for those interested in per-device numbers: Apple only mentions how many iPhones, iPods and iPads they have sold in each quarter, but this includes all models. So you have to exclude the discontinued models as well as somehow determine (if only by guesstimating) how many iPod touch vs regular iPods, or how many iPhone 3G vs iPhone 3GS have been sold in that quarter.

I took the publicly available numbers and then used a reasonable guesstimate to split the device sales of two combined models in order to get a reasonably accurate estimate. I mainly wanted to determine how the gap is widening between the OpenGL ES 1.1 and OpenGL ES 2.0 models. This is particularly interesting for Cocos2D developers who may be wondering if it’s save to upgrade to Cocos2D 2.x or whether it’s still worthwhile to stick with Cocos2D v1.x to be able to deploy even to 1st and 2nd generation iOS devices.

Today I completed the first draft of the Kobold2D chapter which will be in the second edition of the Learn Cocos2D book. In that chapter I’m also giving you an introduction to cocos3d, the official 3D add-on library for cocos2d. I ported cocos3d’s Xcode project template to Kobold2D and spiced it up a little with some cocos2d nodes in the back- and foreground:

Notice the “incoming network connection” warning. This is caused by the iSimulate library which is distributed with Kobold2D and activated by default for Simulator builds. You still need to buy the iSimulate App to benefit from it though. If you don’t you can also choose to ignore the dialog or simply disable iSimulate by commenting out a line in the project’s BuildSettings-iOS.xcconfig file.

I’ve also had great fun with the augmented reality option that the cocos3d CCNodeController class provides. And setting it up is one line of code. Here’s the “camera as live background” demo in action:

Since a picture doesn’t really do it justice, here’s a video:

Admittedly it could run a little faster on my iPhone 3G. It’s pretty taxed and averages around 20 fps with the camera background view and rendering a 3D model. My iPod Touch 4 averages at around 40 fps and it feels a lot smoother.

Kobold2D Todo List

One of the biggest items on my todo list for Kobold2D is to design the website and get rid of the “coming soon” page. This includes setting up the wiki and filling it with content, documentation for the most part. And, well, paying $150 each month because I don’t see any alternative to using Confluence. I want to enjoy working on documentation, and I want you to enjoy browsing and reading it.

I also want to create more template projects. Currently, as you can see in the first screenshot, there’s Hello Kobold2D (iOS & Mac), Hello Cocos3D (iOS) and Hello Cocos2D-X (iOS). I want to add two more templates, one for Chipmunk with SpaceManager (iOS & Mac) and one for Box2D (iOS & Mac). I also want to add the projects from my book as project templates, namely Doodle Drop, the Shoot ‘em Up game, the Orthogonal and the Isometric Tilemap projects, and the Cocos2D With UIKit project (all iOS).

Even though Kobold2D won’t have Xcode 4 Project Templates I still want to give you a quick and easy way start a new project based on one of the template projects. Notice the distinction between “project template” (those in Xcode’s New Project dialog) and “template project” (a regular, already existing project). I started writing a tool that allows you to create a copy of an existing Kobold2D template project and rename it, so that the workflow is just as convenient as doing it within Xcode. It works for the specific template I tested it with, but I still have to design the user interface and make the code fail-safe.

In case you wonder why Kobold2D won’t have Xcode Project Templates: they are not nearly as powerful as they would have to be. And they’re a pain in the rear to create and maintain without some tool support. But worst of all, you have no way of including files in an Xcode 4 project template that must not be added to the Project Navigator. Like, for example, .xcodeproj files.

The Answers

What will be the framerate for each function when run 100 times per frame on an iPhone 3G? Answer: 27 fps for function1 and 24 fps for function2.

Will wrapping the 100 calls to function1 in an NSAutoreleasePool show any difference? Answer: no, but memory of temporary objects is released immediately.

Needless to say, on an iPod (4th Generation) and an iPad these tests all run at 60 fps and give no indication whatsoever that the performance on an iPhone 3G would suffer this much (and neither does the Simulator, of course). All the more reason to test early and often on older devices.

To autorelease or not?

Common wisdom may tell you that alloc/release is faster than autorelease. Even Apple recommends avoiding autorelease, right?

Not quite, because this is often misunderstood: Apple recommends to avoid autorelease but only for functions which create a lot of temporary objects and because of the constrained memory – not because it’s slow or even dangerous – autorelease is not dangerous.

Since memory is so constrained on 1st and 2nd generation iOS devices, it’s best to release that memory as soon as possible and don’t leave it allocated for longer than necessary. To achieve this, you can choose to do two things in this case: use alloc/release or enclose the loop in an NSAutoreleasePool. The latter option is preferred since it will release the memory right away, and not some time later. And autorelease is generally preferable because you will never, ever forget to send a release message to an object – which means it’ll be leaked and forever use up memory.

You can write well-performing, even better-performing code by using autorelease and using NSAutoreleasePool around tight loops creating many temporary autorelease objects.

Innocent looking code kills framerate

Did you expect that creating 100 rather simple NSDictionary instances each frame would drag the framerate down to around 24-27 fps? Me neither. I knew the code wasn’t going to be blazing fast, but I never expected it to have such an impact. However, it can be optimized somewhat since I’m unnecessarily creating two NSArray instances to hold the keys and values respectively before using them to create the NSDictionary. In fact we can get rid of them by using dictionaryWithObjectsAndKeys and doing this in a single step:

Sometimes it helps to look around what other ways there are to run the same code. In terms of performance this is an order of a magnitude faster and now clocks in at 42 fps. Still not good enough for realtime rendering obviously but an improvement of over 50% by cutting two NSArray allocations is a very simple and effective optimization.

Just as a general guideline, when I get rid of the two NSNumber instances and simply pass empty strings for x and y the framerate went back up to 60 fps. Of course that’s over-optimizing to the point where the code doesn’t work anymore. It just goes to show how expensive the creation of NSDictionary and NSArray are, as is wrapping simple types in NSNumber or NSValue objects.

If you can avoid allocation and temporary objects, avoid it. If you can’t, at least avoid creating temporary objects every frame. Re-use objects as much as possible. Unfortunately, that’s not an option for NSNumber objects since you can’t change the value of a NSNumber instance.

In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we need.

Previously, the only programming languages allowed to write iOS Apps were C, C++, Objective-C and Javascript. This has now been removed. For cocos2d developers nothing changes, except maybe that you can feel more comfortable embedding a scripting language like Lua into your games. As long as you don’t allow the Lua scripts to be changed by users, or download or otherwise modify/replace bundled Lua scripts. That wasn’t illegal before, however, yet after the change in section 3.3.1 it put a lot of doubt and worry into developers looking into using Lua. So you can now feel much more comfortable using Lua in iOS games, for example by using iPhone Wax.

The removal of these language restrictions is essentially good news for Unity developers (read their statement), and those who wish to develop iOS Apps using a Flash cross-platform compiler and also those using Corona Game Edition, which is entirely Lua-based. And speaking of which, Corona offers developers to purchase Corona SDK and Game Edition at just $99 until only September 15th, after which you’ll have to pay for each product seperately and the price goes up to $249. Just in case you were eye-ing it.

Compatible with cocos2d-iphone v1.1 and v2.0, Xcode 4.6 and iOS 6.

Includes ARC enabled versions of the starterkit!

What it is:

Get a head-start for your Line-Drawing game and save days if not weeks of your time! You’ll get gameplay code modelled after the extremely popular Flight Control game. You’ll learn how to draw lines, detect touches on objects, have objects follow a path – and much, much more! Written by a professional game developer and game industry veteran (me) the source code is annotated with lots of comments explaining my rationale and written with readability in mind.

Contains separate iPhone & iPad targets!

The Starterkit includes targets for iPhone and iPad using the same code if you don’t want to create a Universal app, for example to reduce your app’s size or to be able to charge more for the iPad version. If the iPad Target is selected hi-res iPad images will be used. Image selection is done automatically by loading those images whose filenames have the “-ipad” suffix, the same suffix cocos2d uses.

Questions? Need Help?

Legal Disclaimer

Cocos2D is a registered trademark of Ricardo Quesada. Steffen Itterheim, the Learn & Master Cocos2D website and the Line-Drawing Game Starterkit are neither affiliated with nor endorsed by Zynga or Ricardo Quesada.

Made with the popular cocos2d-iphone game engine.

Compatible with cocos2d-iphone v1.1 and v2.0, Xcode 4.6 and iOS 6.

Includes ARC enabled versions of the starterkit!

License Agreement

Copyright

Purchase grants you the License to use and modify the source code and assets under the following Terms and Conditions:

You are not allowed to make the source code publicly available. You are not allowed to give or sell the source code to others, modified or not. Licenses are not transferable.

All Licenses are royalty free. You can make as many free or commercial Apps using the source code as you want. You may re-use any existing assets in your App.

If you do contract work and have or want to give the Starterkit source code to your client, your client needs to purchase a Site License as well.

Site License

Each purchase grants you a Site License. The Site license grants you the use of the Starterkit without restrictions at one site.

A site is an office, building or living space rented or owned by the company or individual making the purchase. It allows anyone working on site to use and modify the Starterkit source code.

Large companies operating at several sites need to purchase a site license for each individual location if the Starterkit is to be used at multiple locations. Contact me if you’re such a corporation and you prefer a flat fee license with your own license text to go along with it.

Support

Updates to the Starterkit are done on an as needed basis. I will also keep it up to date and running with the latest stable releases of cocos2d. Updates are distributed via a download link sent to the email address you used for your order. If your email address ever changes please contact me, ideally you should forward me your order confirmation in that case to speed up the change.

Source Code not covered by this License

The licensed Source Code project contains files which are available for free and are governed by different licenses. The Terms & Conditions outlined here do not apply to source code files which do not contain the Copyright notice “Copyright (year) Steffen Itterheim. All rights reserved.”.

Disclaimer

THIS SOFTWARE IS PROVIDED “AS IS” AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Questions? Contact me!

If you have any questions or if you require specific License texts before making a purchase, please contact me.

If you think your game suffers tremendeously from App Store Piracy, you’re wrong. To put it bluntly: your game has simply failed on the market!

Reports that put the App Store piracy rates at “at least 60%” and developers reporting piracy rates of 80% and even up to 95% are mathematically correct but what they often forget to tell you are actual sales numbers. In the rare cases where Indie developers also mention how many sales they have made, pirates or not, these numbers are always extremely low. For a commercial developer who reports an 80% piracy rate on one of his games it’s simply an attempt to turn terrible sales into a PR story which might give their game a little bit more attention. In fact, i expect the games who report piracy rates of over 30% to have sold no more than 5,000 copies. At $.99 this creates a revenue of $3,500 – maybe a good number for a two-man team but a catastrophe for a commercial developer. This is hardly a problem caused by piracy but a simple failure of the product on the market.

What you have to understand about Software Pirates in general: they use a lot of software. In fact, this is their hobby and favorite passtime, to try out as much software as they can get their hands on. So you will always have a minimum amount of pirated copies of each piece of software, no matter how successful this software is (or not). Of course, with higher success and more sales of the software more pirates are also likely to use it because they, too, value quality software. But given the amount of jailbroken iPhone devices prepared to run pirated software there’s a hard cap of the maximum amount of piracy you will ever see on any title. Just as much as there will be a minimum number of pirates playing every game as soon as it becomes available and regardless of how successful it is on the App Store. If your sales are close or below that minimum number of pirates, you naturally get piracy rates of over 50%. These pirates don’t cut into your revenue however. Ignore them. They never would have bought your App in the first place!

David Rosen from Wolfire reports in his Another View on Piracy article that the highest number of Jailbroken iPhones worldwide is said to be 10%, and in the USA – whose users constitute about two thirds of the iPhone/iPod market – the number of jailbroken devices is just 5%. Assuming a total installed base of 75 Million iPhones (50 Mio. as of April 2010) and iPod touches (20 Mio. as of Sept. 2009) we get at most 7.5 Mio jailbroken devices worldwide, or approximately 2.5 Mio jailbroken devices in the USA. They are not all pirates, however. PinchMedia reports that 38% of jailbroken devices have run at least one pirated App. They also state this number is low. So let’s just take half and we’ll end up with 3.75 Mio. jailbroken devices worldwide which have run at least one pirated App. Still a pretty high number – but it only tells us that they have started one pirated App but not how many or how much of a pirate these users really are. If i had to guess i would say that 10% or just about 400,000 of these users are active pirates who try out a lot of Apps on an almost daily basis. These are the pirates who make the biggest impact in terms of per-App piracy numbers. They are also the users who are least likely to upgrade their pirated copy to a legal one, if they ever do it at all. And trying to fight these pirates is anything but futile – they will never be your customers!

PinchMedia also supports my theory that most Pirates try out as much Software as they can which, of course, leaves less time to use each App intensely: “Pirated applications are used less frequently, less intensely, and for a shorter overall length of time than purchased applications.”

Let’s go back to the gist of it: developers who have a problem with App Store Piracy have, in my opinion, either a problem of perception or they’re making a simple PR statement aimed at getting them more attention, hoping to achieve better sales. The developers who suffer most from App Store Piracy are those who simply are not successful. Their real problem isn’t Piracy, it’s much more likely that they failed either at Marketing, Timing, Quality or finding their Target Audience.

Let me sum this up with a simple chart which i think explains why App Store developers report amazingly high piracy rates, when in fact they are reporting the commercial failure of their App:

About Me

I started my game industry career in 1999 creating Gameboy titles as designer, followed by working as software engineer on RTS/RPG series SpellForce and BattleForge for a studio that was acquired by EA in 2006.

Since 2010 I'm a freelance developer, specialising on 2D game development for mobile.

Steffen's Books

The iOS Action RPG Engine

Rapidly create your own RPG or action-adventure game with this complete starter kit. Includes an ebook, game source code and a royalty-free art package.More Affiliate Products …