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

If I were you I would go with a cross-platform framework and/or programming language, nowadays you have plenty of languages/frameworks that are working cross platform such as Java, QT (with both Java and C++ languages for using the toolkit), C# with MONO, GTK+ with C (gtkmm with C++, gtk# and Mono for C#). So it is more simple if you do it in one language/framework than in two simultaneously because if you write the same app in two different languages/frameworks it will cost you extra development time for half of that time you can get your hands on new framework and the language because you know from the very beginning that your target platform is multi-platform. If now your primary platform would be e.g Windows and later the Mac users like the application very much so then is the reason for re-writing it targeting another platform and using its development tools.

Answer 3

Both the pros and cons that you mentioned are absolutely valid. Personally, I hate going back and re-do something even in a different language than having to constantly mentally switch the language mindset. I am already doing this everyday where I am doing both the server development in Python and the client side in JavaScript.

Having said, how about separating the low-level stuff from the high-level UI stuff. Build the low level stuff in each platform so they would have the very exact same APIs. The underlying internal implementation can be totally different, it does not matter, as long as they both expose the same interface. I think you'll find it interesting to do so. You also said you want the UI to feel native on each platform, then why not consider something like SWT in Java. If SWT and Java are not an option, then I guess you'll have to build the high-level stuff using WPF and Cocoa. But by this time, your job will be easier since you would be calling the same API that you previously built in your low-level libraries.

Answer 4

Are you sure you can't abstract the low-level services into a common interface and still have enough app left (such as the UI) to make it more economical to develop in something cross-platform? If you want a shrt time-to-market it sounds wasteful to plan doing everything twice.

Answer 5

What about using a third language as glue for the native calls?

I've heard that python or ruby have good capabilities for native lib integration. The difference could be abstracted through an internal API.

This way all the logic could be set in the third lang and the specific part in the other.

The same may go for Java, but I think the integration looks a little bit harder.

BTW this is the way ( or was? ) classes like java.io.File works.

Tell us how it went.

edit

I think the way big companies go with this is using C++ and using forks for platform specific code.

Answer 6

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 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.

Answer 7

If you are going to have to learn a new technology anyway (Objective-C), I would give Java another look. Trying to develop the same program twice for two different platforms and learn too many things at once may mean that you wind up with a program that works well with neither - or an unsupportable mess if you get seduced into using features available on one platform but not on the other.

If you go with Java you'll only need to deal with some UI and installation quirks on each platform - the bulk of your app (and, importantly, any bug fixes you do) are going to port right away. Java UIs seem fairly mature right now, and there is a lot of reusable UI code (e.g. JIDE components are nice). If your app idea is truly killer, you can hire staff to do the 'first class citizen apps' after you make your millions.

You could also look at how other cross platform apps have been delivered successfully - for example look at firefox, thunderbird, openoffice, and see what you can reuse. I know of a number of cross platform apps done in Java, too - for example I use PersonalBrain and crashplan, and they both seem to be java based, and it's not intrusive at all. (Interestingly, PersonalBrain was first delivered Windows only and they then did a Java rewrite. Some features are still windows only however, but I'm happy using it on a Mac.)

It does depend on some extent on the application you want to write - for example will you want to support iPhone at some point? If so there is little choice currently but to use objective C, and you will probably see some reuse out of your MacOSX efforts if you plan ahead.

Whatever you do, I would definitely suggest splitting the UI from the main logic of your program - and make that main logic as directly portable as possible. Otherwise you will be reinventing every wheel on every platform.

Answer 8

You should focus on writing your application for one platform initially, and worry about porting it later. Your project is guaranteed to fail if you don't complete it, and trying to write it for two platforms at once is certain to increase the overall development time. And can you name one piece of commercial software that failed because they didn't support multiple platforms?