［譯］假如 Mac 上也有 iOS 應用？

<b>本文講的是［譯］假如 Mac 上也有 iOS 應用？，</b>

沒有人專門為 Mac 開發應用，Slack 有專門的 iOS 版本，放在 iPad 上的體驗非常好，接上 smart keyboard 以後，你會發現還可以友善的使用快捷鍵。而且，在應用上無限下滑的體驗甚至超過了他們本身的網頁端，甚至于我從來沒有看到過一個“加載中”的頁面。這體驗如果能夠放到桌面端那是再好不過了，但是他們沒有這麼做，他們僅僅隻是把他們的網頁放到了一個 app-launcher 裡，這就成了桌面端。

Basecamp 是這麼做的，Wordpress 是這麼做的，甚至連 Mac App Store 自己，都隻是一個 webview 而已。

對于那些所謂的“應用”，我是再讨厭不過了。我了解大公司的選擇，他們不喜歡跨平台。設計師們需要專門做設計，QA 需要測試更多的環境，而文職人員們則要費力去翻譯那些“原生視圖”到更為工業界接受的“頁面視圖”。那些大公司一直不願意費力氣去替代跨平台的 Html 5 應用也毫不奇怪了。

如果說，還要什麼别的原因的話，那就是：這也不僅僅是一個“編譯到OS X”的簡單工作，你需要雇傭專門的 OS X 開發者，且維護一個新的代碼庫。

We cannot port Sketch to the iPad if we have no reasonable expectation of earning back on our investment. Maintaining an application on two different platforms and provide one of them for a 10th of it’s value won’t work, and iPad volumes are low enough to disqualify the “make it up in volume” argument.

我們不會把 Sketch 移植到 iPad 上面，除非我們有合理期望去赢回我們的投資。去維護一個兩個不同的平台，并在其中一個上面付出超過其價值10倍的投入是不值得的，而 iPad 上面的流量少到我們根本不必參與到“盡可能擴大使用者”的争論裡。

他們認為一個很有效的規避風險的辦法就是從試用開始，而我認為還有一個選擇就是使得支援 iPad 變成一件簡單的事情。你也許會問，“為什麼不呢？”

我就直說了：直接把 iOS 應用移植到 OS X 的體驗是超級差的，你需要重新設計觸摸屏的互動來适應鍵盤和滑鼠的互動。當然也有一些例外，一部分領域的應用是不需要這麼做的：假設你請 Pinterest 重新設計他們全是圖的界面，他們隻需要聳聳肩，然後把整個網站放在一個 webview 裡就行了。

盡管 OS X 和 iOS 共享了相當一部分的底層接口，然而他們在 UI 層面是完全不同的。前者是建立在 Appkit 的基礎上的，其曆史可以追溯到 NeXT。而後者則采用了 UIKit，那是從 iPhone 的最底層開始寫的。

二者甚至連坐标系統都是不一樣的，在 OS X 上坐标點在左下方，而 iOS 上面則到了在左上方。

不僅是這樣，UIKit 專門為 GPU 設計了渲染加速，每一個 UIView 都有一個核心的動畫層（layer）作支援，與 GPU 一同提供了流暢的滑動體驗。

但大概是為了支援比較早的版本，這層 layer 到了 Mac 上就變成非必須的了，甚至就算你啟用了這個動畫層，你也會感覺到他們也是建立在 NSView 上面的。

tvOS is derived from iOS but is a distinct OS, including some frameworks that are supported only on tvOS.

tvOS 是 iOS 的一個衍生版本，包含了很多隻能在 tvOS 上使用的架構。

那上面也運作 UIKit，剛剛好能夠 讓你 重寫一遍适合 TV 上的互動。

TV 上應用的互動方式和觸摸屏上的方式差太多了，極有可能到最後，你會得到一個完全不同的設計。

When porting an existing project, you can include an additional target in your Xcode project to simplify sharing of resources, but you need to create new storyboards for tvOS. Likely, you will need to look at how users navigate through your app and adapt your app’s user interface to Apple TV.

當移植現有的項目的時候，你可以附加一個 target 在現有的 Xcode 項目裡面共享資源。但是，你得專門為 tvOS 建立新的 storyboards。類似地，你還需要研究使用者如何使用你的應用來調整你的應用界面來适應 Apple TV。

即便你可以把 tvOS 應用和 iOS 應用放在一個 Bundle 裡面，缺點（eg. 過度耦合）也大過優點。我知道不少的 iOS 的開發者都後悔釋出了 iPhone/iPad 上通用的應用，因為二者的聯結太緊密。很多時候，倒不如把那些共享的代碼放到一個架構（framework）裡面。

鑒于此，如果想要在 iOS 和 Mac 之間移植，情況也是類似的。如果蘋果能使 Mac 和 iOS 的使用者體驗更相似一些，你很可能可以把 Mac 和 iOS 應用放在同一個包裡。

對于開發者而言，一個應用意味着一份 Bundle ID，這使得共享不同裝置之間的資訊變得更簡單。這所有一切的目的，都是為了簡化在新平台 (macOS) 上開發與iOS 應用相應的(桌面)應用的流程”

理論上，你可以限制一些 Mac 的特性，使其符合 Mac 慣例，比如浮動調色盤。

那坐标系統呢？—— 如果你使用自動布局，就不用擔心了。别的情況，你可以用相對布局來取代那些寫死的坐标，就好比是 CSS 一樣，其實并不是很複雜。

再也沒有（0，0）點了，你可以毫無顧忌的改變視窗的大小。

不幸的是，很多應用都寫死了坐标值。除了 UIKIt 以外， Apple 都要抛棄掉坐标系統了。如果你把它和 Appkit 應用連結到一塊的話，你就得到了已有的坐标系統，而指望在同一個應用裡統一 Appkit 和 UIKit 的坐标系隻會把一切弄得一團糟。

比方說你正在使用 Facebook，你希望在螢幕的一邊能夠一直看到更新的話題，而你的螢幕上還空了一大塊。你可以把它設定成“普通的”寬度。那為什麼要這麼大費周章，而不是簡簡單單的看一下這是不是一台iPad呢？這是因為隻需要把應用從“普通的”寬度切換到“緊湊的”寬度，就可以讓使用者友善的開啟多任務模式了。

Mac 也可以做類似的事情，當視窗小于一定阙值以後，就可以改變視窗的類型。

這五年來，每一次 WWDC，我都在想，“是時候了。”，對于此，我的 Outlook（日程表）已經從“渴望的事情”到了“無可避免了”。

其實蘋果公司比任何人都更渴望讓 Sketch 這樣的應用運作在 iOS 上面。比如說 iOS 上的 Lightroom ， 它卻不支援“RAW”格式，這對專業的攝影師來說 iPad “pro”就是個笑話。而對比微軟的 Surface，上面則運作了真正的lightroom。

看起來，Apple 像是放棄了 OS X。他們沒有雇傭更多的 AppKit 的開發者，而 Mac 的 App Store 多年來就是破爛不堪了。那麼如果他們終于決定放棄舊的平台轉而将所有的資源注入到一個(iOS與macOS)統一的平台上會産生怎樣的效果呢？

這五年來，蘋果改變很多，iOS 7 顯示了他們願意打破傳統。Apple Watch 顯示他們願意承擔風險。為什麼不呢？他們在2010年就開始在 “Back to the mac” 上承擔風險了。

他們說，在 WWDC2016 上 OS X 會被重命名為 macOS，今年會是時候了吧。

譯注: “Back to the mac” 是蘋果在2010年的一項活動，那次釋出了Mac OS X Lion，并且介紹了蘋果如何期望把 Mac 平台和 iOS 平台統一起來。本文在圖檔裡的标題也是“Back to the mac”

<b></b>

<b>原文釋出時間為：2016年07月06日</b>

<b>本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。</b>