iOS 和 macOS 应用的整合开发代码共享有哪些经验可以分享？

WWDC 2014 有一个专门的 session 讲这个：
&> Learn what the iWork engineers did to ship iWork for iOS and Mac from a single codebase. Explore the patterns for sharing code between desktop and mobile, and see how you can optimize your code and write great apps.
Source: WWDC 2014 Session Videos (sharing code between iOS and OS X)

谢邀。

大概是要从网路、本地存储、炫酷界面及方面开始。

网路

选对开源Frameworks。例如：网路引擎AFNetworking/AFNetworking · GitHubA delightful iOS and OS X networking framework 很明显，这是通用的。

本地存储

这一块需要做一个通用存储类，方便应用在iOS和OS X存储数据，上资料库吧，自己CoreData坑多但方便啊。（如果要用sqlite＋FMDB，可以去问问周围有几个人用过DISTINCT，写SQL也是要有基础的）

界面

这个天天写就不用说了吧。

代码

WWDC 2014 Session Videos (sharing code between iOS and OS X)这一段主要是基于MCV分层来讨论的代码共享根据不同平台对同一个类作出的修改：

#if TARGET_OS_IPHONE

@interface MyAwesomeView : UIView

#else

@interface MyAwesomeView : NSView

#endif

{

}
@end

基于以上的代码可以分别对Model、View、Controller进行不同程度的share，避免出现大量重复代码，达到「sharing code between iOS and OS X」的目的。

同时，针对图片资源、屏幕尺寸、设备性能做出不同的处理也要一并进行处理。

以上。

多谢邀请，最近忙于创业，有段时间没有来逛知乎，现在才看到。我没有整合过iOS 和 Mac(Mac 开发我一般直接用node webkit 把web套过来就行了。。。。偶尔不偷懒的话，会用angularjs写点奇葩的东西)的代码，不过个人认为这种整合开发，可以施展的范围比较有限。

12年3月份还是四月份，美团的iOS团队做了一个决定, 将团购iPad 客户端和团购iPhone分离，当时是我们的技术专家@李帅主刀的，我也跟著掺合了下。分离后，两个客户端UI代码完全独立，但是有一个公用的核心库。

13年7月份，我开始主刀美团App的架构设计和建设，当时的目标是形成一个能在公司范围内使用的公共库。大概的分层结构是这样的：第一层系统层，包含对于NSFoundation,UIKit等一些系统API的包装，网路客户端，加密模块, 我们自己的异常处理运行时啊等等等等。第二层是基础服务，崩溃日志啊，统计啊，(我也想多说啊。。。但是不能够啊，虽然离职了，但是不竞业协议在身)。第三层围绕美团账户展开一些基础业务逻辑。第四层，保密。。。。第五层表现层。第3层以下，美团各个客户端都在用。第3层以下，用到美团账户的客户端在用。第4层保密。。。第5层是一个虚拟层，因为每个App不一样，包含一些UI定制／工厂，其他各种配置。到我离职前夕，iPad客户端大概用到这套框架的底下3层，正在冲击第4层，但是遇到很多问题。为啥呢？因为业务流程有差异，而且其他和团购打交道的客户端都有比较大的差异。同时，第一层里面的部分UI组件对于iPad也不适用。如果针对iPad特别做适配工作量比较大，因此iPad团队放弃了不少公共代码（这里还要说一下，上面有人说用static library/framework，在这种情况下就很不方便了。后期我们的配置工具是允许各团队有自己的私有代码存在的，求「同」存「异」嘛）。因为这些差异的存在，我们否决当时另外一个技术专家要将iPad合并进iPhone的提议。结合以上经验，对于楼主的问题，我的建议是：

1. 应用架构设计可以统一，因为换来换去就那些

2. 在1 的基础上，对于一些兼容iOS和OSX的的系统API的包装，已经有人躺过浑水的兼容两系统的第三方库的包装，这些可以公用3，在1和2成立的基础上，和自己的业务服务的一些业务逻辑的交互可以包装一下。（不一定像我那么神经分那么细，我当时要考虑3个主业务线，自己所在部门，还有几个兄弟部门的使用。还想开源一部分东东）4. 为了解决1/2/3, 你还需要很强大的配置管理。5. 好了，如果1到4都解决了，然后你还有预备队，或者可以让督战队也上战场。此时你可以尝试看看能不能把UI界面也统一了。不过大部分人到了，会选择另外两种做法。第一种，定义一下UI的介面，只要能做到和3的业务逻辑兼容就行。第二种, 投靠Hybrid，顺手再让Android的开发者失业。两种我都试过（当然，我的ex厂Android开发都还好好的，而且都很N），各有千秋。

谢邀。

这个问题挺久了，一直都很忙，没空来解答。其实这是一个好问题，因为要想做出来的程序跨平台，需要一系列的策略来指导当前程序架构的选择以及模块组件间的搭配，使得程序能在完成程序功能的基础上，达到目标各平台的适配。

虽然我并没有太多Mac原生程序的开发经验，但是我做过比较多的跨平台的开发工作。比如，做服务端程序经常需要考虑跨Windows和Linux，手机端经常需要跨iOS及Android，桌面平台上经常会需要跨Windows和Mac甚至Linux。

总体来说，考察一个项目的跨平台，需要考虑以下几点：

业务目的：你做的项目是为了达到什么目的，有哪些是必须做到不能舍弃的，是不是可以直接使用Web端就能完成了？
涉及到的技术：是否需要OpenGL？是否需要网路编程，若是网路编程，协议是http还是socket？是否有音效方面的要求？OpenAL？还是各自平台各自做？
涉及到哪些编程语言：这些编程语言间如何配合？（比如Java通过JNI与C++通信，Objective-C与C++混编，lua与C++互通等），有没有可能找到共通的编程语言？比如C++或者Objective-C？
涉及的编程语言在各平台下的技术解决方案：基础库的选择，比如网路若用C++来做是否使用ASIO这样的跨平台库（socket）或者curl（http），或者只是iOS和MAC是否可能考虑AFNetworking（http）。是否需要推送，后台统计？可否使用国内外流行的第三方开发包？同时，还需要参照当前团队人员配置，每个开发都擅长不同的领域，如何把他们挂载到一起，也会直接影响当前的技术选择。
抽象出与平台无关的程序架构：最后所有的技术方案都确定了，需要将整个工程的总体架构定出来，在涉及不同平台的地方抽象出简单的可满足业务需要的模型。

以上几点看起来似乎复杂，但是在有经验的情况下，往往也就是在一小时左右就可以确定整体的技术解决方案。使用开源的封装好的第三方库，比如Qt，wxWidgets，ASIO，CURL等，可以让你事半功倍。

＝＝＝＝关于iOS和MAC开发的一些建议＝＝＝＝

使用Objective-C这门语言已经足够
可以考虑使用Cocoapods来管理公共的库，比如AFNetworking库等，看团队风格。
严格遵守MVC架构。除了视图（V）的部分需要单独开发，数据（M）和控制器（C）的部分都应该是一样的（业务逻辑一致的情况下）
使用宏定义来切换不同平台下的编译选项，但是不要滥用，注意控制程序复杂度
最好不要把两种不同的平台下的视图代码写到一个文件里，保持程序结构的清晰，不然当一个视图变大的时候，那代码看起来可能会让人疯掉，维护成本最后可能会超过开发成本

以上。

谢邀。简单说说个人的看法：1. 公共部分抽取后做成static library或framework（有静态资源如图片、语言等引入）类型的工程是必须的，方便在各项目中使用。使用方式可以用多target(lib-ios, lib-mac)或项目编译前挂脚本改配置等等2. 针对ios/mac os的公用组件但实现有差异的部分，可以考虑采用宏指令来处理差异代码，如nicklockwood/iCarousel，ASIHttpRequest，AFNetworking等3. 针对各平台独立的部分，可以考虑分类后依据宏指令分别导入，各target分别引用或宏指令处理整个差异文件。如ReactiveCocoa/ReactiveCocoa · GitHub等4. 麻烦看楼上楼下

参考一下 Swift 里边的做法