The My Dream App web site opened this week to a great deal of publicity. Reaction from bloggers and the press has been mostly positive, I think because it’s a truly novel concept. This is an innovative gimmick that will generate a great deal of publicity for everybody associated with it, and that’s about where my admiration for the idea ends.

Am I just a cranky developer who wishes he had thought of the idea first? No! Well, cranky, yes. But I know at least a little bit about how good software gets made, and it doesn’t happen when a small team of developers is forced by contractual obligation to implement three separate projects, none of which came about from their own inspiration or passion.

Summary of the official rules: lots of people send in ideas, they get whittled down to 24. Then these ideas get narrowed down to three winners whose app designs get developed and marketed as shareware. The winners get 15% of the profits while the rest is split up somehow by the My Dream App team. Now, it would be one thing if the team got to pick their own burden, but the decision will be made by popular vote:

Registered users of the Contest website will narrow the field of twenty-four (24) Finalists to three (3) Winners through five rounds of popular voting.

The three winners give up any rights to benefit independently from their idea (a shaky legal restriction, if I ever heard one):

If a Submission is Accepted (and thereby becomes MDA’s property in accordance with Section 7), You do not use any information or material in the Submission for Your own personal gain.

Ideas can become property? Only if they’re patented, and you can’t patent something after it’s been made public. But the worst part is what’s in store for poor Austin, Jason, John, and Martin, the contest’s software developers. Who knows what motivations they had for agreeing to participate in this event, but it looks like a raw deal from where I’m sitting:

MDA Has the Obligation to Develop an Accepted Submission. After a Submission is Accepted (the 3 Winners), MDA has the obligation to put forth all reasonable effort to develop a product based upon the Accepted Submission and release it for commercial gain.

We can’t see the contents of their legal agreements with My Dream App, but it would appear that they, or somebody else in their stead, will be compelled to develop three applications whose specifications are unknown, without pay and in exchange for notoriety and a cut of future profits. If there are any. If somebody came to me with a contract like that I’d tell them they were out of their freaking mind. If they’re lucky, they’ll end up with three winners that the team can actually get fired up about. If they’re not, then the fulfillment phase of this arrangement will be a nightmare, indeed.

My Dream App celebrates what I think is an utterly false notion in software development: that ideas are golden. Ideas are practically free. They run like flood-water through every conceivable channel of the internet. This contest will do nothing except put a heavy burden on a small development team to turn somebody else’s ideas into the type of application that can usually only be inspired by the developer’s own dreams.

Even when a team pursues a dream – their dream – success is far from assured. Good luck to the My Dream App team!

Something I’ve been meaning to do for a long, long time, is set up some custom project templates in Xcode. The problem is, it doesn’t really take that long to tweak all the little things in a new project, so when I’m in the mood to start something new, I usually just go through all the grunt steps.

Today I decided to put together a template that should cover at least 90% of the grunt work for typical applications I start work on. I started with a great example from Jon Wight of Toxic Software. His “CocoaApp” template did a lot of the things I wanted to do, but lacked a few whistles and bells. I thought I’d just work from his and it would be easy.

Instead it was amazingly, unbelievably difficult. The major complication comes from persuading Xcode’s template manager to actually do the substitutions it promises to do. See, at the root of the template system is this behavior where Xcode will replace certain tags in your files with appropriate values for the new project. The tags are surrounded by French quotes, chevrons, whatever … you know: «these». That’s fine, but depending on whether the file is in MacRoman, UTF-8, or UTF-16 format, the chevrons are a different value. Ugh, it’s infuriating the way they would sneak back and forth. I still don’t quite understand the logic applied by Xcode in deciding which encoding to look for, when. To make matters more complicated, I strived for (and accomplished) something truly amazing: an end to the “NewApplication” text in new project nib files. To achieve this I had to save the nib as XML format, but even then it was difficult to get the files into a suitable format that was still parseable as XML, yet would satisfy Xcode’s template system. This is so fragile that the nib files in the template are not even openable in Interface Builder – so unfortunately you won’t be able to tweak them without some serious hacking.

But the end result is nothing short of amazing, I’m proud to say. Download the Red Sweater Cocoa Application template and install it on your system. Then, when you go to create your next project, enjoy all the following frills right from the start:

• Automatically names all menu items in MainMenu.nib. No more “NewApplication”!
• Automatically instantiates a delegate class named [AppName]Delegate, connected as the delegate from NSApplication, and creates the supporting source files.
• Automatically creates an AppleScript scripting definition, pointed at by the Info.plist. The scripting definition contains a skeletal dictionary with a “[AppName] Suite”, ready for you to expose your model through.
• Automatically sets the CFBundleVersion to the subversion build number through a script build phase.
• Centralizes the marketing version in one build setting called “APPLICATION_VERSION.” Just change this build setting to easily update your release version.
• Presets the application icon name to [AppName]. Just pop in a [AppName].icns file.

I think that covers it. I have kindly left out the private framework references to my Red Sweater frameworks. You should be able to edit the “Cocoa Application.pbproj” to fine-tune things to your liking, but be sure to remove the “acct.pbuser” files from within it after you do so, these have a habit of bringing some nasty values into the template which won’t get replaced by the template system.

It occurred to me that I’m using this blog to spew updates about FlexTime, and that some of you might not give the slightest damn about updates to that particular product :)

On the other side of the spectrum, I’m sure some FlexTime users would like to subscribe to news about the application without being subjected to my lengthy diatribes about gdb debugging or Cocoa programming.

I’m going to try to start making better use of categories, including the hierarchical feature in WordPress, which allows for high-level subscription to only a specific category or to a whole class that live under the same parent.

For starters I’ve moved all the existing tags/categories into two high-level groups: “Red Sweater News” and, for lack of a better name, “Articles.” Basically, “Articles” is everything of general interest to the world, with occasional announcements of major software releases. “Red Sweater News” is for my customers, or anybody interested in following all the announcements about my products. If you’re just here to see what I have to say about various topics, stick with “Articles.” I will probably further refine the Articles category in the future so you can, for instance, ignore my technical pieces and only get the opinion, or whatever. The default feed will continue to carry everything.

In summary and for future reference, here is a list of the various pages and feeds you might be interested in:

Everything – View | Subscribe

Articles Only – View | Subscribe

Red Sweater Product News – View | Subscribe

FlexTime News – View | Subscribe

FastScripts News – View | Subscribe

Clarion News – View | Subscribe

Hopefully this isn’t complicating things too much!

It had to happen – especially after yesterday’s proud moment of not having found any critical bugs! A user pointed out a major flaw in FlexTime’s scripting support, which would cause the simplest of all commands, “open,” from working correctly in many instances.

If you’re doing any scripting at all with FlexTime, you’ll want to grab the latest version.