跨平台桌面应用程序 - 一种方法？

我认为这是一个应用程序的杀手锏.根据定义,这将是一个桌面应用程序,它与我编写它的平台(Windows Search Service,Mac OS X Spotlight服务器)提供的一些相当低级别的服务相关联.

我的意图是Mac OS X和Windows版本.绝对意图实际上是不共享代码 - 主要是因为它很少(如果有的话)可以是共同的.因此,我打算使用完全不同的框架(Mac上的Cocoa/Obj-C,Windows上的C#/ WPF/PInvoke),并且如果愿意的话,让他们对他们的平台感觉"原生",成为一流的应用程序公民.

我的问题是:尝试"同时"构建它们是否更好,即尝试即使在开发周期中也将它们保持在特征奇偶校验中; 或者更好地让一个"正确"然后跟进另一个？

保持平价的优点似乎是:

更容易保持算法一致,因为我用一种语言实现,我只是移植到另一种语言

更容易确保在发布时,两个应用程序都可立即使用

保持平价的缺点似乎是:

更难做; 不断的语言切换可能会让我的头脑爆炸(每当我在C#工作4天时,我已经完成了这个工作,然后我突然不得不维护一个旧的VB.NET解决方案)

一个,然后另一个的优点似乎是:

没有恒定的语言切换

一个平台可以在测试中,而另一个平台正在构建中

一个,然后另一个的缺点似乎是:

回到那将是"旧"代码来移植算法

可能会失去对"重做"我已经做过的事情的兴趣

不可否认,这是非常雄心勃勃的...我只是一个人,在"空闲"时间做这件事(哈).如果你在同一条船上,熟悉两种技术套件,你会如何处理？

更新

回答以下一些问题:

是的,常见的API是可行的,但是调用约定不会 - 或者至少不容易.我打算定义相同的类,但使用特定于平台的代码.(这似乎相当重要,因为Windows Search Service和Spotlight的工作方式完全不同.)

我可以使用类似Java的东西,但我选择不这样做有几个原因:(1)我没有永远完成Java ,而且现在危险地不合格.:)(2)部分内容是通过在我熟悉的技术中"基本上"使用相同的应用来学习Objective-C; (3)虽然Swing可以在OS X上提供大多数本机外观,但它的Windows UI并不是非常正确,我真的希望这两个应用程序都感觉它们属于各自的系统.

上市时间不是一个重要的考虑因素; 我觉得应用程序的想法本身会相当安全.比TTM更重要的是让应用程序感觉正确并提供功能......

我会先为最大的目标受众(比如你的杀手级应用程序)开发平台,然后使用我不可避免的经验教训来改进我为其他人开发的方式.

虽然我一直在狂热地寻找两种平台的桌面解决方案,但我认为构建应用程序两次没有任何问题...可能有意义.

也就是说,我不认为你应该构建一个然后另一个,但是尝试做一些疯狂的事情,比如使用相同的UML类图.这将迫使您将应用程序划分为相同的部分以及根据定义特定于平台的部分进行艰苦的工作.

这个想法不是共享代码库,而是共享软件设计.