We mentioned Gamesalad's plans to bring their publishing system to the iPhone earlier this year, and now they've done it: for $99 a year, they say that you'll be able to design games on their game creator development tool, and then publish them straight out to the iPhone's App Store. If you don't want to bother publishing the games yourself, you can create them and have them "viewed" through the Gamesalad Viewer (which we couldn't find on the App Store quite yet), or you can export them out as full applications and publish them as your own iPhone apps (Flutterby is in the store right now as an example of a Gamesalad Creator game).

There's also a $1999 membership service that lets you customize every aspect of your games, and provides you with direct customer support, which is supposed to be for "elite users" (like, we guess, actual game companies). And truthfully, I've developed a few apps using just Xcode, and it's not too big a deal (though I've never had to go through an actual release or worked with end users, which I'm sure is most of the battle anyway). But if the thought of using professional coding tools to develop your little game idea sends you into panic attacks, and the Gamesalad creator seems more your speed, this might be a nice viable way for you to turn your gaming idea into App Store gold.

It costs nothing to download and try out the creator, so if the idea interests you, you can work on putting a game together, and then pay later when you decide you've got something you want published on the iPhone. And hey, if you do put a game up, be sure to send a tip and let us know -- we'd love to see the end products of this process.

It appears that the Dev Center at Apple just updated its documentation set today. If you're using Xcode 3.2 and you want to update your documentation, you might be looking in the wrong place.

Before 3.2, you used to update your documentation in the Developer Documentation window (Help > Developer Documentation, or Command-Option-?). Now you'll find your documentation sets in the Xcode Preferences window (Xcode > Preferences... or Command-, and then choose the Documentation tab). Also, if checked, Xcode will automatically update your documentation when you launch it.

This Documentation panel offers subscription options for installing a documentation set (such as, for example, Mac OS X Legacy Library or iPhone OS 2.2 Library) as well as a handy Check and Install Now button that lets you request the latest updates. Use this to keep on top of the latest documentation updates.

Thanks, Scott Lawrence and @zadr

More Xcode daily tips for Mac and iPhone developers.

Back in the old times, when dinosaurs roamed the earth (and used less sophisticated IDEs), Interface Builder offered a built-in class browser as part of the project window. This browser allowed to you navigate through the Objective-C class hierarchy, and add subclasses along with instance variables and methods. You could generate files from those classes as a skeleton for further development.

Then for a while, the class browser went away. And it was missed. But it is back again. New to Xcode 3.2, the Interface Builder Library pane hosts an updated class browser. This new subpane combines features that have recently been in the Class Identity Inspector (namely, adding outlets and actions to a class) with the ability to generate new subclasses from existing classes.

So how does it work? I may be a brontosaurus but I prefer the old style browser to the new style "Lineage" display shown here. The new pane is certainly pretty, and it fits in well with the Library pane concept of collecting elements that are universally used throughout a project, but it lacks a certain ease-of-browsing that the old tree-style presentation used to give.

All aesthetic and usability concerns aside, it's important to know that the Outlets/Actions interface has moved from its prior home into a new one. The interaction objects remain essentially unchanged. Use the + button to add outlets and actions, the - button to delete them. Double-click the default types to change them to a different class.

You can locate a class by entering a string into the search field at the bottom of the pane. The pop-down action menu on the bottom-left offers a number of class-related functions including subclassing, displaying group banners in the class list, writing out updated class files, and more.

More Xcode 3.2 tips for Mac and iPhone developers.

The LLVM/Clang static analyzer bundled with the Snow Leopard developer tools automatically detects a variety of memory management bugs in Objective-C programs. It's a terrific tool for finding memory leaks and other issues and it is now easily available to all developers, both for the Macintosh and iPhone platforms.

I first learned about using the analyzer with iPhone projects from a blog post by Joe Heck of rhonabwy.com. Heck pointed out that the Intel-only analyzer worked with the Intel-based Simulator code generated by the iPhone SDK, letting you use the analyzer with your iPhone projects.

At that time, you had to download a copy of the analyzer, install it by hand, and run it from the command line. It was amazingly helpful but a bit of a pain to use.

No more. Xcode 3.2 incorporates the static analyzer tool directly into its IDE. Choose Build > Build and Analyze (Command-Shift-A) and the analyzer automatically checks your code. and presents any bugs detected by the analyzer. Static analysis evaluates source code to automatically find bugs, issuing hints that are similar in nature to compiler warnings but targeted at Foundation (Cocoa) and Core Foundation memory management.

Each bug is marked with a blue icon and a description. I do wish that the text didn't seem to "cut off" so abruptly. Resizing the Xcode editor window does not affect the hard right alignment of the bug reports. This bug refers to the local watcher variable, which is allocated and initialized but not released.

The tool is not perfect. It may flag nonexistent "bugs" in programs, so there are definitely false positive results that will show up as well as gray areas. In this example, the watcher is used until the application teardown, so the fact that it's leaking is not really a problem. That having been said, the analysis is amazingly helpful and if you do find real bugs, the Clang Static Analyzer team solicits bug reports.

To learn more about your bug, click the blue branch icon in the code itself. The analyzer offers a detailed view of the bug and its issues. This presentation provides more information about the specifics of the issue at hand.

In this detail view, clicking any single blue arrow opens the Build Results pane, showing the analyzer result list. Hide or show analyzer information by clicking the blue branch icon in the left gutter.

It's easy to overlook the new built-in static analysis feature of Xcode 3.2, but you'd be missing out on a great feature if you didn't explore it further.

It's a Menlo world in the new Snow Leopard Xcode. 10.6's Xcode uses the Menlo Regular-11 font for the standard Xcode template. If you miss Monaco (and I know I did), it isn't hard to restore the look and feel of Xcode 10.5's defaults. That's not to say there's anything wrong with Menlo. Menlo is a lovely font. It's just not a familar font and some strange part of my brain keeps freaking out every time I look at the screen.

I'll probably force myself to adapt to Menlo at some point but for the moment, I'd rather just stick with Monaco. So to do that, here are some quick instructions. As you'll see you'll need to create a new theme based on the Xcode default theme and update its font settings.

To start, open Xcode > Xcode Preferences (Command-,). Choose Fonts & Colors. Select the Xcode Default theme and click Duplicate. Enter a name for the new theme (e.g. Normal Xcode Theme) and click OK. Select the new theme, and then select all categories within the theme. To do that, click on any item and then choose Edit > Select All (Command-A).

With the categories all selected, double-click in the font column. A font panel appears. Select Monaco 10 in the font panel and then close the panel. Click OK in the preferences pane and boom. You have returned to a font comfort zone.

Got any Xcode font preferences? Can you recommend a font that's better than Menlo, Monaco, or the good old standby Courier? Let us know in the comments.

For those about to code, we salute you.

Developers: are you ready to upgrade your new Snow Leopard install to Xcode 3.2? The Xcode installer package appears in your Snow Leopard disc's Optional Installs folder. Double-click the mpkg file to open the installer and begin the installation process.

Xcode 3.2 offers a number of really great new features, several of which will be highlighted in upcoming daily tips. Standouts include the new built-in static code analysis, the two new LLVM compiler front ends (GCC 4.2 and Clang), and the new Build Results window.

Until you install, you may run into problems using the standard C compiler from the command line. (It threw errors about not finding <stdio.h>, etc.) This despite the fact that I had already re-installed the iPhone SDK.

Once I upgraded to the new Xcode, and rebooted, the command line cc started working again. The reboot step seemed necessary because cc didn't work until I did so. There might have been a less extreme alternative I'm not aware of to use instead. (If you know of one, please let me know in the comments!)

You'll need to re-install your iPhone SDK packages as well. Make sure you download the SDK versions that were built specifically for Snow Leopard. The iPhone Dev Center provides both Leopard and Snow Leopard SDKs for each of its standard and beta distributions. Install these packages after upgrading to Xcode 3.2. I did not and ran into trouble with project creation (as well as the already mentioned command line cc) until I finally got the install order corrected.

Update: Remember, the iPhone SDK packages do not include Xcode 3.2, so just downloading the iPhone SDK for Snow Leopard will not upgrade Xcode.

Thanks go to hatfinch for his help.

At times, iPhone developers might like to test out applications without going through the formality (or challenges) of ad hoc distribution. Ad hoc distribution was introduced by Apple to allow software testing on up to 100 registered devices. It is, admittedly, a bit of a pain.

Developers must collect device information (the "UDID", aka their unique device identifiers), register that device at the iPhone developer portal, create an special provisioning certificate, add a special entitlement, and build an ad-hoc only version of their software to distribute along with that certificate.

If all that seems like a hassle, well, yes it is. It is, however, the proper, authorized, and recommended way to distribute pre-release software, whether for testing or reviews. But there is another way.

If you know for sure that your target audience is another developer, the process becomes way easier. You can simply compile a normal development build of your application and send a copy of that build to another developer.

That's because each registered developer has the ability to sign applications. Although the app was built to work with just the in-house devices you've registered for development, another developer can re-sign that application using the simple command-line script shown here.

#! /bin/bash 
export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform\
/Developer/usr/bin/codesign_allocate
 
codesign -f -s "iPhone Developer" $1.app

This script uses Xcode's codesign utility to sign the already compiled version of the application. Once applied, you can then install the application through Xcode.

So is this a general distribution solution? No. And thank heavens for that; free trading of app binaries would rapidly lead to piracy. This approach allows developer-to-developer testing and collaboration only. The development signing is limited to the units you have personally registered.

If you want to try this out, follow the link at the start of this post. It leads to a testing folder I keep around and occasionally stock with software that I need tested. It also includes a copy of the script, which you must make executable (chmod 755 signit).

I love hearing this about the iPhone: the San Francisco Chronicle has a piece about how Apple's little revolutionary telephone has brought a whole new crop of programmers into the development mix. People who had never before looked at code or considered writing their own applications are getting ideas about how to make better software, picking up Cocoa and Xcode books, and going to town. And strangely, we might actually have fart apps to thank for this -- people aren't just seeing the iPhone as an innovative platform, but they're seeing the App Store as an "anything goes" environment, where even their silly little idea might work.

I don't know if we can pin all the credit for the burgeoning iPhone development scene on fart apps and the impression that even a monkey can make bestselling iPhone software (certainly Apple has set the bar and price for entry pretty low, both with the extremely cheap $100 fee for a developer account as well as the high quality Xcode software that comes on every Mac), but there is definitely something in this little device that's driving people to try and create their own software for it.

Oh, and the money probably helps, too. Still, whether people are taking up iPhone development because they want to make millions or are just looking for another hobby, it's us, app consumers, who will benefit.

In the last iPhone Dev 101 post, I told you a little about creating your first project using Xcode; however, in this post, I want to show you how to create your first application that will run in the iPhone simulator. In honor of staying with the classic way of teaching programming, we'll create a "Hello World!" application as our first one.

Creating the new project
If you have installed the iPhone SDK/Xcode, then you can launch Xcode by navigating to /Developer/Applications. Once there, you can double click on the Xcode application (you may also find it handy to just drag the icon to the dock if you will be using it a lot).

Once Xcode launches, click File > New Project. Under the iPhone OS section on the left side of the resulting window, select "Application." Select "View-based Application" from the templates that show up on the right side, and then click the "Choose" button. You will then be prompted to specify a project save name -- this will also be the name of your resulting application, so choose your project name wisely.

You're project has now been created, and the Xcode window that is displayed will contain all of your code, resources, etc. There isn't much there now, but the application is fully functional at this point. You can click the "Build & Go" button in the toolbar, and the application will be compiled and launched in the iPhone Simulator. Again, this is a fully functional application, but it doesn't do anything useful at this point -- the usefulness of the app is up to your coding, but Apple supplies you with the base code and dependencies.

In our last iPhone Dev 101, a continuing series on iPhone development, we talked about resources that you can use while you are coding with Cocoa. In this dev post, I'm going to walk you through Xcode and creating your first project.

First we need to open Xcode, so once you have the SDK installed, you'll need to open /Developer/Applications/ and look for Xcode.app. This is Apple's IDE (Integrated Development Environment) that allows you to code, debug, test, and build all of your iPhone and Mac applications. When you open this application, nothing specially really happens, although you might see the welcome center -- if you see this, you can choose to disable it at startup by using the check box at the bottom.

To create a new project, select File > New Project. In the resulting window select iPhone OS Application > View-based Application, and click "Choose." You will then need to specify a save name and location for the resulting files that will combine to create your application. In the resulting Xcode window, you should note that most of the work is already done for you!

At this point you have a fully functional application. Try it out: click the "build and go" button at the top of the window and wait while the app is compiled and opens in the iPhone Simulator. The app definitely doesn't do much, but still, it's a running application you made without writing any code.

Continue reading to learn more about Xcode, and get a brief UI overview.

The Daily Mail has reported the story of our friend Simon Oliver, creator of Rolando (whom we interviewed quite a while ago when the game originally came out). Apparently things have worked out very well for him -- the game has sold 700,000 copies so far, Oliver's set to be a millionaire, and he's now, as he says, the head of a game studio that already has a hit under its belt. Very impressive (too bad they still call him a geek).

It's stories like this that are pushing the little App Store bubble we've got going nowadays -- every investor with money to spare (not as many as usual, given the current economy) is happy to sink it into releases for the iPhone, and while there is plenty of money being made, not every developer ends up like Oliver (let's not forget he had a quality product in the first place).

But there is some good news here: without the App Store and the iPhone platform, this never would have happened. Say what you want about Apple's release policies or their initial "no SDK" choice, but with the iPhone, they've brought development and distribution down to anyone who can dream it.

Cocotron is a potentially exciting open-source project that "aims to implement a cross-platform Objective-C API similar to that described by Apple Inc.'s Cocoa documentation." What this means is that, in principle, Cocotron would allow an OS X Cocoa app written in Xcode to be easily cross-compiled for other OSes, particularly Windows.

Of course that in principle still leaves open a bunch of practical difficulties. The guys over at Magnetism Studio (developer of FileMagnet for iPhone) have a great account of how they used Cocotron to port their Mac FileMagnet Uploader to Windows. Of course it wasn't as easy as pressing a button and having a Windows executable pop out of Xcode, but after suitable adjustments (particularly to get rid of Mac-specific code) it did make a Windows version possible. In any case, Cocotron seems poised to make cross-platform development a much less costly and time-consuming process for Mac developers.

Cocotron itself is a free download and released under the MIT license.

[via Daring Fireball]

Apple has posted an interesting new tutorial on developing OS X applications with MacRuby. MacRuby is an implementation of the Ruby programming language "ported to run directly on top of Mac OS X core technologies such as the Objective-C common runtime and garbage collector, and the CoreFoundation framework."

What this means is that applications written with MacRuby can be a full-fledged Cocoa application with all the advantages that entails. The tutorial will take you through the process of installing MacRuby as well as building a sample application with Xcode. So if you've ever wanted to get started thinking about developing for the Mac, but have always been intimidated by Objective-C (which pretty much describes me), playing around with MacRuby might be just the ticket to get you started.

[via MacVolPlace]

If you're curious about developing for the iPhone, but haven't made the plunge yet, you might want to read Rogue Amoeba programmer Mike Ash's 22-step tale of developing NetAwake, which is available in the App Store.

It's a fascinating story, with a lot of waiting, a lot of rejection, and a lot of "screwing about in Xcode."

"The errors are essentially worthless. I believe I only ever saw Xcode generate one error, over and over and over again, as it encountered a whole bunch of different problems," he wrote.

The app took a month to approve, once it was submitted. Ash says that the people he corresponded with at Apple were "nice about responding to my query" but "spending a month in limbo for a single bug is a very poor tradeoff."

I unabashedly love TextMate, and I love my TextMate themes. I do, however, spend a fair amount of time in Xcode, which is why I was excited to find XThemes. With a little bit of drag and drop, you can convert any TextMate theme -- in all of its splendor -- into an Xcode theme.

Yes, it's for a limited audience ... namely TextMate die-hards who also use Xcode frequently enough to miss the themes they love (and have probably spent a fair amount of time tweaking). If you fit into this niche, you'll definitely want to take a look. XThemes: $0. Feeling at home coding outside of TextMate ... priceless.