Do No Harm

First things first, make a backup of the project. In case of emergency, it’s easier to revert the processes undertaken. I simply made a tar file of the project directory and then gzipped it.

Excise The Old Tissue

I deleted the ‘cocos2d’ directory inside my “cocos2d Sources” group of classes (I’d create the project using one of the cocos2d templates). When asked, I told Xcode to move the files to the Trash, not just delete the references.

Introduce The Transplant

Next was copying in the new ‘cocos2d’ directory from the 0.9.0-alpha tarball into the place the old version of the directory inhabited. I stated I wanted to copy the files, not just references, and that I wanted them added to the ‘cocos2d libraries’ subproject.

Administer The Anti-Rejection Medication

At the bottom of the new ccConfig.h file is a commented out line that creates a CC_COMPATABILITY_WITH_0_8 flag. This is required initially, and will make cocos2d create stub classes that use the 0.8 naming conventions but flag their use with deprecation warnings.

Move to Intensive Care and Observe The Patient

Now that the new files are in place and prepared, it’s time for a clean and compile. The result: a whole bunch of warnings as expected, but also a handful of errors. Errors are bad.

Fortunately, all the errors were the same – the compiler was complaining about the lack of a TargetedTouchDelegate protocol. This has been renamed CCTargetedTouchDelegate, so that change was applied liberally through the header files, the compile was fine, but the linker hated me. Turns out that the addition of the files to the ‘cocos2d libraries’ subproject was a mistake. With that checkbox unchecked, the linking went fine.

Fool Me Once…

Okay, so I really wanted to have my cocos2d folder live within the subproject build, not the main project. I deleted that new cocos2d directory again, and before adding it back I set the active project to be the ‘cocos2d libraries’. When I copied the files back into place, I was given the choice of making them exclusively part of that target, and did so. Then I set the active project back to my app, updated ccConfig.h again, cleaned the project, and compiled again. All good.

Removing The Stitches

The setup was all corrected, now I needed to deal with the warnings. Most of these simply required the addition of the new ‘CC’ namespace prefix. A few class names had changed completely though:

• TextureMgr is now CCTextureCache
• AtlasAnimation is now part of CCAnimation
• AtlasSprite is now part of CCSprite
• AtlasSpriteManager is now CCSpriteSheet

Where the class name had changed, there were a few method name changes to go alongside. Animation changes were slightly more involved, but not significantly so. My code now compiled without any warnings. All done, right?

Fool Me Twice…

The last step was to re-comment the line in ccConfig.h that enabled 0.8 compatibility. A clean and compile later, and there’s a ton of errors again! Looks like not everything has a deprecation message yet. These classes included Director, TouchDispatcher, and some animations. The fixes were all class renames, and then it was done.

A Simple Operation

All in all, this was a pretty simple feat to accomplish, though I got a lot of help from the upgrade guide and the community forum.  The cocos2d library is great and I look forward to seeing what new functionality the 0.9 series will bring us.

Below is a rehash of some comments I left at Fred Wilson’s blog.

Today, the vast majority of iPhone developers are targeting the App Store as their only distribution channel. Though Apple has made an “ad-hoc” distribution channel available, it is unwieldy and extremely limited in its scope. Some developers have attempted to use this channel to circumvent the App Store; the reaction from Apple was to further limit the ad-hoc channel to the point that it was no longer viable for mass distribution.

While many commenters feel the whole idea of having an approval process is wrong on a moral level (“my customer’s device, my customer’s choice”), it does provide some value. In summary, some of the approval process is automated (“is this application only referencing public API methods?”) and some requires human input (“does the application meet our UI guidelines?”).

Given that some of the approval process is automated, I believe Apple should execute the automated steps as early as possible – right after the application has been uploaded. There is no value in a developer sitting around for two weeks for their program to be approved, only to find out that they’ve been rejected because an automated test has finally been run. The sooner this rejection reason can be communicated, the better.

Looking beyond this automation, there is the question of distribution. Currently Apple controls all distribution of applications for their mobile devices. I think they could open this up to some extent, while still maintaining control over certain aspects of code quality.

When developers submit their applications for approval, they could request an approval for “independent distribution”. Such applications would be required to pass the automated parts of the existing approvals process, and would probably have other restrictions (i.e. no access to StoreKit, no Push Notifications, possibly no network access). Passing applications would be signed by Apple as having been approved for independent distribution and could be installed via iTunes or directly through Mobile Safari and a slightly updated version of the existing App Store program on the iPhone.

If the developer chooses to only have their application approved for independent distribution, it is not put into the queue for human approval. This moves simple applications out of the extended approval process. Apple could introduce additional timing incentives for developers to start using this approval option. For instance, if the developer wants both forms of approval, they don’t get the signed binary for independent distribution until the full App Store approval process has been completed.

At the time of writing, the approval queue is approximately two weeks long (“96% of applications are approved within 14 days”). This queue is part of a workflow that takes a developed application and eventually makes it available to users exclusively through the App Store. By introducing some automation and other limiting criteria, Apple could create a better experience for their developer community and enable new distribution channels.