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 則是原生解析度。
另外一點,A12 晶片用了一個叫做 arm64e 的新 architecture ,用 Xcode 9 要 build & run 到 XS Max 上會顯示以下資訊:
依照錯誤訊息在 build setting 加上 arm64e 也沒用,因為 Xcode 9 就是不支援。
結論就是,如果要支援 iPhone XS Max 的原生解析度或是進行 Max 的實機開發,一定要用 Xcode 10(廢話🤣)。但如果暫時還維持 Xcode 9 的話,使用者會看到 iPhone X 放大版的內容。放大的程度並不明顯,不仔細看是看不出來的。
* Knil 是我撰寫的開源且免費的 Universal Links 測試工具
GitHub 一直都沒有推送的功能。是有 Webhook 可用,很多人可能是用 Slack 接 Webhook 來接收通知的。不過如果參與的開源專案比較多,一個一個設定 Webhook 就太麻煩了。
Canopy 是用來在 macOS 與 iOS 上接收 GitHub 通知的工具。作者是 Max Howell (@mxcl)。如果你不知道 Max 是誰,他就是 Homebrew 與 PromiseKit 的作者。他本人說,GitHub 推送通知的功能他等了十年也沒等到。對於開源專案來說,漏掉重要訊息太傷了,乾脆自己來寫一個。
For 10 years I’ve wanted an app that does push notifications for GitHub. For 10 years there has been nothing. So this year, fed up with not being able to respond to important events in realtime, I wrote the app. Free for open source, check it out. https://t.co/L2mv2v91Kk
— Max Howell (@mxcl) 2018年9月4日
9 月剛推出 v1.0,還熱騰騰
Canopy 的 macOS 版 在 Mac App Store 可免費下載,iOS 版 則是 4.99 USD,支援開源專案的即時訊息,像是:
如果要支援私人專案的通知,則要另外付費訂閱服務。這種設計跟 GitHub 的方案一樣,是鼓勵開源專案的。
介面很簡單,可以輕易地勾選要接收通知的專案。值得一提的是兩個版本是會同步的,我第一次打開 iOS app 就看到 Mac 登入好的設定,非常貼心。😍
(小插曲,我第一次打開 iOS app 其實有遇到通知權限沒有被詢問的 bug,回報作者以後他也馬上修好了。⚡️)
如果你仔細看官網的 FAQ 會發現竟然有這麼多注意事項,感嘆這麼基本的需求,GitHub 官方竟然搞得這麼麻煩。😓
我平時常在 GitHub 上維護或參與的專案超過五個,雖然沒有很頻繁的消息,但是有時候收到貼五芒星的通知,感覺也是不錯啦。🤣
另外就是像我這個 blog 是架在 github.io,每次 commit 跟 jekyll deploy 也會有通知,十分好用。
推薦給需要接收 GitHub 即時資訊的朋友。
iOS 12 的新消息自從 WWD18 以後已經很多了。以下是 iOS 12 正式發表之際的資訊:
NSCoding
、UserDefaults
等的變更URLRequest.networkServiceType
的新選項、CLLocationManager.activityType
新增了飛行模式✈️。值得一讀另外還有一些 apps 的更新:
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.
還在等待的朋友可以去找別的解決方案了。
請見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 🤣