最后要提的是，正因为OS X的文化与Windows有许多不同处，笔者建议跨足OS X的开发者应该要尽可能贴近甚至配合OS X的习惯。举例来说，大多数OS X应用程序都不需要安装程序，只需要直接将软件拷贝到想要存放的目录（通常是/Applications）即可。而解安装也就直接删除该.app bundle就解决了。在Windows上就没那么容易了（特别是有相当多组件依存关系的软件）。这些都是开发上需要注意的地方，但是开发者多付出一份心力，使用者就会多一份便利，终究会得到用户肯定的。

项目  Windows  Mac OS X
系统内部编码 Unicode (UTF-16) Unicode (文件系统使用 UTF-8, 系统API一般使用 CFString/NSString, 内部使用UTF-16)
语系处理 区分Codepage 不区分Codepage
应用程序的设定管理方式 Windows registry Property list files
IPC的几种方式 COM/Windows RPC Objective-C Distributed Object/Apple Event/BSD Socket
脚本语言的支持 VBScript/JScript/CScript/DOS Batch script AppleScript/Perl/Ruby/Python/shell script

表三：一些重要的系统特性（摘录）

项目 Windows (.NET) Mac OS X (Cocoa)
字符串处理 System.String NSString
数据结构与容器 System.Collections NSArray/NSDictionary/etc.
HTTP网络存取 System.Net System.Net,NSURLConnection
XML解译 System.XML NSXMLDocument etc.

表四：几个代表性的.NET namespace/class在Cocoa中的对应class

跨平台的建议

最后简短分享一些跨平台软件开发所可能遇到的问题。

要同时在Windows和Mac上开发，有两种可能的思维方式。一种是追求真正的"write once, run everywhere"。此时开发的选择，可能是采用Java平台，Adobe的AIR，抑或使用C++搭配像QT这样的跨平台链接库。这三种主流方案各有千秋，但在视觉和用户体验上往往皆无法与原生（native）的Mac应用程序相比。

因此，另一个方向则是体认到，要保有Windows及Mac各自平台的特长，就必须割舍GUI跨平台的可能性。也就是说，GUI是最无法移植到其他平台的部分。我们能做的是将共通的逻辑部分独立出来，然后开发两套前端接口（frontend）。若以在Windows及Mac上皆能使用为前提，共通逻辑开发语言的选择就很少了，不是C就是C++。所幸Windows和Mac上具有平台特色的语言，要和C++结合，也不是那么困难的事（在.Net上是透过C++/CLI，在Mac上是透过Objective-C++这两种扩展的语言）。

不过，在开发共享部分的时候，最容易碰到的问题，恐怕还是要如何省下力气去做例如解译XML文件、存取网络这一类不是GUI的工作。这类工作的麻烦在于，Windows和Mac都各自提供了相当便利、但也绝对和平台相依的链接库（例如.Net的System.Xml，Cocoa的NSXMLDocument）。在这种情况下，我们也大体有两种选择：不是全部采用跨平台的链接库（例如使用expat来解译XML），就是善用面向对象的抽象化以及Abstract Factory这样的设计模式（design pattern），让程序逻辑呼叫抽象的接口，然后在于各自平台的版本中藉由呼叫平台相依的API来实现这些对象。

结论

本文简要地讨论了Windows及Mac OS X在操作系统架构、开发环境、API、图形环境等环节上的相近处与不同的地方，也简单提出了跨平台应用程序开发的两种策略。事实上在两种平台上开发所需要了解的概念跟技能没有太大的不同，两种平台在性能上的差异也不大，但是在实现细节、视觉表现与用户体验上，OS X有自身独特的风格与文化。OS X软件开发社群常常说要"be a good Mac citizen"意思也就在此。了解这些差异和独特性是撰写合宜的OS X软件的第一步。