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

Question

我有一个我认为是一个致命的想法的应用程序。根据定义，这将是一个桌面应用程序，它与我编写它的平台(，服务器)提供的一些相当低级别的服务绑定在一起。

我的目标是Mac和Windows版本。其绝对意图实际上是不共享代码--主要是因为很少(如果有的话)代码能够共享。正因为如此，我打算使用完全不同的框架( Mac上的Cocoa/Obj，Windows上的C#/WPF/PInvoke )，如果愿意的话，让他们的平台感到“本土化”--一流的应用程序公民。

我的问题是:是否最好“同时”构建它们，也就是说，在整个开发周期中保持它们的功能均等；还是更好的做法是“正确”，然后跟进另一个？

保持均等的好处似乎是：

• 更容易使算法保持对齐，因为我用一种语言实现，我只是将其移植到另一种语言。
• 更容易确保在发布时，这两个应用程序立即可用。

保持均等的缺点似乎是：

• 很难做到；不断的语言转换可能会使我的头脑爆炸(每当我在C#工作4天时，我就已经经历了这个过程，然后突然不得不维护我们的旧VB.NET解决方案之一)。

其中一种，然后另一种，似乎是：

• 没有固定的语言转换
• 一个平台可以进行测试，而另一个平台正在建设中。

其中一个，然后另一个的缺点，似乎是：

• 回到“旧”代码来移植算法。
• 可能对“重做”我已经做过的事情失去兴趣

无可否认，这是非常雄心勃勃的..。而我只是一个人，在“业余时间”做(哈)。如果您在同一条船上，并且熟悉这两套技术，您将如何处理这个问题？

更新的

在回答以下一些问题时：

是的，一个通用的API是可行的，但是调用约定是不可能的--或者至少不容易。我确实打算定义相同的类，但使用特定于平台的代码。(这似乎相当关键，因为和Spotlight的工作方式非常不同。)

我可以使用类似Java的东西，但我选择不使用Java有几个原因：(1)我已经很久没有使用Java了，现在我已经危险地不合格了。(2)它的一部分是学习目标的练习--通过在我熟悉的技术中做“本质上”相同的应用程序；(3)虽然Swing可以在OS X上提供一个本机的外观，但它的Windows UI从来都不太正确，我真的希望这两个应用程序都能感觉它们属于各自的系统。

上市时间并不是什么大问题，我觉得应用程序的想法本身是相当安全的。比TTM更重要的是让应用程序感觉正确并提供功能.

Answer 1

您应该首先将重点放在为一个平台编写应用程序上，然后再考虑如何移植它。如果不完成项目，项目肯定会失败，同时尝试为两个平台编写项目肯定会增加整个开发时间。你能说出一款商业软件因为不支持多个平台而失败了吗？

Answer 2

我会开发的哪个平台有最大的目标受众(在你的杀手应用程序)，然后使用不可避免的教训，我将学习到的道路上，我将发展的方式，为其他人(在)。

Answer 3

虽然我一直狂热地为这两个平台寻找桌面解决方案，但我认为两次构建应用程序没有任何问题.可能很有道理。

尽管如此，我不认为您应该先构建一个，然后再构建另一个，但是尝试做一些非常困难的事情，比如，为两者使用相同的类图。这将迫使您做艰苦的工作，将应用程序划分为完全相同的和定义为特定于平台的部分。

这样做的目的不是共享代码库，而是共享软件设计。