Cross-Platform Desktop Apps -- An Approach?

Question

I have what I believe is a killer idea for an application. By definition, this would be a desktop application, and it ties into some fairly low-level services provided by the platforms for which I'd write it (Windows Search Service, Mac OS X Spotlight server).

My intent is both a Mac OS X and Windows version. The absolute intent is actually to not share code -- mostly because very little (if any) of it would be able to be common. Because of this, I intend to use completely different frameworks (Cocoa/Obj-C on Mac, C#/WPF/PInvoke on Windows) and get both feeling "native" to their platforms, first-class application citizens if you will.

My question is this: Is it better to try and build them both "simultaneously," that is, try to keep them at feature parity even through the development cycle; or is it better to get one "right" and then follow up with the other?

The pros to keeping parity seem to be:

• Easier to keep the algorithms in alignment, as I implement in one language, I merely port to the other
• Easier to ensure that at release, both apps are immediately available

The cons to keeping parity seem to be:

• Harder to do; constant language switching might make my head explode (I already go through this at work whenever I work C# for 4 days then suddenly have to maintain one of our old VB.NET solutions)

The pros of one, then the other, seem to be:

• No constant language switching
• One platform can be in test while the other is being built

The cons of one, then the other, seem to be:

• Going back to what will then be "old" code to port the algorithms
• Potentially losing interest in "redoing" what I've already done

Admittedly, this is very ambitious ... And I'm only one guy, doing it in "spare" time (hah). If you were in the same boat, and are familiar with both suites of technology, how would you approach this?

Updated

In response to some questions from below:

Yes, a common API is doable, however calling conventions wouldn't be -- or at least, not easily. I do intend to have the same classes defined, but with platform-specific code. (This seems fairly critical, as Windows Search Service and Spotlight work really differently.)

I could go with something like Java, but I'm choosing not to for a couple reasons: (1) I haven't done Java in forever, and am now dangerously unqualified. :) (2) Part of it is an exercise in learning Objective-C by doing "essentially" the same app in technologies I am familiar with; and (3) While Swing can provide a mostly-native look on OS X, its Windows UI doesn't ever feel quite right, and I truly want both apps to feel like they belong on their respective systems.

Time to market isn't a big consideration; I feel the app idea itself will be fairly safe. More important than TTM is getting the app to feel right and provide the functionality ...

Answer 1

I'd develop for whichever platform has the largest target-audience (as in for your killer app) first, then use the inevitable lessons I'd learn along the way to improve the way I'd develop for the other(s).

Answer 2

Although I've been fanatically looking for a desktop solution for both platforms, I don't think there's any problem with building the app twice... probably makes sense.

That said, I don't think that you should build one and then the other, but try to do something madly difficult like use the same UML class diagrams for both. This will force you to do the hard work of dividing the app into the parts that are identical and the parts which are, by definition, platform specific.

The idea is not to share a code base, but to share a software design.