App Store developers now have more to contend with than just the fickle tastes of the humans Apple has reviewing submissions. Now, submissions also go through an automated filter that determines whether or not the app is obeying the rules and not using any of Apple’s private APIs, which is a no-no, according to the developer agreement.

The news comes via a conversation that occurred between developers on Twitter. Craig Hockenberry, best known for Twitterific, guessed that the App Store now contains a mechanism to check submitted code against proper framework use, and John Gruber responded that Apple has in fact recently begun to do just that.

The specific function of the new automated component is to check submissions for private API calls. If it finds any, the app is rejected outright. Presumably, such a check would be run at the beginning of the review process, thereby cutting down a lot on the number of submissions that must be reviewed by actual human beings. In other words, it’s a volume compensation strategy on Apple’s part.

It’s also technically fair, since Apple has said all along that private APIs are off-limits. The published reason being that Apple can’t confirm that said APIs will remain stable from release to release of the iPhone OS, meaning that something based on them might break every time an update rolls out. By forcing developers to stick with the public APIs, Apple is trying to ensure that some stability exists for end-users who depend on the hundred thousand apps or so available now in the App Store.

Despite being technically fair, the move feels a little unfair to developers, since Apple hasn’t exactly been consistent about enforcing the rules regarding private APIs up till now. One reason could have been that spotting their use just isn’t that easy, which the computer filter now rectifies. But it seems clear that Apple also looked the other way in at least a couple of cases when it suited it to do so, like with Google’s mobile search app, hence my suggestion that this has more to do with reducing workload using a non-arbitrary filter than anything else.

While the introduction of an automated layer does, on the surface, seem to guarantee a level of fairness, it also probably isn’t very encouraging to developers, who now essentially face a firewall before they gain access to individuals they can actually talk to about what’s wrong with their submission. Expect more headaches for the App Store team as the fallout for the implementation of this measure.

iPhone devs are a rebellious bunch, and they don’t like to be bullied by anyone other than their Apple, which both frustrates and affirms their existence. Now, in light of what some might call a campaign being waged against the App Store by a well-known trademark troll, many iPhone devs are protesting what they see as Apple’s cowardice in the face of unjust threats.

According to TUAW, the trademark troll in question is none other than Tim Langdell, founder of the “gaming company” Edge Games. In reality, Edge Games produces very little beyond copyright infringement suits, which it launches against any and all games that feature the word “edge” in their title. EA’s Mirror’s Edge recently fell between Langdell’s crosshairs, for example, despite the fact that the game itself bears no similarity to any of Edge Games’ roster of “planned” titles.

Apparently the App Store has been a prime target for Tim Langdell and Edge Games. Reports claim that all he has to do is contact Apple and let them know that a game is in violation of his trademarks — which again, basically means it has “edge” somewhere in the title — and Apple pulls the game without much fuss. No doubt Apple just doesn’t want to deal with yet another legal battle that could ensue if Langdell gets the opportunity to take things beyond the cease-and-desist phase, but this really seems unfair to honest game devs who actually work for their money.

In protest, a group of iPhone devs are changing the names of their games to include “edge” in the titles, with the desired outcome being that Apple will realize that to continue just disallowing the word completely will significantly affect the App Store’s catalog of offerings. So, for example, Canabalt becomes “Canabedge,” the Eliss sequel becomes “Edgeliss” and Critter Crunch becomes “Critter Credge.” All of the changes mentioned haven’t actually been made to the apps in the store, but on developer web sites as a show of solidarity.

Even though this particular protest limits itself to the area beyond Apple’s sphere of control, it does demonstrate a promising solution to App Store bully tactics. If developers could organize in a similar manner, but with bigger numbers and with the support of some of the pillars of the App Store, they could more effectively combat unfair policies. Apple will be less likely to anger content producers if it has potential ramifications across its catalog. Let’s see a developers rights advocacy group come to pass, so articles about the injustices of the App Store can become a more infrequent occurrence.

Going behind-the-scenes of a real iPhone app’s development, in this installment I investigate several methods for cutting development costs and adding value to the game.

I have to admit that I’m still working on the Game Design Document. Something which I thought would take only a few days has grown to incorporate minute details alongside gargantuan fundamental gameplay concepts. This document is essentially Tetris in written form: piling on concept after concept, attempting to make it fit together before the whole thing becomes too unwieldy to manage.

While work on the GDD should finish this week – Matias has stated that this Friday is the absolute deadline – I’m finding the time to explore other related areas of app development. In my last entry I spoke to Mills, one of the founders of ustwo, a growing independent mobile content studio.

Mills provided me with some revealing data in terms of development costs and sales. Looking at ustwo’s costs for app development relative to the revenue that they generated led me to think about how I could lower our own development costs while increasing the app’s desirability.

I’ve managed to find three different solutions that add value to our app and cost either very little or absolutely nothing.

Recycle That Code

Recycling and reusing code is a tried and tested convention in software development, particularly in the game industry. When you write a piece of code once – for example a game engine for a first person shooter – why spend time and money writing it again for the sequel? It’s far simpler to copy, paste, modify and deploy.

Working for a game developer a few years back, there were times when I noted that code recycling wasn’t necessarily in the customer’s best interests. In particular, I remember a top-down shooter – in the style of Grand Theft Auto – recycled as two different titles. The artwork was redrawn, the in-game dialogue was chopped and changed, but it was quite clearly the same game.

We plan to be a little smarter in choosing how and where we redeploy certain pieces of code. The PearComp coders, Matias, Markus and Ben, are currently working on Facebook and Twitter integration for the game. The plan is that, from within the game, players will be able to post their high scores to the two social networking services.

Facebook and Twitter posting is the value-adding feature du jour. Being able to link an app to these services provides a seamless connection between a user’s social life and the app in question. For games in particular, it’s a great way of enabling players to shout about their achievements while generating publicity for the title among their social connections.

In effect, the code that the PearComp team have created for the game can be re-used for future iPhone app developments. It’ll benefit some of PearComp’s clients, plus it’ll cut costs, and save time and resources.

Find Your Voice

John J. Dick is a voice actor and DJ who happens to be pretty badly in debt. His biggest gig was working on Serious Sam, an explosive shooter for hardcore gamers. John’s husky vocals helped flesh out Sam, the game’s main man: an alien destroying, gun toting, time traveling mercenary.

Back in the real world though, John’s debt has become such a problem that he’s come up with a cunning way to bail himself out. John has decided to offer his voice acting talent at an incredibly competitive rate: $1 per word.

Commissioning John to record a few words for the game was an easy decision – it cuts costs for sound recording and should save us some time later in the project. Having John’s name, and by extension Serious Sam, attached to the project could also make for some fun PR when we launch.

Collaborate & Communicate

In the previous installment of the App Developer Diary, I found out a little more about ustwo’s MouthOff app for iPhone. After speaking to Mills. I realized that there was potential for a really exciting collaboration.

I called Mills back the next day and pitched my idea: ustwo would create a special version of MouthOff featuring one of the characters from our game. We’d take the MouthOff code from ustwo and put it into our app, essentially this exclusive MouthOff would be accessed from within our game.

Featuring an exclusive MouthOff mode within our app adds some serious fun and replay value to the game. It would also garner some added exposure for ustwo’s app. Of course, we’ll ensure that there’s a link to the App Store for players to purchase the full version of MouthOff.

By recycling code, finding a great deal on audio assets and collaborating with an awesome dev studio, we’ve made our game even better without breaking the bank.

Next time: I finally submit the Game Design Document to the coders at PearComp.

The open-source project team that released Sequel Pro 0.95 three months ago has just released 0.96. The update adds polish to the application, making working with it more pleasurable — if you can ever call working with databases pleasurable.

They’ve also added some new core functionality and optimized the backend. To me, this feels like more than a 0.01 update. With every update of Sequel Pro, the open-source project continues to close the gap between itself and commercial competitors such as Querious.

New Features

Sequel Pro now includes full SSH tunnel support built into the connection manager (which has also got a UI facelift).

There is a new Relations screen that lets you view and edit foreign keys for a table.

Enhancements

By far one of my favorite new enhancements is the ability to filter the database’s table list. When the list gets larger than the displayed area, a filter box appears at the top, enabling you to quickly find the one you’re looking for. I’ve been using this a lot already.

When running custom queries, the results used to be presented in a static table. Now you can sort the results on the fly by clicking the column titles. Even better, for supported queries you can edit the results directly.

Browser-like table history navigation has been added, allowing you to go back to previous table views, which is great for flicking back and forth.

Significant Update

There are also plenty of smaller enhancements. Another favorite is the ability to select a record (either in the content view or after running a custom query) and then select “Copy As INSERT Statement”. This is so handy, I don’t know why it wasn’t there before. There are plenty of small changes like this, and almost every part of the application has had numerous bugs fixed.

In addition to all the new features, enhancements and fixes, this release is significantly snappier, and very noticeably so. The memory overhead is also greatly reduced. The developers have done some serious optimizing, and the results have paid off. See the full release notes for Sequel Pro 0.96 for a complete list of changes since 0.95.

There’s a new tool available that’s designed to make life easier for iPhone developers, and its surprisingly low tech. It’s called the iPhone Application Sketch Book and it looks like just the thing to keep all those notes and inspirations about a new app idea all in one place.

The spiral-bound book is around 8 1/2″ x 11″ so it won’t get lost in the bottom of a laptop bag. There are 100 pages of design templates with lines at the top for jotting the name and other important details of the app. A real-size image of an iPhone is centered on graph-style paper with ample room to make drawings and notes about every aspect of the development process.

I caught up with the sketch book’s creator, Dean Kaplan, and was surprised to discover the impetus behind the book’s creation.

“I happened to be auditing the Stanford iPhone Programming course,” says Kaplan, “and one of the guest speakers discussed how he went about creating his user interface designs. Paper was one option he mentioned. Almost instantly the notebook idea light bulb went off. Other options of various computer programs were mentioned, but it always got back to paper and pencil. Subsequently, I did my own online survey that revealed designers prefer paper 95% of the time.”

Kaplan says once he got the idea to create the book, it only took about nine weeks until it hit the shelves. Depending on its success, he may create similar sketchbooks for the Palm Pre and Android.

The sketchbook is already a hit with some application developers. David J. Hinson, creator of popular iPhone apps like Cheap Gas (iTunes link) and Amigo (iTunes link), says he sees immediate value in a tool like this. “You can keep your notes and preliminary wireframes all in one handy little notebook. I was really intrigued and I think it’s a great concept because I’m constantly writing things on the whiteboard and losing track of my notes. It’s simple in execution, but spot on.”

Interested developers can pick up the iPhone Application Sketch Book for $14.99 at Amazon.

Welcome to another episode of TheAppleBlog’s iPhone Dev Sessions. We left off with a drum app tutorial called Bickboxx. For this tutorial, we’re building off of the first Bickboxx project, so go back and finish it if you haven’t already. Or if you want to cheat, grab the Bickboxx code from Github.

The Story

The Boss is happy we’ve released Bickboxx, the iPhone drum app, but now he wants to know how it’s doing. Not just sales-wise.

How many people use our app? How many times have they used the app? How much time do they spend using our app? How many users do we have in each city, state and country? How many illegal haxored versions are out there? How many people open the app once and never use it again?

Yikes. That’s a lot of questions.

Lucky for us, we don’t have to write hundreds of lines of code and roll our own analytics server to track the answer to these questions.

There are dozens of iPhone analytics APIs that will do all of the heavy lifting for us. Flurry, Mobclix, and Medialets come to mind.

There isn’t a clear leader in iPhone analytics yet but for this tutorial we’ll be using Pinch Analytics. It has comprehensive documentation and its reporting is detailed as well.

Signing Up for a Pinch Media Account

The first thing you want to do is sign up for a Pinch Media account. The first part of registration is the usual username/email/password page. The second part detailing your app takes you to this:

Since Bickboxx isn’t a real app that you’ll be distributing, you don’t have to fill out any of this. You can skip this part by clicking the “I’ll do it later” button.

When you are adding analytics to your real-life app, I’ve filled out some sample data for you to go by. Note that if you don’t add an app into Pinch Media, you won’t be able to view any analytics reports.

Download and Install the Pinch Media SDK

After you’ve signed up for an account, download and unzip the SDK.

Open up the Bickboxx project in Xcode. Drag the Beacon+FBConnect.h and Beacon.h files into the Classes directory in the Xcode project.

Make sure the “Copy items into destination group’s folder (if needed)” checkbox is checked. Click Add. We do this so our code knows how to access the Pinch Media methods in the libPMAnalytics-rXX.a library.

We’ll need to import the libPMAnalytics-rXX.a library next. Do this by dragging the libPMAnalytics-rXX.a file to the Frameworks folder in Xcode. Again, make sure the “Copy items into destination group’s folder (if needed)” checkbox is checked. Click Add.

Install the Supporting SDKs

We need a few more frameworks to get going. We may not use these frameworks directly, but Pinch Analytics does.

Ctrl-Click the Frameworks folder and choose Add → Existing Frameworks…

Select libsqlite3.dylib and click Add.

Do the same for the SystemConfiguration.framework.

Lastly, do the same for CoreLocation.framework.

Build the project to make sure everything is in place. It should compile. Got it? Good.

Adding the Pinch Analytics Code

Add this import statement for the Beacon.h file into BickBoxxAppDelegate.h.

#import “Beacon.h”

Adding this will allow us access to the Pinch Analytics methods from inside our BickBoxxAppDelegate.m file. Your BickboxxAppDelegate.h file should now look like this. Our change is in line 2.

#import <UIKit/UIKit.h>
#import "Beacon.h"

@class BickBoxxViewController;

@interface BickBoxxAppDelegate : NSObject <UIApplicationDelegate> {
  UIWindow *window;
  BickBoxxViewController *viewController;
}

@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) IBOutlet BickBoxxViewController *viewController;

@end

Open up BickBoxxAppDelegate.m and locate the applicationDidFinishLaunching method. Add this line of code.

NSString *applicationCode = @"REPLACE THIS WITH YOUR APPLICATION CODE";

Replace the REPLACE THIS WITH YOUR APPLICATION CODE with your Application Code from Pinch Media. You can find your application code in your Pinch Media account.

This is your unique ID that Pinch Media uses to identify which app is sending data to them. If you opted to not setup an app during registration, you need to do this to get an Application Code. If you don’t put in a valid Application Code, you won’t get any analytics reports and you’re wasting your time.

We’re going to use this applicationCode NSString to activate our analytics beacon. Add this line of code to the applicationDidFinishLaunching method.

[Beacon initAndStartBeaconWithApplicationCode:applicationCode
    useCoreLocation:YES useOnlyWiFi:NO];

This fires up the analytics code when the app launches. Note that we’re sending in the applicationCode NSString that we inserted in the previous step. Also note the useCoreLocation parameter. You can set this to YES or NO depending on whether you want to capture location statistics.

Use this with caution. If you think you’ll offend your users by asking for their location, set this to NO.

Another parameter is useOnlyWiFi. Not everyone in the world has an unlimited data plan. They’ll be none to happy if your app is sending data over the mobile network when they don’t want it to.

Like the useCoreLocation parameter, use this parameter with caution. If set to YES, the analytics data will be sent to Pinch Media only when they’re connected to Wi-Fi. This way, the people who pay their mobile carrier per kilobyte won’t get mad. The downside is that you will miss usage statistics if they never connect to Wi-Fi.

If you’re not worried about being responsible for someone’s data overages, set this to NO.

Your code in BickBoxxAppDelegate.m for the applicationDidFinishLaunching method should now look like this.

- (void)applicationDidFinishLaunching:(UIApplication *)application {

	// New code below this
	NSString *applicationCode = @"REPLACE THIS WITH YOUR APPLICATION CODE";
  [Beacon initAndStartBeaconWithApplicationCode:applicationCode
								 useCoreLocation:YES useOnlyWiFi:NO];

  // Old code below this
	[[UIApplication sharedApplication] setStatusBarHidden:YES animated:NO];

  // Override point for customization after app launch
  [window addSubview:viewController.view];
  [window makeKeyAndVisible];
}

Finally, when we exit the app or your app crashes (your apps never crash right?), we need to stop the analytics beacon.

Add this method to the BickBoxxAppDelegate.m file.

- (void)applicationWillTerminate:(UIApplication *)application {
  [[Beacon shared] endBeacon];
}

Build and run your app.

You’re Done!

That’s it — you’re done! Go to lunch and have a sandwich. Nothing’s changed to the user except it’s going to ask if it’s okay that Bickboxx uses their location. You can now login to Pinch Media’s site and see all your pretty statistics and graphs. Worth noting is that the data isn’t real-time — it’s only updated twice a day.

Homework

The Boss is happy now that we can measure the performance of our app. He wants more detail on which buttons are pressed the most. You can do this by adding sub-beacons, which you can read about at the documentation site.

BickBoxx On Github and the iTunes App Store

Like last time, the code is open-sourced on Github. You can check your code against the code here if you start to stumble.

We’re here to show you how to build actual apps. You can download the app as it’s built at the iTunes App Store. More info on the open-source/open-tutorialized efforts on the BickBoxx website.

If you were to navigate to lingon.sourceforge.net or smultron.sourceforge.net today, you would see the following text on your screen:

“Hi!

First of all I’d like to thank you for your interest in my applications. But I have now come to a point where I don’t have the time to spend on the applications that they deserve so I have decided to not release any more versions for the foreseeable future.

Cheers,

Peter Borg”

Lingon is a utility to assist managing the launchd process. I covered Lingon in-depth back in February, and it has been a fantastic, easy-to-use tool for managing my custom scripts. The current version can still be downloaded from sourceforge.net/projects/lingon/. Alternatives include Apple’s commandline tool launchctl, and the $5 shareware tool launchd Editor.

Smultron is a fully featured popular text-editor and was one of the first applications I downloaded when I moved over from Windows to the OS X world in 2007. Most importantly, it’s lightweight, fast and boasts a great-looking syntax highlighter, among other tools. It, too, can still be downloaded from sourceforge.net/projects/smultron/.
Of course, there are heaps of alternative text editors for OS X, from the commercial offerings, like Textmate, SubEthaEdit and BBEdit, to the free TextWrangler.

Being open-source projects, hopefully somebody will take over maintaining these two very useful applications. In the meantime, both applications continue to work fine on both Leopard and Snow Leopard, and until they don’t, I’m happy to continue using them. So I’ll just say, thanks very much, Peter for those two great applications. Your efforts have been most appreciated.

Taking a genuine behind-the-scenes look at developing an app for iPhone, the latest installment finds this journalist-cum-game-designer hidden behind a mounting pile of paperwork and planning.

Last time, we left off with me pondering the possibility of the project’s failure. I’ve moved on, though, and set aside my doubts, mainly because I need to focus on the rapidly mounting stack of deliverables that seems to have been pinned to me.

To start with, there’s the game design document, the all-encompassing bible covering every aspect of the game we’re making. The fundamentals go in here, alongside the seemingly irrelevant minutiae. It’s a massive undertaking.

There’s more, though. Markus has coded an empty level, featuring our ball character bouncing around the screen. On paper, the game mechanic I’ve designed sounds like fun, but we’ve not even tested it in practice.

The task that falls to me, as game designer, is to plan out a basic level featuring several different key components: scenery, obstacles and enemies. The key is that I make sure to squeeze in any gameplay concepts that I’d like to test out at this early stage.

And, amidst having to generate blueprints for a prototype level and write what amounts to a small book, we’ve hit upon a scheduling problem.

Real Mobile Development

The three coders, Matias, Markus and Benjamin, started this project as a quick, 3-month development. Their aim was to release for September and, if they struck upon success, release a bunch of new levels in time for the Christmas rush.

Naturally, taking advantage of the iPhone’s new software features, the extra levels would be an in-app purchase. A potentially shrewd move by the trio of coders, until I threw a spanner in the works of their clever calculations.

Having worked at a mobile game studio, I’ve seen many games rushed out the door in time for what seems to be an unrealistic deadline — frequently a symptom of a studio that is run at the behest of its investors.

The investors have a quarterly plan and, for each quarter, want to see their profit targets met. To generate profit, product must be released. And so, to illustrate to the investors that profit can be generated, the studio produces a road map that specifies at least one release per quarter.

Lose/Lose Game

With everyone happy, development can begin. Except, in these situations, it rarely runs so smoothly. Frequently, the specific deadlines are arbitrary — they’re primarily set just to keep the investors happy, with no semblance of realism. As such, the games that are developed don’t reach their full potential. These games are essentially hastily organized attempts to garner profit before moving on to the next cash-generating attempt.

Everyone loses. The consumers receive a poor-quality product; the studio, reduced to the role of factory, farting out a stream of poor games, is demoralized; and the investors’ profit targets are barely hit.

Myself, Markus, Matias and Benjamin have a unique opportunity with this game. We’re not operating at the behest of a board of investors. Nor do we have a release schedule in which our game has to fit. What we have is an opportunity to spend a little more time on development, ensuring that this game reaches its full potential. And after explaining this to the team, they agreed — we now aim to release the game in February of next year.

With the release date moved from September through to February 2010, I’ve bought us around four months of extra development. With six months, three coders and me handling game design, art and sound, we’ve finally begun stacking the odds in our favor.

Next time: I speak to Mills, founder of mobile dev studio UsTwo, about the true cost of development. Only in the next thrilling installment of TheAppleBlog’s App Developer Diary.

Yesterday evening was a red-letter night for Apple developers, especially if you happened to have both Mac and iPhone developer accounts. That’s because Apple dropped new builds of both iPhone OS 3.1 and Snow Leopard, bringing it to version 10A411. Users with an iPhone developer account can head to Apple’s Developer Connection web site and get iPhone 3.1 Beta 2 and its attendant SDK in the usual way, while Snow Leopard users should find the new build available when they open up Software Update.

iPhone OS 3.1 Beta 2

I wasn’t expecting any massive changes in an incremental decimal point update, and a Beta 2 at that, but apparently this latest build packs at least one big punch. Said punch is the ability for developers to communicate with their device wirelessly while debugging new apps and versions, over Wi-Fi. It’s not something end users will ever see or necessarily appreciate, but it’s hard to understate how much it helps on the development side not to have to depend on a hardware tether anymore.

Theoretically, at least, this clears up the dock connector for use with third-party peripherals that tap into OS 3.0’s new software access features. Hopefully that gets more developers working faster on integrated hardware devices, since it’s the one remaining OS 3.0 feature that has yet to see its potential realized.

One “feature” not everyone will be pleased with is the new beta’s built-in tethering trick block, which cuts off the workaround iPhone owners have been using to get around AT&T’s official reluctance. If it makes it through to the official release, I’m not sure U.S. iPhone users will be in a huge rush to upgrade, especially if the rumors of a $55 official tethering plan prove true. AT&T’s official stance at this point is that those particular rumors are not true.

Some additional improvements about which few details are available are battery life improvements, and more access to video functions for developers, which hopefully brings us one step closer to “true” augmented reality capabilities.

Still included in Beta 2 are the Voice Control via Bluetooth and non-destructive video editing features first introduced in Beta 1, which came out June 30.

Mac OS X “Snow Leopard” Build 10A411

This appears to be yet another minor update on the road to the Snow Leopard GM candidate, with all the usual bug fixes, security enhancements and stability improvements associated with that kind of build. The last update did see some UI tweaks, but at this point no new feature additions should be forthcoming.

Like any gaming platform, the sustained success of the platform itself is driven by its users. Social gaming networks allow for increased user interaction and, in many ways, a more engaging gaming experience. On the Xbox, you have the Xbox Live service; the Playstation 3 features the Playstation Network; and the Wii features WiiConnect24. So what types of social gaming services does the iPhone support? Come to find out, an increasing number of them. Here’s a look at the top three.

ngmoco’s Plus+

The company who dazzled your iPhone with hits like Rolando, Rolando 2, Topple (my favorite) and others, recently introduced their service called Plus+. This service allows users to challenge your friends on the network (or via Twitter) and track awards and top scores on leaderboards.

For more information, check out Darrell’s review of the service. From what I have been able to find, the Plus+ service is not open to outside developers at this time.

OpenFeint

If you are a fan of Aurora Feint, you’ve likely heard of their social gaming service called OpenFeint. This service allows users to interact similarly to Plus+, but is based around a concept they call “social discovery.” Some unique features to OpenFeint-enabled games include chat rooms for more open social discussion, the ability to see what other OpenFeint-enabled games your friends might be playing (and buy them from within the app), and the largest user base of games supporting its service, with over 100 games based on OpenFeint.

For developers, if you’re interested in integrating OpenFeint into your next masterpiece, its SDK is free to try and is available here. The size of your user base, or if an app is paid vs. free, determines the cost per user for developers to integrate OpenFeint’s service into their applications.

Scoreloop

Another service to enter this market is Scoreloop, a company and service formed by previous Apple and NeXT employees. Scoreloop is based around the simple objectives of global high scores and player challenges. Much like the other services, it also features integration with social networks such as Facebook, and allows for custom avatars and personalized profiles for tracking records and high scores. Scoreloop’s “economy” is based around coins, which helps to provide a unified scoring system between games, allowing users to maintain their collection of coins and gain or lose more via challenging other players.

While perhaps not as fully featured as other services, like OpenFeint, Scoreloop is, however, the first to announce that it is working to release its service on other devices, such as the Android platform. With a larger target market and a cheaper cost of entry for developers, Scoreloop could easily become more popular than OpenFeint (not to mention it’s user interface is more customizable to fit your application). For developers interested in Scoreloop, check out their free SDK here. Bug Landing, by the Scoreloop developers, is also a free application that features integration with this service.

Will one rise above the rest?

As Twitter became popular, we saw a plethora of competitors enter the market, from Plurk to Jaiku to Pownce. At the moment, a similar effect is starting to happen among these social networking services. Where on the console platform, each manufacturer has produced their own service, Apple has yet to bring any sort of unified service to its users. Since we all have an Apple ID for iTunes, Apple could easily integrate a beautiful solution so you can keep one central list of your gaming friends, awards and achievements.

Will Apple continue to stand by and allow multiple social gaming network services to evolve on the iPhone platform, or will they step in to offer their own service?

At the beginning of the decade, Intel was imagining that by 2010 it would have processors with over 1 billion transistors running at a clock speed of 20GHz. As we move into the second half of 2009, the reality is that we will soon have 3GHz mobile chips with four cores on them and 2010 will likely see 4GHz desktop chips with six and eight cores. Ultra-fast processors running at clock speeds over 4GHz have just been too expensive to power — and to cool off. So the other solution is to have more processors.

These new processors, based on the Nehalem architecture, or the Westmere 32nm process that will follow, will also feature simultaneous multithreading (what Intel calls “hyperthreading”) to allow for two threads to be executed on a single core. So instead of a superfast 20GHz chip, you could have a Mac Pro in 2010 with 16 cores capable of executing 32 simultaneous threads. Apple is preparing for this massively multi-core future with features in Snow Leopard (Mac OS X 10.6) that can take full advantage of all this raw power.

Time for Software to Catch Up

The introduction of dual-core systems was a brilliant success. Even code that was not built or optimized for multiple cores would run at least a little faster because the OS would use the second core, leaving more processing power available to the foreground app. The dual-core systems were noticeably more responsive to the user, and we loved them for this feeling of instant power at our fingertips. Quad-core and 8-core systems have been confined to the Mac Pro line, partly for cost, but also partially because the average user does not have software that can really take advantage of all those cores. Many people would be disappointed to learn that their quad-core iMac did not really seem any faster. Software applications, like Photoshop and Final Cut Pro, were designed by teams with significant engineering resources so that they could take advantage of a system with four or eight cores, and even then certain operations will still bottleneck the application.

What Have We Been Doing?

Multithreaded programming is not new on the Mac. We have had POSIX threads, or pthreads, (and NSThread on top of that) since OS X 10.0. The Mac has a scheduler that is multi-processor aware and can assign processes and threads to available CPUs as needed.

There are two ways that software benefits from concurrency (running multiple software tasks simultaneously). The first is to keep certain parts of the software, say the user interface for a financial management app, responsive while waiting for another task that is being processed, say downloading some stock quote data from the Internet in the background. The second opportunity is to design a function that can be parallelized, or split up into smaller chunks, like encoding a video by splitting it into sections that can each be encoded by a different CPU or core. The responsiveness of the app, and the performance of a parallelized function, are great for the end user. However, each developer is still responsible for managing the threads in the application and designing algorithms and functions for atomicity, parallelization and re-entrancy while avoiding deadlocks, resource starvation, deadly embrace, and so on. Concurrency is a challenging endeavor.

So Why Do We Need Grand Central Dispatch?

Grand Central Dispatch (PDF) is a new technology that will be available in Snow Leopard that helps developers more easily write software for multi-core systems. It does not make multi-threading automatic, or write thread-safe code for you, but it does add semantic and syntactic extensions to C, C++, and Objective-C to make code more readable and better organized with hooks into tools to analyze the multi-threaded performance of an application. Developer still have to do the hard conceptual work around figuring out concurrency in their application, but the implementation of those ideas is cleaner.

How Does Grand Central Dispatch Work?

The core functionality of Grand Central Dispatch is provided by organizing code into blocks and queues. A block is a self-contained unit of work that can represent anything from a simple step to a complex function with all the associated arguments and data. Queues are a method to schedule the execution of blocks and define the relationships between them. Instead of spawning and managing threads in the application, the developer marks sections of code as blocks and then places them in a queue. GCD steps in and manages all the queues and pulls blocks out and assigns them to available threads of the appropriate priority to be executed.

The Instruments utility in Xcode lets developers see how their code runs in GCD, so that they can learn how to improve performance. GCD also has a view of the entire system and the resources available to try to maximize efficiency across all running applications. It also relies on native hardware support for locking in Intel CPUs to implement some of its magic. This stuff won’t work on PowerPC, which is another reason why Snow Leopard is Intel-only.

What About the Users?

If you are an end-user, you will not benefit one bit from installing Snow Leopard and having GCD available unless the software you use is written to take advantage of it. It is not at all guaranteed that developers will jump to GCD. If a certain application would benefit from concurrency, then the developer has probably already started using pthreads to make the software more responsive and take advantage of current multi-core systems. If you look in your Activity Monitor, you will see that most applications have multiple threads already. Since multi-threaded code is hard to begin with, I do not see many projects choosing to rewrite all their pthread code to use GCD blocks and queues right away, especially since it means leaving all Leopard, Tiger and earlier users behind.

The low price on the Snow Leopard upgrade is a nice perk for existing Leopard users, but I think it is also meant to reassure developers that a very large percentage of their existing Leopard customer base will be able to run Snow Leopard-only software. If your app runs fine now using NSThread on Leopard, there is little reason to adopt GCD. So why build GCD at all?

I think the most obvious reason for building GCD is that Apple will be able to take advantage of it with all the system processes and included applications that people use all the time. Looking at my Activity Monitor right now, I see the kernel has 66 threads, Safari has 19, Mail.app has 18, mds has 16, SystemUIServer has 13, Spotlight has 6, and so on. Helping all those threads run more efficiently is going to pay off for the user experience on the Mac. If it helps a few other developers along the way, all the better.

The Future

Things get a little more interesting when you consider that future iPhones will likely have multi-core CPU’s and that Intel is advising developers to prepare for a future with “thousands of cores” available. Add in something like Larrabee, which presents dozens of additional cores to the system, and the wisdom of a systemwide approach to managing threads becomes apparent.

In this week’s enlightening installment of the App Developer Diary, I pitch my game concept to the coders, preach the gospel of the Game Bible and muse upon the possibility of the project imploding.

Straight after submitting last week’s App Developer Diary, I packed up my MacBook Pro and headed down to Nolla, a local bar and Scandinavian restaurant. I was to meet with Markus, one of the project’s coders, and pitch my game concept to him.

Hailing from Finland, Markus Piipari is one of the three coders who invited me on board to make the game. Together, with his brother Matias and Benjamin Schuster-Böckler, the trio formed Pear Computers, a dev studio specializing in mobile development.

When I arrived at Nolla, Markus was hunched over his MacBook (one of the old white models, which was sealed, I noted, in a scruffy faux-leather hard cover). He glanced up, headphones in ear, and although he acknowledged me with a quick nod, had that glazed look of somebody whose mind is elsewhere.

The pitch process is a fundamental component of having your idea become a reality. It’s the first hurdle, as not only should it be a clear and concise outline of your concept, it should also enthuse the rest of the team. As they say in the industry, you need your team’s buy-in — if the team hasn’t bought in to the concept from the very start, then the project is almost certainly doomed to failure.

I was already nervous enough, pitching a concept that I believed in so firmly, and yet Markus seemed to want to make me sweat more than a chubby man in a Finnish sauna. Perhaps this was a Scandinavian tactic to pile on the pressure and make pitching an even more tense affair? Or maybe Markus was living up to the stereotype of a hardcore programmer: King of the Code, cold and focused.

Setting Up My Pitch

Markus uttered a few words in Finnish, clicked around on his MacBook, and the glazed look dissolved into a warm smile. He wasn’t cold or emotionless, he was just chatting to his brother, Matias, on Skype. And now he was back in the room, ushering me to sit down, already offering me a steaming glass of black coffee — a staple beverage for Finns throughout the year.

Awkwardness over, I booted up my MacBook Pro and opened Apple’s Keynote. Rather than bewilder Markus with the entire game design in one go, I’d prepared a short Steve Jobs-style presentation, explaining the multiplayer component of my game concept. The game was to be a multiplayer bat-and-ball game, featuring novel physics-based power-ups for an added twist.

The images that I’d prepared were mockups of the game screen, featuring arrows and captions pointing to the most important elements — describing the game-flow, control mechanic and graphical style. Markus loved the concept and insisted on immediately contacting Matias and Benjamin to enthusiastically pitch the idea to his team. The coders were on board; I had buy-in. Boom!

The Gospel of Games

With the team bought into the concept, the next step for me would be to produce what’s known as a GDD, a Game Design Document. This document is sometimes referred to as a Game Bible as, once written, it’s the point of reference for every single detail within the game.

Produced during the pre-production phase of a project, the GDD is a key asset during the game’s actual production. It provides guidelines for gameplay, user interface and menu flow, scoring and game rules. It will even include the game’s story, characters and location. Essentially, every detail of the game, no matter how seemingly inconsequential, is mapped out in this document before starting production.

The GDD defines the features and scope of the project; ideally, once production has begun, the GDD won’t change and will serve as a blueprint for the game’s development. Games being what they are — entire populated virtual worlds with their own distinct rules — they are particularly susceptible to feature creep. This project management issue occurs when new features creep in to the product design during the production phase — it drags out development, costing both time and money.

Feeling Doubtful

Over the past few days, since my meeting with Markus, my thoughts have been a flurry of game-related ideas, ready to throw in to the GDD before we begin production. It’s really happening and it’s so exciting to be part of the process. The team — Markus, Matias and Benjamin — are passionate about coding, so accomplished in their abilities, I feel lucky to be working with them.

However, my mind keeps returning to one question: Will this app really make it the App Store? It’s an exciting project indeed, but it’s such a massive undertaking and all the more intense because I’m documenting it in public, right here. It seems like an irrational doubt, but, we could be setting ourselves up for a big fall.

Gomi is a forthcoming iPhone game that blends Katamari Damacy with Mario Galaxy, rolling a recycling blob creature around tiny planets to clean up the trash. Based on the preview videos, the game looks fantastic, yet its release has been delayed for several months now.

My worry is that if one element goes awry (we lose a coder, the game mechanic isn’t fun, the scope is unrealistic, our project planning is off) we could end up delaying, or worse, shutting down the project. Everything seems to have run smoothly so far, but once we get into the nitty gritty of pre-production, I wonder if that will still be the case.

Next time: Marvel at the visual delights as I unveil my conceptual character artwork, delve in to the details of gameplay mechanics and discover what happens when a hardcore coder disagrees with a journalist-cum-designer. It’s all in the next thrilling installment of TheAppleBlog’s App Developer Diary.

Following closely on the official release of iPhone OS 3.0, Apple has seeded a developer build of version 3.1, build 7C97D, along with the SDK.

The point release appears to be more than bug fixes, too. A number of sites, including Gizmodo, are reporting features like:

• Faster boot time
• Bluetooth voice control
• Access to video editing through APIs for third-party developers
• Non-destructive editing of video by allowing saving of copies
• Fraud Protection, or phishing warnings, as an option in preferences for Safari

This discussion at MacRumors also has an interesting list of new features:

• A carrier selection preference, though apparently not for AT&T customers
• An MMS option, though again this does not apply to AT&T customers yet
• Saving video sent in e-mail to the camera roll
• Direct copying and pasting in the address book, no need to select edit first
• Copy and paste phone numbers to and from the phone keypad
• Canceling text messages as they are sent
• Choose picture size/quality for MMS video, where MMS is an option

As for fixes, the biggest problem, so far, relates to hardware of the iPhone 3GS, not the OS. Whether the new firmware helps with overheating issues has not been reported yet.

The speed at which Apple is updating the iPhone firmware is intriguing. From the final of version of 1.0 to 1.1, over two months passed, and nearly that much time from 2.0 to 2.1 and 2.1 to 2.2. Of course, this latest version of the iPhone OS is a beta, but it’s hard to imagine two more months will pass before iPhone OS 3.1 is officially released. One possible explanation might be that with the apparent early success of the Palm Pre, Apple feels the need to compete a little more aggressively. If so, bring on Windows Mobile 7.

Just about as far back as I can remember, every new release of an operating system has brought new features, additional functionality, and, unfortunately, more bloat. This applies equally for OS X and Windows, and in recent years has become even more prominent.

Windows XP was bigger than both NT or 98, Vista was far bigger than XP, and Windows 7 is shaping up to be bigger still than Vista. Panther included 150 additional features, Tiger brought more than 200, and Leopard brought north of 300, as well as a visual refresh and more dependence on the 3D interface. We can see a steady trend of increasing size and complexity for operating systems.

But while Microsoft is continuing that trend with Windows 7, Apple has opted to do something different. The company has taken a step back and started building a platform that is going to carry their operating system for the next 5-10 years. Snow Leopard includes “no new features.” Apple has decidedly spent the past year refining Leopard, stripping out old code, and building frameworks for developers to take advantage of the multicore, multiprocessor machines that it’s building.

But let’s be clear: To say that Snow Leopard includes absolutely no new features is kind of misleading. Snow Leopard does include new features, including some tweaks to the Dock and Exposé, a new Finder, and exchange support for iCal, Mail and Address Book.

That’s all well and good, but the real new features, the ones that matter, are all for developers. 64bit support, Grand Central Dispatch (GCD), and OpenCL will make applications developed for Snow Leopard faster, and able to take advantage of the power and capabilities of the new machines. Enabling 64-bit applications means that apps can now address more than 4GB of RAM (theoretically up to 16 billion gigabytes). The new GCD frameworks make it easier for developers to write code that executes on all of the available CPU cores simultaneously. OpenCL enables developers to tap the unused power of the graphics cards to speed up their applications even more. Snow Leopard is more than an OS, it’s a platform built for developers.

And yes, Apple is dropping support for PowerPC. I’m assuming that stripping out the Rosetta code and the PowerPC code from universal binaries is one of the ways Apple has saved so much disk space in Snow Leopard when compared to Leopard. Although, as awesome technologies go, Rosetta certainly ranked high.

To get Snow Leopard to as many Macs as possible, Apple is going to try very hard to push how much faster all the built-in applications run. However, the real benefit from Snow Leopard might not be seen until the developers catch up. Large, professional applications like Apple’s own Final Cut Pro and Adobe’s Photoshop might see the biggest benefit from taking advantage of the new technologies.

What Apple has done is shift away from adding more and more code and features into OS X, and instead concentrate on making what’s in Leopard lighter, faster, and stronger. It’s the right thing to do. Snow Leopard might be a hard sell at first, which I’m assuming is why it’s competitively priced at $29, but roughly a year after it comes out, when more developers have had a chance to build on it, I believe we are going to see a line drawn in the sand. There will be the apps before Snow Leopard, and then there will be everything that comes after it. Leopard is a transitional OS, the prequel, and Snow Leopard is the main event.

When Apple revamped its operating system and adopted Nextstep as the base of OS X, they brought along with it an extremely powerful version of Unix based on the open-source project FreeBSD, now known as Darwin.

Unix has a long history, one that started in the basements of Bell Labs by a group of AT&T engineers some 40 years ago. A professor in a C programming course I took once said that they were supposed to be writing drivers for the AT&T hardware, but instead, they wanted some way to use the system to play games, so they invented Unix.

Unix is now a mature and robust operating system, and since OS X is based on Unix, it has inherited all of its power, and some of its complexity. The beautiful aqua interface that we are used to seeing is really all that is needed, but if you would like to take a look at what makes your computer tick, Apple included Terminal.app to act as a window into the GUI and into the Unix soul of OS X.

Nick started a great series back in January 2007 on this subject, and now I’d like to cover some of the basics again, and maybe bring a different point of view to the table as well.

Open Terminal.app (found in Applications → Utilities), and you’ll see a window with a prompt waiting for you to start typing.

At this point, it’s important to understand a few things about the Terminal. For one, the commands that you can type are interpreted and carried out immediately, no waiting around. So if you tell it to remove a file, it will do it right then, with no easy way of recovering it. There isn’t a recycle bin on the command line (not without a little coaxing, anyway). Secondly, since Unix was developed decades ago, many of the commands seem a bit archaic. Back when most of these utilities were written, they were all abbreviated to save space and cut down on the number of keystrokes you’d need to type. Below is a list of a few essentials, and another list from Nick’s post is here.

• ls (list): Probably one of the most important commands, it lets you see what’s in your current directory.
• cd (change directory): This is how you move about the filesystem in Unix, for example, to move from Library to Documents.
• file: This one isn’t short for anything, but it will give you a brief description of what a particular file is.
• cat (concatenate): Or “Grab everything in this file and let me read it.”
• man (manual): The online manual will describe most commands that you’re interested in; for example, typing man ls will give you the manual page about the ls command.

It might be helpful to open a Finder window and put it right next to the Terminal. Open the Finder so it shows your home directory. Type ls in the Terminal to see the same files that you see in the Finder. Try another command: touch. touch is designed to change the last accessed timestamp of a file, but it will also create a blank file. You can see the file created in the Finder as well. You can cat the file, and see that there is nothing in it.

Now that you’ve created a file, and looked at its (blank) contents, you can remove the file using the rm command. This is one of those dangerous commands that, if used carelessly, can really screw things up. For this example, carefully type rm file into the terminal, and watch the file disappear in the Finder. You’ll notice that your Trash stays empty — that file is goners.

The Unix filesystem is a nested hierarchy, with each directory separated by a forward slash (/). The current working directory is symbolized as a dot (.), and the parent directory is symbolized by two dots (..). The top of the hierarchy, known as the root, is symbolized by a single forward slash.

So, to move to the parent directory, you could type cd ... If you were in the Library directory and you typed this command, you would then be moved into your home directory. To see the very top of the hierarchy, you would type cd /. Type this command now.

Also, move in the Finder to the hard drive where you have OS X installed. I have mine named, originally, “OS X”. Type ls in the Terminal, and you’ll notice a few more files than you can see in the Finder. These files are important Unix system files, and should not be touched unless you really know what you’re doing…and really, not even then. To illustrate the importance of these files, you could type file mach_kernel.

This is the kernel, the core of the operating system. Do not mess with this file. Several of the other files are directories. You can change directories into /bin, for example, and type ls to list the contents of that directory. You’ll find a file in that directory named “ls,” which is the executable for the ls command. When you type ls into the terminal, it executes this tiny app. A great place to learn about Unix is to get a list of this directory, and then read the man page for every file listed.

To exit the Terminal, just CMD-Q like any other app, and you are back in the comforts of OS X.

This has been a very brief overview of how to go from absolutely no Unix knowledge whatsoever to the smallest amount of Unix knowledge necessary to poke around a bit. There’s a lot of power under there, but before you can really start to harness it, you need to get a decent understanding of the hows and whys.

An early version of Chrome is now publicly available for Mac users, at least what there is of it. As the Chromium Blog glibly posted, this release is intended for developers who take “great pleasure in incomplete, unpredictable, and potentially crashing software.” Having caveated that, Chrome feels fast, faster than Safari, and that is saying something.

Something else to be said in favor of Chrome is that it’s stable. Not that this release doesn’t crash — it does, but it just dies gracefully. Unlike Safari, which upon crashing takes all your browser windows down to the grave, Chrome displays a “sad tab of death” for the single offending browser instance. Similarly, isolating browser instances benefits security, and security for Chrome is also boosted by periodically updated blacklists of malware and phishing urls.

What's wrong with this UI picture? Look at the tabs.

On the negative side, “developer preview” is arguably a euphemism for alpha release, with all the negative connotations that implies. Something as basic as resizing the main window demonstrates in jaggy, tearing detail how far Chrome is from completion. Just some of Chrome’s missing features include:

• Flash is right out (but javascript seems pretty robust)
• Printing and saving pages
• Bookmark importing and organization
• Privacy settings, passwords, and autofill
• Full screen display

Nonetheless, even at this nascent stage of development, Chrome for OS X is impressive. Mac users should definitely be looking forward to it in their future.

Programming for the iPhone is still pretty new. It might be a bit tougher to find iPhone developer resources, but we found a bunch that will get you through building any iPhone app you might be starting on. Check out our list of our favorite developer books, blogs, podcasts, screencasts, open-source libraries, communities, forums, conferences, training, and more!

Books

Beginning iPhone Development: Exploring the iPhone SDK

This is the go-to book for beginning iPhone developers by Jeff Lamarche and Dave Mark. It takes you from downloading the SDK to creating your very own apps. The official page and support site: http://iphonedevbook.com/

Programming in Objective-C 2.0

This is the book to get if you’re just starting out programming. It assumes you have no prior programming knowledge before picking it up. It’s highly recommended for people who don’t know any programming and want to learn Objective-C. Not a lot of iPhone-specific stuff in this one, but a lot of this knowledge will carry over when you do want to create iPhone apps.

Cocoa Programming for Mac OS X

This book assumes you know a bit of C/C++, and it’s a really good book for getting started with Apple’s developer frameworks. There isn’t a lot of iPhone-specific stuff in this book, but a lot of what you learn carries over into iPhone development.

Pragmatic Programmers iPhone SDK Development

This book is in beta still, so you can only get the PDF. It was originally scheduled to be released by now, but they are updating it to include iPhone SDK 3.0. It’s still worth it to get the PDF. I’ve gone through it, and it is fantastic. The book is now set to be released in September.

The iPhone Developer’s Cookbook: Building Applications with the iPhone SDK

This book is full of code snippets that will help a lot of people with common tasks that Apple’s iPhone SDK doesn’t provide. There are some code blunders in this book, but luckily they’ve fixed the code and put it up here. They also have movies at this site that demonstrate what each mini-project does.

iPhone in Action: Introduction to Web and SDK Development

The iPhone in Action book covers both native and web programming in step-by-step tutorials. It’s a complete primer to iPhone development.

Blogs

Mobile Orchard

The best iPhone developer blog I’ve seen. It’s written by Dan Grigsby and Ari Braginsky. I recommend you start with the top posts on the right sidebar and go through all the archives. Pretty much all of the articles are gold.

iCodeBlog

This blog has some of the best iPhone app building tutorials on the web. They have newbie tutorials as well as multi-part advanced tutorials ranging from Hello World to game development. The “ToDo List Using SQLite” tutorial series is a good start for a new developer to learn a breadth of concepts.

iPhone Development Central

The meat of this site is the video tutorials. The videos are separated into different levels of complexity. Good site for audio/visual learners.

Dr. Touch

Dr. Touch gives us a mix of specific programming solutions as well his experiences with the App Store and his sales. The recipes section of his blog have really useful code snippets to help you build your app.

iPhone Development

Jeff Lamarche is also the author of Beginning iPhone Development: Exploring the iPhone SDK. He keeps his blog updated constantly with cutting-edge code and even a guide to surviving WWDC.

Keyvisuals iPhone Development

This blog isn’t updated as often as some of the others, but the articles that do come out are really useful. My favorite recent one is How to Detect Network Availability.

71squared

71squared has some great iPhone game development tutorial collections. It is updated quite often, and anyone interested in iPhone game development should check it out.

How to Make iPhone Apps

It’s a fusion of iPhone app marketing and coding. Most of the site is focused on marketing your app.

iPhone SDK Articles

This blog isn’t updated that much these days, but the articles are still useful. It’s 100 percent dedicated to code tutorials.

148apps.biz

Jeff Scott writes about various iPhone app marketing tips and analytics. The blog is focused on the business side of iPhone apps. It’s fairly new and looks very promising.

iPhone developer:tips

A how-to focused blog run by John Muchow. The posts are put together in nice bite-size pieces.

PrEV

Bill Dudney is an author/screencaster with the Pragmatic Programmers family. The books and screencasts he makes are good for beginners, but a lot of the stuff on his blog address more complicated coding issues and bugs in the SDK.

Podcasts/Screencasts

Stanford iPhone Application Programming Course

Stanford open-sourced its lecture, slides, and course material to the world. It’s available for free in iTunes. Watch the presentation by Loren Brichter of Tweetie fame when you get a chance.

Mobile Orchard Podcast

Awesome podcast series with iPhone app developers and their successes (and struggles) running iPhone app businesses. They always have A-list guests.

Pragmatic Programmer’s Screencast Series

If you’re more of a video learner, start with the Coding in Objective-C 2.0 and Becoming Productive in Xcode screencasts. Follow that with the five-part Writing Your First iPhone Application screencast. If you really want to get fancy with transitions and animations, check out the Creating a Compelling User Interface with Core Animation screencast.

Objective-C for Rubyists

Peepcode is usually known for its Ruby resources, but it has a great screencast that teaches you about Objective-C. It’s edited by Scott Stevenson of great Objective-C resource, CocoaDevCentral.

The App Show

Great conversations about everything related to iPhone apps. The podcasts are about an hour or so long.

iPhone Alley

The iPhone Alley Podcast is a weekly roundtable with different iPhone app media peeps and creators. Each episode is very entertaining.

Schenk Studios

This site has some great video tutorials — and a lot of them, too. He’s made 25 of them, including a sneak peek at some new 3.0 features.

Open-Source Libraries

Joe Hewitt’s Three20 Open-Source Objective-C library

Three20 is a collection of iPhone UI classes, like a photo viewer, and general utilities, like an HTTP disk cache. Three20 is derived from the Facebook iPhone app, which is one of the most downloaded iPhone apps ever.

Bullet Physics Engine

Bullet is a free, professional 3D game multiphysics library used in some popular games in the App Store.

Cocos2d Framework

Cocos2d for the iPhone is a framework for building 2D games for the iPhone and iPod touch. There’s a great community around this open-source engine, so there’s plenty of support to help you get your iPhone game out there.

Matt Legend Gemmell – Cocoa Source Code

Matt Gemmell has some great code out there for the community, including MGTwitterEngine, the Twitter API used in iPhone apps Birdhouse and Twitteriffic.

Appsamuck

An open-source collection of 31 mini-iPhone app projects to get you up and running fast.

Communities/Forums

iPhone Dev SDK

The greatest iPhone developer community on the Internet. Chris Stewart’s site boasts nearly 6,000 registered users. The forums are very active. You’ll find yourself visiting this site at least once a day.

Stack Overflow

Stack Overflow is a collaboratively edited question and answer site for programmers — regardless of platform or language. Every question asked on the site will almost always get a correct answer.

MacRumors Forums for iPhone Programming

Great community of developers on this forum. They even include some nice guides for getting started with iPhone development.

Conferences/Training

Apple Worldwide Developers Conference

WWDC is Apple’s official developer conference. All the cutting-edge programming topics are taught here. The 2009 one runs from June 8-12. WWDC is the Mac daddy of all iPhone conferences. Get it? Mac daddy? I’m here all night, folks.

360|iDev

360|iDev is the premiere iPhone, iPod touch developer conference in the world. The next one will be a four-day event and will take place September 27-30, 2009 in Denver, Colo. They have a call for papers right now if you want to make a debut as a conference speaker.

Pragmatic Studio’s iPhone Development Course

Here you will learn how to build iPhone applications from experienced iPhone developers Bill Dudney and Daniel Steinberg in this four-day training course. The next one runs August 4-7, 2009 in Reston, Va.

iPhoneDevCamp

iPhoneDevCamp is the brainchild of Raven and Dom. The event format is “unconference” or Barcamp-style, featuring content from the participants themselves. There are satellite events held all over the country. The next one is this August.

Game Developers Conference

This conference is for all game developers, and there’s an increasing number of mobile app game developers. If you’re a game developer or want to be one, this is the one game developer conference to go to.

StackOverflow DevDays

This is more of a general developer conference, not just iPhone developers. The beauty of this conference is that it’s in multiple locations and dates, and it only costs $99. Plus, you get to hang out with Joel Spolsky.

Other Collections Of Resources

Apple’s Official iPhone Dev Resources

The Apple engineers give us a lot of information to get started with app development. There are a lot of resources that Apple provides including documentation, how-tos, videos, code samples and forums.

iPhone Flow

This site is updated daily with the best iPhone developer links on the web. It’s driven by the community submissions, and all the links are top-quality here. The site is maintained by the Mobile Orchard crew.

XCake iPhone Dev Resources

MattJ’s collection of iPhone developer resources. A lot of good stuff here including our very own Create A Drum App tutorial.

The Flying Jalapeno Lives

Great list of iPhone development blogs written by Corey.

Those are my favorites. I’m not a human Google, so I may have missed some gems. What are your favorite iPhone developer resources?

The real core of the video game industry has long been Japan, where it enjoys a pop culture status that Western studios can only hope to one day achieve. It stands to reason, then, that a good barometer for the iPhone’s success as a gaming platform would be Japanese industry interest in the device. A recent survey by Japanese middleware developer CRI suggests that interest is very high indeed.

CasualGaming.biz details the report, which found that of 102 game studio representatives surveyed, 87 percent responded in the affirmative when asked if they were interested in developing for the iPhone/iPod touch platform. Nearly 20 percent had, in fact, already done so, and another 16 percent already had games in the works. Thirty-eight percent said there was corporate motive, but that they’d yet to make any concrete moves. Maybe they’re holding out to see what exactly iPhone OS 3.0 is capable of.

Either way, the survey reveals other interesting details about why the iPhone is the most popular smartphone platform for development among Japanese game companies — and also about how far behind its competitors are lagging. Android, the next most appealing platform in the survey, garnered interest from only 47 percent of respondents, while the much-hyped Pre intrigued a dismal 6 percent. I suppose not having really seen the device in action in the real world tends to lessen its appeal to profit-driven businesses.

In case Apple wants to increase its developer base, the survey also asked about what were the biggest impediments to iPhone development, and at least one of the answers suggested that Apple is either very clever, or foolishly stubborn. Half of those surveyed felt that the biggest drawback to iPhone development was that they had to do so on a Mac.

So, Apple could probably add even more apps to its extensive library by opening up development to other platforms but, on the other hand, the respondents said it was a drawback; they didn’t say it deterred them completely. The appeal of iPhone development is probably actually driving Mac sales to game studios, which is likely worth more to Apple financially than the addition of yet more content to the already very healthy App Store.

For this installment of the App Store Roundtable, we talked to developers about analytics. On the web we’re spoiled when it comes to analytics. Simple plug-ins allow us to track where visitors come from, and what they look at. We can also use this information to track purchases and referrals over many months. It’s a different story in the App Store, and many developers feel that the lack of quality analytics is hindering their marketing efforts.

Why don’t I know ANYTHING about the people that are looking at my store front. The biggest one is how many people that click on my app, actually buy it. I would love to compare the performance of different screenshots, especially the first one, and see what kind of conversion rate I’m getting. What about how many people are clicking through to my site, and how many of those go back and buy? Or what percent of my customers are reading more reviews than those on the front page?

– Evan McMahon of Veiled Games, developer of Up There

Absolutely! Not knowing where sales are coming from hurts us in two different ways:

1. Hard to tune our marketing strategies. What’s working and what’s not working? How much is it coming from a lite version vs. ads vs. reviews? Impossible to tell.

2. Impossible to set up sales-based partnerships. I actually talked to some flower companies about doing something together for Flower Garden. The idea being they can advertise Flower Garden in their web site or emails and they get a percentage of those sales. But we have no way of tracking how many sales came from there!

– Noel Llopis of Snappy Touch, developer of Flower Garden

We’ve had some success using the LinkShare affiliate program to track an app cross-promotion experiment that I ran with my friend – it was a little “ad” in Scramboni for another app that helps you learn SAT-grade words. We were able to get something like a 12% click-to-purchase ratio. LinkShare allows you to track marketing efforts from clickthroughs to purchasing, and gives you a commission on every copy sold.

– Peter Bakhyryev of Byteclub, developer of Scramboni

I go to great lengths to try to track the efficacy of my marketing efforts. I can track data right up to the point where a user enters the app store, but at that point it’s a black box. How many users who visit my app page buy the app? How many users search for a lite version after visiting the full version page? How many users who downloaded the Lite version bought the paid version? How many users found my app’s page because of a search? All of this data would make me feel more confident in spending more money on advertising and marketing. Don’t get me wrong, I appreciate how much information we get right now, but I’d love to have a lot more.

– Owen Goss of Streaming Colour Studios, developer of Dapple

Apple does a great job of taking care of things once an app arrives in the store itself, but they expect the developer to take care of the marketing aspect after that. It sounds like a reasonable proposition, but the reality is that there isn’t enough information available to developers to effectively do that for reasonable costs (particularly for the price tier 4 and lower apps). It’s essentially impossible to tell what marketing efforts have an effect on sales and which do not.

– Adam Byram, developer of Budgee

Join us next time?

If you’re an iPhone developer with App Store experience and would like to participate by sharing some opinions in future App Store Roundtables, please get in touch via our contact form.

Yesterday, people registered as paid iPhone developers received an email alerting them to the availability of a new version of the Associated Press News app via a temporary, exclusive code. The purpose of the app is to test high-volume live push notification and its effect on Apple’s servers before the function goes out live to all iPhone users in June at WWDC.

The app, which expires in seven days, appears to only be available through the U.S. iTunes store, which doesn’t seem to have stopped Apple from sending out emails to all developers, regardless of their country of residence. The email specifies that devs should choose U.S. English as the app’s default language at first run, which suggests that they are fully aware that people already have or are able to create U.S. store accounts without actually being residents.

A forum thread on MacRumors details some developers’ progress so far with the test app, which is varied. Some, like Ben Dodson, have successfully received push notifications from the app (check out a lengthy post on his blog for details and screenshots). Others have yet to receive any notifications at all, myself included. A cursory survey of those who’ve also been unable to receive any push updates from AP finds that most, if not all, are located outside of the U.S., but I don’t have nearly enough information to cite that as the definite cause.

Chime in and let us know your experience if you’re also helping Apple test the app.