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 裡邊的做法