13's blog

iPhone XS Max 與 Xcode 9 相容性分析

iPhone XS / XS Max 開賣當天我跟同事 Toby 有拿到 Max 來做測試。如同他分享的文章,iPhone XS Max 在跑 iOS 11 SDK (Xcode 9) build 的 app 會用放大模式來顯示。

這個放大模式怎麼來的呢?就是根據 iPhone X 的顯示內容。因為兩個螢幕的長寬比一樣,所以內容是等比例放大的。仔細比較一下還發現更多的細節。先講結論:

iPhone XS Max 在系統設定 > 螢幕顯示與亮度 > 顯示畫面設定為放大模式時,不管是用哪一版的 SDK build,app 的顯示內容都會跟 iPhone X 一樣,只有狀態列會略有不同。而在一般模式時,app 必須用 Xcode 10 才能在 XS Max 上顯示原生解析度。


以下影片是 Knil 這個 app* 分別在五種狀態下的樣貌,可以注意到 1~4 的顯示內容相同,只有狀態列不同。而 5 則是原生解析度。

  1. iPhone X
  2. iPhone XS Max, Xcode 9 (iOS 11 SDK), 放大模式
  3. iPhone XS Max, Xcode 10 (iOS 12 SDK), 放大模式
  4. iPhone XS Max, Xcode 9 (iOS 11 SDK), 標準模式
  5. iPhone XS Max, Xcode 10 (iOS 12 SDK), 標準模式

iPhone X & XS Max compare


另外一點,A12 晶片用了一個叫做 arm64e 的新 architecture ,用 Xcode 9 要 build & run 到 XS Max 上會顯示以下資訊:

Xcode 9 run on iPhone XS Max

依照錯誤訊息在 build setting 加上 arm64e 也沒用,因為 Xcode 9 就是不支援。

結論就是,如果要支援 iPhone XS Max 的原生解析度或是進行 Max 的實機開發,一定要用 Xcode 10(廢話🤣)。但如果暫時還維持 Xcode 9 的話,使用者會看到 iPhone X 放大版的內容。放大的程度並不明顯,不仔細看是看不出來的。


* Knil 是我撰寫的開源且免費的 Universal Links 測試工具

接收 GitHub 即時通知 - Canopy

GitHub 一直都沒有推送的功能。是有 Webhook 可用,很多人可能是用 Slack 接 Webhook 來接收通知的。不過如果參與的開源專案比較多,一個一個設定 Webhook 就太麻煩了。

Canopy 是用來在 macOS 與 iOS 上接收 GitHub 通知的工具。作者是 Max Howell (@mxcl)。如果你不知道 Max 是誰,他就是 HomebrewPromiseKit 的作者。他本人說,GitHub 推送通知的功能他等了十年也沒等到。對於開源專案來說,漏掉重要訊息太傷了,乾脆自己來寫一個。

9 月剛推出 v1.0,還熱騰騰


CanopymacOS 版 在 Mac App Store 可免費下載,iOS 版 則是 4.99 USD,支援開源專案的即時訊息,像是:

  • Commit
  • New issue
  • New pull request
  • Issue reply
  • Star
  • Follow

如果要支援私人專案的通知,則要另外付費訂閱服務。這種設計跟 GitHub 的方案一樣,是鼓勵開源專案的。

Canopy macOS

介面很簡單,可以輕易地勾選要接收通知的專案。值得一提的是兩個版本是會同步的,我第一次打開 iOS app 就看到 Mac 登入好的設定,非常貼心。😍

(小插曲,我第一次打開 iOS app 其實有遇到通知權限沒有被詢問的 bug,回報作者以後他也馬上修好了。⚡️)

如果你仔細看官網的 FAQ 會發現竟然有這麼多注意事項,感嘆這麼基本的需求,GitHub 官方竟然搞得這麼麻煩。😓


我平時常在 GitHub 上維護或參與的專案超過五個,雖然沒有很頻繁的消息,但是有時候收到貼五芒星的通知,感覺也是不錯啦。🤣

Canopy iOS Notification

另外就是像我這個 blog 是架在 github.io,每次 commit 跟 jekyll deploy 也會有通知,十分好用。

推薦給需要接收 GitHub 即時資訊的朋友。

iOS 12 相關技術新知

iOS 12 的新消息自從 WWD18 以後已經很多了。以下是 iOS 12 正式發表之際的資訊:

另外還有一些 apps 的更新:

fastlane.ci 停止開發

4 月提到的 fastlane.ci 現在已停止開發。😅

說明:

As we were building fastlane.ci we realized that it wasn’t going to cover all the requirements we wanted to support. We are currently in the process of re-evaluating our approach and are actively working on a better solution, subscribe here to be the first one to be notified about any upcoming launches.

還在等待的朋友可以去找別的解決方案了。

iOS 12 普及率預測與觀察

請見10/9 的更新


今年 WWDC 發表 iOS 12 beta 版以後,由於效能優化的評價良好,基於口碑效應,我就跟人家說這可能會是有史以來升級最快的一版。

不過不能只是說說而已,「最快」要怎麼衡量呢?

我的操作型定義是:

從 iOS 7 開始算起,用 Mixpanel Trends 的數據,觀察過去幾年每一版 iOS 正式版開放下載到市占率超過前一版所花的天數。

以下表格是我根據數據整理出來的:

Version Release 25% Cross 50% 75% Final % Source
iOS 12 2018/9/17 6️⃣ +10 4️⃣ +17 4️⃣ +19 ? ? 📈
iOS 11 2017/9/19 5️⃣ +7 5️⃣ +20 5️⃣ +26 4️⃣ +90 🥉 90.81% 📈
iOS 10 2016/9/13 4️⃣ +4 🥉 +16 🥉 +18 🥉 +89 🥈 91.27% 📈
iOS 9 2015/9/16 🥈 +3 🥈 +8 🥈 +11 🥈 +68 5️⃣ 86.36% 📈
iOS 8 2014/9/17 🥈 +3 6️⃣ +27 6️⃣ +32 5️⃣ +146 4️⃣ 90.50% 📈
iOS 7 2013/9/18 🥇 +1 🥇 +3 🥇 +3 🥇 +33 🥇 95.06% 📈

Cross 欄是該版正式開放直到與前一版黃金交叉所花的天數。Final % 欄是該版本的下一版正式開放前夕的市占率。Source 欄要注意的是 Mixpanel 網址所帶日期參數為相對數字。


表格剛出來就打臉自己了😅。看到 iOS 7 這種輝煌的成績,未來除非是 UI 風格大改版,應該是難以突破了啦🤪。

第二名的 iOS 9 也相當驚人,那一版的助力應該是大幅縮小升級所需的容量(在那個 16 GB 為基本款的年代),加上續航力大幅提升🔋,最為有感。

影響使用者升級的因素很多,其中一個是口碑*。iOS 12 的口碑就是跑起來明顯順很多,連比較舊的機種也變快了。衝著這一點,許多使用者應該是迫不及待升級才是。

如果這點成立的話,那我猜 iOS 12 跨過 11 的黃金交叉應該不會輸給 iOS 9 的 8 天太多才是

本文寫在 iOS 12 正式開放下載當天。待續…


* 另一個可能是出了新的 emoji 🤣