今年 WWDC 最爲重磅的消息可能就是 Applie Silicon Mac——搭載着蘋果自研芯片的 Mac。得益於 CPU 架構的統一,在 Mac上原生的運行 iPhone 或者 iPad App 似乎已經不是那麼的遙不可及了。相信很多人都會好奇蘋果將會用什麼樣的方式將這些移動設備上的 App 帶到我們手中的 Mac 上。 Session 10114 iPad and iPhone apps on Apple Silicon Macs 就是對這些疑問的一個統一回答。

概述

簡單來說,Session 10114 主要向我們傳達了這幾個信息:

  • 運行方面:在不依賴 macOS 系統沒有的 SDK 的前提下,所有的 iPhone/iPad App 在 Apple Silicon Mac 上都可以無需改動運行起來,只是很多地方看起來會不那麼符合 macOS 風格,結合 Catalyst 會讓我們的 App 在 macOS 上更好用
  • 調試方面:調試運行在 Mac 上的 iPhone/iPad 的過程和在模擬器、真機上完全相同
  • 發佈方面:默認所有的 iPhone/iPad App 都可以發佈到 Mac App Store,開發者可以選擇手動關閉,同時像 Ad Hoc 或者企業分發這種 App Store 外的發佈流程也和之前基本相同

接下來,我們來詳細瞭解一下蘋果的工程師都說了什麼。

運行

在有 Apple Silicon Mac 之前,在 macOS 上我們一般會開發這四種類型的應用程序:

  • Mac apps: 基於 AppKit 開發,比較老牌的一種開發方式
  • Mac Catalyst apps:在 macOS Catalina 後才支持的開發方式,基於 UIKIt 開發
  • Web Apps:基於前端技術棧開發,比較老牌的一種開發方式
  • Games:基於 Metal 框架開發,相對比較新的一種開發方式

得益於 Catalyst 在 macOS 上引入的 UIKit,在 Apple Silicon Mac 上,我們可以非常輕鬆的運行原本運行在 iPhone/iPad 上的 App。

默認運行起來的這些 App 在很多方面上都可以獲得類似 macOS App 的體驗,包括:

  • Standard window chrome(就是 Mac app 左上角的那三個按鈕)
  • Menu bar
  • macOS app lifecycle
  • Preferences panel
  • Dock presence
  • Dark Mode
  • Open/save panels(CMD + O / CMD + S會打開的那個面板)
  • Text behaviors
  • Font and color panels
  • Scroll bars
  • Touch Bar
  • Printing
  • Alerts
  • Drag and drop(和 iOS 上的類似,通過拖拽將一個 App 中的內容移動到另一個 App 中,參見 Human Interface Guidelines - Drag and Drop

注意:

儘管以上這些內容是可以自動獲得的,但僅僅有這些能力並不足以讓一個 App 在 macOS 獲得良好的體驗,這些 App 僅僅是處於 “能用” 的狀態。如果想要讓 App 在 macOS 上“好用”,蘋果的工程師建議我們使用 Catalyst 來優化 App 的體驗。

不過獲得以上這些體驗的前提是,App 能夠在 macOS 上正常的運行起來。

要想讓 App 能夠在 macOS 上正常的運行起來,開發者需要關注這幾個方面的事情:

  • App 沒有依賴 macOS 上不存在的 API 或者是 SDK(包括系統的和第三方庫的)
  • App 沒有依賴 macOS 缺失的功能
  • App 沒有依賴 Mac 所不具有的硬件能力

除此之外,在代碼的健壯性上,開發者需要關注 iPhone/iPad App 在 Mac 上運行會有如下方面的不同:

  • 硬件上的不同
  • UI 上的不同
  • 系統軟件上的不同

硬件上的不同

硬件方面,蘋果的工程師主要提及了三點不同:

  • 鼠標與觸摸事件的不同
  • 環境傳感器的不同
  • 攝像頭的不同

鼠標與觸摸事件的不同

在 iPhone/iPad 上用戶輸入都是以觸摸爲主,而 Mac 則是以鼠標鍵盤爲主。macOS 會盡量將普通的點擊等事件映射成對應的觸摸事件。但如果 App 實現了一些自定義的觸摸事件,那麼開發者就需要自己測試一下自己的 App 在 Apple Silicon Mac 上是否表現正常。

環境傳感器的不同

iPhone/iPad 上都有着大量的環境傳感器,例如加速劑、陀螺儀、GPS、磁力計、景深攝像頭等,而在 Mac 上基本沒有這些傳感器。因此開發者要在代碼做好沒有這些傳感器的對應處理。需要注意的是,沒有傳感器並不代表沒有相應能力,例如在 Mac 上開發者依舊可以使用 CoreLocation 來獲取設備當前的位置(只是不那麼精確)。

攝像頭的不同

在 iPhone/iPad 上幾乎所有的設備都擁有前置和後置攝像頭,但是在 Mac 上這種假設並不一定成立。蘋果的工程師建議開發者,用 AVCaptureDevice.DiscoverySession 這個 API 來獲取攝像頭設備的使用權限。

UI 上的不同

在 macOS 中,很多系統控件的行爲表現會和 iPhone/iPad 上不太一樣,例如 Alert:

所以 App 的代碼中不要有任何類似假定系統控件彈出位置的代碼,因爲這些代碼運行在 Mac 上時,會得到完全不同的結果。

同時注意,如果開發者的 iPad App 沒有支持 Multitasking ,會和 iPhone App 一樣在 Apple Silicon Mac 上表現爲一個不可以改變大小的窗口。

如果 iPad App 支持了 Multitasking,那麼開發者需要保證佈局代碼足夠的高效,以便用戶在縮放窗口大小時能夠得到流暢的體驗。

系統軟件上的不同

系統軟件上的不同主要體現在兩個方面:

  • 文件系統
  • 設備信息

文件系統

和 iPhone/iPad App 不同,Mac App 可能被用戶放置在任何一個地方,因此 App 的代碼中不應該對 App Bundle 以及沙盒的位置做任何硬編碼。

設備信息

在 Mac 上,窗口的分辨率可能會有各種各樣的變化,設備名稱也可能有各種各樣的變化,因此 App 內部不應該對設備的分辨率以及設備名稱做任何假設(設備名稱這一條 App 對應的後端服務也要注意,不要依賴設備名稱)

調試

調試這部分可以講述的東西不多,因爲整體內容就可以用四個字來總結:完 全 一 致。不管是 Debug 的工作流,還是 Profile 的工作流,甚至單元測試的工作流都是完全一樣的。

唯一值得一提的是,根據蘋果工程師的說法,在 Apple Silicon Mac 上,使用 Xcode 打開 iOS 工程,在 Target 的 Destination Device 中會多一個 My Mac(Designed for iPad) 這樣一個設備:

選擇這個設備,運行起來後就會看到這樣的效果——沒有模擬器,直接運行在 Mac 上的 iOS App:

發佈

如果說調試可以用四個字來形容,那麼發佈就可以用六個字來形容:基 本 完 全 一 致。

將 iPhone/iPad App 發佈到 Mac App Store 的步驟和發佈到 iOS App Store 的步驟是基本一致的,開發者需要做的就是同意新的開發者協議,然後把能夠發佈到 Mac 上的 App 勾選發佈到 Mac 即可,整個過程就像是發佈到一個新的設備類型一樣。

通過這種方式發佈的 App 同樣也可以使用 StoreKit 完成應用內購買、AppThing 以及 On-demand Resources 這些 iOS App Store 提供的功能,唯一有所區別的是,TestFlight 並不支持這種形式的 App。

同樣的過程也體現在 Ad Hoc/Enterpirse/Development 發佈的過程中,整個過程中開發者只要將 Mac 當做一個新的設備類型發佈即可。

除此之外,在今年的晚些時候(熟悉的 Later in Summer),蘋果還會提供一些新的開發者工具,幫助開發者更好的驗證他們的 App 在 Apple Silicon Mac 上的表現。

總結

雖然形式非常不同,但是蘋果 Catalyst + Apple Silicon Mac 的這套組合拳,讓我不禁聯想到了 IPad 早年推出的時可以運行 iPhone App 的操作。以成熟的生態帶動一個不那麼成熟的生態,進而創建/拉動一個新的生態。雖然現在只是一個開始,但說不定過幾年再看我們會發現:

相關文章