Apple Device Sales Statistics Q3 2012 (Including Macs)

On August 23, 2012, in idevblogaday, by Steffen Itterheim

This is an update to the last sales statistics post to include Apple’s Q2 and Q3 2012 results as well as adding Macintosh sales:

Apple Device Sales, accumulated (Q1/2007 - Q3/2012). Y Axis is in millions.

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.

iOS Sales Statistics including Q1 2012: Split by Model and OpenGL ES 2.0 Support

On March 22, 2012, in idevblogaday, by Steffen Itterheim

With Apple’s blazing Q1 2012 quarterly results, which sees iPhone sales double (!) that of the previous Q4 2011 and last year’s Q1 quarter, it’s time to update my iOS Device sales statistics from July 2011.

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.

Tagged with: apple • cocos2d • idevblogaday • iOS • ipad • iphone • ipod • ipod touch • market share • quarterly results • quarterly sales • sales numbers • sales statistics

Kobold2D: Cocos3D Project Template

On June 25, 2011, in cocos2d, cocos3d, Kobold2D, by Steffen Itterheim

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.

Tagged with: augmented reality • book • box2d • CCNodeController • Chapter • Chipmunk • cocos2d • cocos3d • Confluence • documentation • Introduction • iOS • iphone • isimulate • kobold2d • project template • project templates • Templates • Xcode

iPhone Performance Killers

On March 8, 2011, in Programming, by Steffen Itterheim

Have a look at the following code, and then answer these questions before reading on:

Which function will run faster?
What will be the framerate for each function when run 100 times per frame on an iPhone 3G?
Will wrapping the 100 calls to function1 in an NSAutoreleasePool show any difference?

[cc lang=”ObjC” height=”465″]
-(void) function1
{
CGPoint pos = [self position];
id x = [NSNumber numberWithFloat:pos.x];
id y = [NSNumber numberWithFloat:pos.y];
id objects = [NSArray arrayWithObjects:x, y, nil];
id keys = [NSArray arrayWithObjects:@”x”, @”y”, nil];
id dict = [NSDictionary dictionaryWithObjects:objects forKeys:keys];
dict; // avoid compiler warning, is a noop
}

-(void) function2
{
CGPoint pos = [self position];
id x = [[NSNumber alloc] initWithFloat:pos.x];
id y = [[NSNumber alloc] initWithFloat:pos.y];
id objects = [[NSArray alloc] initWithObjects:x, y, nil];
id keys = [[NSArray alloc] initWithObjects:@”x”, @”y”, nil];
id dict = [[NSDictionary alloc] initWithObjects:objects forKeys:keys];
[x release];
[y release];
[objects release];
[keys release];
[dict release];
}
[/cc]

The Answers

Which function will run faster? Answer: function1
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:

[cc lang=”ObjC”]
-(void) function1Optimized
{
CGPoint pos = [self position];
id x = [NSNumber numberWithFloat:pos.x];
id y = [NSNumber numberWithFloat:pos.y];
id dict = [NSDictionary dictionaryWithObjectsAndKeys:x, @”x”, y, @”y”, nil];
dict; // avoid compiler warning, is a noop
}
[/cc]

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.

Tagged with: alloc • autorelease • framerate • iphone • memory • NSArray • NSAutoreleasePool • NSDictionary • NSNumber • optimization • Performance

Apple removed programming language restrictions

On September 10, 2010, in Mobile Business, by Steffen Itterheim

As summarized by DaringFireball, Apple has loosened their restrictions of section 3.3.1 of its iOS Developer Agreement:

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.

Tagged with: apple • Apps • corona • DaringFireball • developer agreement • Flash • iphone • language restrictions • legal • Lua • section 3 • Store • unity • Wax

Starterkit: Line-Drawing

On May 27, 2010, in , by Steffen Itterheim

Line-Drawing Game Starterkit

Site License! Unlimited Apps!

Royalty Free! No Attribution!

60 day money-back guarantee!

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!

Sale - only $49 !

All Starterkit project artwork provided by Arezou Ipakchi Design. Promotional images created by Justin from CartoonSmart.

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.

What others are saying:

“Code is quite clearly written and decently documented […] definitely a fine investment.”
From: Commercial cocos2d Code review from Alex Curylo.

“It was an awesome moment when I found the source for a line draw game of this caliber.”
-Franklin Lyons, SpinFall

“Especially the path and movement system is saving me lots of headaches.”
-Martin Hoffmann

Games made with this Starterkit:

Launch Control

Ferries HD

Feature List:

cleanly seperated and well-structured GameScene code design with a minimum of dependencies
easy to add new objects and extend object parameters
touch object & draw a path for it (whether it’s already following a path or not)
path drawing ends when path is drawn over appropriate target location (eg airstrip for airplanes, respecting angle of approach)
path drawing ends when arbitrary point limit is exceeded (to avoid slowdowns)
path is drawn when dragged with thick transparent line style like Harbor Master, without glitches
path is split into equal length pieces no matter how quickly user moves finger
objects spawn outside screen, locations can be re-defined and extended
objects display incoming warning marker at screen border
objects display collision warning when any two of them are getting too close
objects follow path to end - then fade out and increase score or continue moving
objects always rotate in movement direction
objects bounce back at screen borders
motivational Labels for successful landings, precached
Score and HighScore Labels
HighScore saved to disk between play sessions
supports both Landscape orientations with autorotation
loads correct resource files depending on Target (iPhone or iPad)
proper Pause handling for incoming calls, SMS
many generally useful Math Helper functions included
lots of comments explaining rationale and giving tips for improvement
assertive coding style to help catch coding errors early on
offline and online documentation
you can choose between using cocos2d-iphone v1.1 and v2.0
you can choose between using ARC or classic manual reference counting
compatible with iOS 5.0 and newer, including iOS 6
compatible with Xcode 4.6 (the most recent versions also work)
easy setup: just unzip, open Xcode project, select build scheme, build and run

Questions? Need Help?

Just send me an email.

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.

Try Before Buy!

Demo App for iPhone
Demo App for iPad

Browse the API Documentation

View a Code Sample