Ethan Huang's blog

iOS 也有深色模式—智慧型反相

2016 年,Apple 給 tvOS 10 增加了深色主題設定(UIUserInterfaceStyle*)、2018 年 macOS 在 Mojave 也新增了深色模式,甚至連 Safari/WebKit 都可以告訴網站去支援深色模式(prefers-color-scheme)。但是 iOS 一直沒有全系統的深色主題或設定。

由於 iOS 的 UI 預設都是白底黑字或亮色系,大部分 app 如果不特別設計深色主題的話也就會是淺色,所以把螢幕顏色反過來就是一個建立深色模式的思路💡。

但是傳統的螢幕反相,就是單純地把輸出到螢幕的顏色反過來、黑白互換,類似於傳統底片的效果。遇到圖片就會慘不忍睹😂。直接拿來當深色模式是不堪用的。

螢幕顏色反相的設定在輔助使用裡面存在已久,但是我唯一聽過的使用情境,就是還在用傳統底片的攝影師,用相機 app 搭配反相模式來看她沖洗好的負片。


不過 iOS 11 新增了智慧型反相輔助功能。智慧型反相把 iOS 主畫面與 app icon 保留原本的配色,只是稍微降低飽和度。同時,app 可以指定忽略哪些 UI 元件。例如用來顯示圖片的 UIImageView 就不需要反相。對於大部分使用者來說,可以當作一個不錯的深色模式替代品。

把智慧型反相當作深色模式來思考的話,除了圖片以外,底色是深色的畫面就可以忽略反相。如果 app 本來就是以暗色為主的介面,那就可以全部忽略。以我公司 CATCHPLAY 的 app 為例,我們的主題一向是深色為主,因此可以把所有的元件都忽略掉智慧型反相。

要支援智慧型反相滿簡單的,就是把不要反相的 UIView 元件的 accessibilityIgnoresInvertColors 設為 true 即可。

如果整個 app 都不要反相,在 UIApplicationDelegatedidFinishLaunchingWithOptions 方法設定 UIView.appearance().accessibilityIgnoresInvertColors = true 即可。


正常的顏色:

Normal

智慧型反相的預設結果,效果跟經典反相一樣:

Enable Smart Invert

整個 app 的 UIView 都忽略經典反相,看起來大致相同。狀態列的顏色仍然是反過來的:

Ignore Invert

如果在意狀態列顏色的話,可以監聽系統通知 invertColorsStatusDidChangeNotification,並用 UIAccessibility.isInvertColorsEnabled 來判斷使用者是否啟用反相,然後再指定狀態列的 style。這個判斷名稱雖然沒有寫 smart,但是我實測它只會在智慧型反相時回傳 true,在經典反相時則回傳 false。


雖然說叫做智慧型反相,其實也沒有多智慧🤣,就是可以指定部分 UI 元件不要反相而已。也許你還會想,既然照片的顏色顛倒不堪用,為什麼智慧型反相時,系統沒有預設把 UIImageView 忽略掉呢?大概是因為 UIImageView 可以用來顯示照片,也可以用來顯示圖形按鈕。即使 UIImagerenderingMode 也不容易判斷,乾脆讓開發者自己決定。就像其他 accessibility 功能一樣,系統可以猜到大概,最後細節還是要留給開發者。

但這也導致絕大多數 app 的圖片在智慧型反相預設情況下很可怕,就連 iOS 11 初期版本的 WebView 與郵件也沒支援正確的照片顏色。開發者應該檢查一下自家的 app 在智慧型反相下的效果。

最後提供一個開發或測試的時候的小技巧,可以在系統設定➡️一般➡️輔助使用➡️最下面的輔助使用快速鍵勾選智慧型反相,這樣按三下裝置的實體按鈕,就可以快速切換。控制中心也可以放入輔助使用快速鍵項目。


補充資料:

*iOS 12 也新增了跟 tvOS 10 一樣的UIUserInterfaceStyle,但是沒有作用。

開啟智慧型反相時,在裝置上螢幕截圖還是會截出正常的圖片。如果要截圖的話要接上電腦用 Quick Time 來抓。

accessibilityIgnoresInvertColors 也可以在 Interface Builder 設定,在 User Defined Runtime Attributes 新增 keyPath 並設為 true 即可。細節可參考這篇文章

iOS 12 Adoption

Now that iOS 12 has been released for three weeks, let’s take a look at its adoption.

iOS 12 adoption by Mixpanel on 10/9

The table lists how many days does each version (since iOS 7) took to passed 25%, its previous version, 50%, and 75%. The Final% means its adoption date at the day its next version released.

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% 📈

Data collected from Mixpanel Trends.


iOS 12

  • 2018/09/17: Official released
  • 2018/09/27: Passed 25% after 10 days. The slowest since iOS 7 🙃
  • 2018/10/04: Passed iOS 11 after 17 days. It’s the 4️⃣th since iOS 7
  • 2018/10/06: Passed 50% after 19 days. Also the 4️⃣th

There are numerous factors contributing to the trends and I don’t plan to discuss here. However, while iOS 12 is probably the most stable version in recent years, its adoption rate is not growing the fastest compared to iOS history. It’s still remarkable that an OS with this large user base has half user upgrade within three weeks.

身為 iOS 工程師不該錯過的 iPlayground

最近台灣的 iOS 開發界有一個大事,就是即將在 10/20-21 在台大舉辦的開發者研討會 iPlayground。身為宣傳組的一員,我多半是用官方帳號小編的名義在做介紹。但我今天想用個人的角度談談 iPlayground,它的意義、以及為何你應該來參加。

我學習開發 iOS 已經超過五年。由於不是資訊相關科系出身,完全不認識其他同行,也沒有業界的朋友,前三年幾乎是自己在摸索。任職的公司 CATCHPLAY 願意栽培,2016 年送我去舊金山參加 WWDC。孤身一人踏上美國國土闖盪很有意思,但是我從頭到尾沒有遇到任何台灣人,吸收相對有限,也沒那麼好玩(而且,舊金山 6 月很冷)。

一直到 2016 年底我寫了一個開源的 app 叫 Blahker(專擋蓋版廣告,你可能有用過)。被 CocoaHeads Taipei 的成員 Vincent 邀請去分享。在那之前我都只是在網路上觀望,也不知道自己程式的實力如何。但就是那一次,我遇見了許多有趣的人,獲得許多迴響,也發現自己其實有一些特色是可以跟社群中的大家分享的。

有些軟體工程師寧可面對電腦也不願意面對人群。但是加入軟體開發的社群(任何形式的),對於個人只會有好處。我對自我學習能力很有自信,不過增加了社群參與以後,學習速度還會倍增。有問題你可以找人問、有可能從別人的分享中找到靈感,絕大部分的 bonus 都不是你個人的職涯規劃可以料想得到的。

比如說… 2017、2018 這兩年我就跟大家一起去 WWDC,玩得很開心。Apple 推了什麼新功能新技術,可以聽到不同的評論角度,觀點會跟更多元。有時候還湊熱鬧跑 lab 挑戰蘋果的工程師、甚至一起看個 NBA。上個月還去了東京參加 iOSDC。平時鑽研一些技術或是工作遇到的問題,隨便 PO 在 Facebook、Twitter 上就會有人神來一筆的回答。我最近一個開源專案 如果不是 @yllan 跟我在 Twitter 上往返,我可能兩個月也寫不出來。還有前前一個開源專案 也是在跟 @zonble 討論事情時想到的點子… 這裡不是要廣告自己的東西就不多說了。

iPlayground 是一群熱血的 iOS 工程師個人自發創立的,背後不是任何公司主導。這群人因為出國參加過 WWDC、iOSDC 等大型研討會,看到技術社群的價值、又發現台灣根本沒有這樣的活動,所以自己跳出來做,有一些成員還是因為一起籌備活動才認識的。期待它在台灣變成一個串連水果系技術資源交流、工程師人脈與求職、企業人力資源等各方面需求的平台。我們背後都是來自不同的公司,也沒有收益的目標(相反地,就算賠點錢還是想把這樣的平台做起來)。


你可以看看我們總召 hokila真誠介紹

iPlayground by Hokila


iPlayground 的票價是兩千元,因為在台北舉辦,場地就佔了很高的成本。坦白說由於第一次辦、經驗有限,我們犯了不少錯誤,包括時程安排、宣傳、預算規劃都有改進空間。但是就目前最重要的部分議程(見官網)來看我個人相當滿意。在台灣 iOS 開發圈你可以想得到的許多重要人物都出現在我們的講者名單上,他們也跟團隊成員一樣不支薪,是基於熱情來跟大家分享。我敢說任何去過 iOS 專門技術研討會的 iOS 開發者,一眼就可以看出這些議程跟這場活動的價值。甚至覺得物超所值。

WWDC 的票價就 1599 鎂,還不計算交通食宿。就算去東京參加 iOSDC 也要機票啊。而且只有在台灣舉辦你才能用熟悉的語言與大家交流。

如果沒參加過 iOS 研討會,這其實只是稍微離開自己的舒適圈一點點而已,卻有莫大收穫。就算只參加半天,也是值得。

最後必須提醒,由於活動僅剩三週,眼下看似還有一百多張票可能轉瞬就消失。所以有一點心動還是趕快行動吧。

你還在猶豫是因為你想要!

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 🤣

在 Xcode 10 模擬器上跑 Xcode 9 build 的 app

如果還不急著切換到 Xcode 10,可以使用這個技巧來測試 Xcode 9 build 出來的 app,跑在 iPhone XS Max / XR 模擬器的情況:

  1. 用 Xcode 9 選一個模擬器為目標來 build
  2. 在 Products/OOO.app 上按右鍵、Show in Finder
  3. 打開 Xcode 10 的 Simulator app,Hardware 選 XS Max 或 XR
  4. 從 Finder 裡把 OOO.app 拖拉到上述的 Simulator 視窗裡(會安裝)
  5. 點開 app 來觀察狀況

以上方法來自這篇文章的 Wait, What Did You Say? 那一段。

發表會後搶先版:iPhone XS Max 與 XR 開發注意事項

2018 蘋果秋季發表會在 9/13 結束了。iOS 開發工作要注意什麼?

  • 新裝置的官方的教學影片系列
  • 更新版的 HIG
  • iOS 12 GM 已開放下載
  • Xcode 10 GM 已開放下載,可以升級到 Swift 4.2 了
  • 可以用 iOS 12 SDK 上傳至 App Store 了
  • 如果要上傳新版,原來是 iPhone X 的 5.8 吋的可選截圖已增加 6.5 吋,如果上傳 6.5 吋會自動產出 5.8 吋版本
  • Build 自己的 app 試跑 iPhone XS Max 跟 XR 看 UI 是否正常。例如這種同時有橫版、home indicator、瀏海的排版。參考
  • 這兩款的螢幕不同但是 pt 相同,設計時可視為同一種尺寸。XR 要 10 月才開賣。基本上支援好 XS Max 就可以了
  • iOS 11 SDK 有支援上述兩款新機的解析度,所以如果你的 app 是用 Auto Layout 而不是寫死來支援 iPhone X 的話,還不需要急著重新上傳 App Store。來源
  • iPhone XS 螢幕解析度跟 iPhone X 一樣
  • 各種螢幕解析度的差別可以參考這篇
  • 如果你是第一次載 Xcode 10 來用,然後發現 app build 不過,請注意 Xcode 10 預設用 New Build System。如果要改回舊的請去 File/Workspace or Project Settings 改成 Legacy。詳情請見 Xcode release notes

FoundationDB

蘋果今天將一套 noSQL 資料庫軟體 FoundationDB開源出來。這個名字很蘋果。釋出的版本是 5.1.5,看來有點歷史了,但之前沒聽過。出於好奇查了一下它的背景。

FoundationDB 本是一間 startup,以及同名開源資料庫軟體。蘋果在 2015 年把這間公司買下後把軟體閉源,作為內部使用。現在又重新開源起來。

(根據當年 Business Insider 的報導,蘋果收購與閉源 FoundationDB,造成不少公司的麻煩啊…)

至於 FoundationDB 軟體本身是幹嘛呢?資料庫我實在不是很懂,不過看了一些介紹,它擅長做大型分散式服務,不僅高效、有彈性,而且還具有硬體成本優勢。

據說蘋果是把它用在 iMessage 等大型服務的設施上(品質應該比什麼 UIKit、Swift、Xcode 之類的好得多吧 😂)。既然重新開源了,可以觀察一下。

git 不能保證專案在每台電腦上的狀態完全一樣

A quick reminder for iOS dev: git status clean != everything the same between 💻 machines 🖥:

  • Files in .gitignore: Non-shared Scheme/Workspace settings 🛠
  • Empty folders: Search Paths 👀
  • Case-insensitive FS: Change name case of files in .xcassets, crash on #imageLiteral 💥

git 不能保證專案在每台電腦上的狀態完全一樣。以我曾遇過的坑為例:

  • 列在 .gitignore 的檔案:scheme 或 workspace 的設定,如果不是 shared,每台電腦可以完全不一樣。天差地遠
  • 空的資料夾:同事換了 framework 的位置,但 Header Search Paths 設定沒拿掉舊的。他的電腦可以 build,我 pull 後卻不行,因為我的空資料夾還在
  • 檔名不區分大小寫的檔案系統(Mac 預設):把 xcassets 底下的檔案大小寫改掉。git 看不出來差異,build 得過,但是 runtime 時 #imageLiteral 這種 code 會 crash

不是要提出解法,只是講一下有這些坑

Modern iOS dev life

  • Xcode 9.2 for main project until its next release⌛️
  • Xcode 9.3 for iOS 11.3 development and Swift 4.1 side project. High Sierra required⛰️🧗‍♀️
  • Xcode 9.4 beta for iOS 11.4 beta⚠️

Also, never get Xcode via MAS🚫. Directly download from /download/more/

簡單說一下 fastlane.ci

昨天 4/7 在 @johnlinvc 的大力協助之下,fastlane 開發團隊成員 Felix(@KrauseFx) 與 Josh(@taquitos) 在 iCHEF 樓下的場地介紹了 fastlanefastlane.ci

fastlane 大家比較熟悉,就是把行動應用開發中,主要跟認證簽署及發佈相關的流程(當然還有更多)給自動化,並且統統加入版控。優勢是開發工具的環境設定都可以在 repo 裡面一起管理。

這樣一來,就算你今天換個地點、換了一台電腦,或是來了新夥伴,只要能夠 checkout 就可以無縫接軌。這精神在其中的套件 match 尤其徹底發揮。(這會讓人想把整個系統會用到的設定都給版控化,不過這是另一個題目了)

基於同樣的理念,fastlane.ci 是把連續整合的流程也版控化。如果有用過 Jenkins 或其他 CI 系統就會知道環境設定有多麻煩,還很難管理。用 fastlane.ci 的話,原則上架設一台新的 CI 只要 checkout 就可以掛好所有設定,然後工作流程就可以繼續囉。

fastlane.ci 前幾天才剛 alpha,昨天則是首次 live demo👏,Felix 跟 Josh 他們建議至少到 beta 再來用。當然你很勇敢也可以 alpha 就來玩,然後認真報 bug。fastlane.ci 是完全開源的,有興趣的話也可以 contribute。另外就是他們強調團隊會有 Google 的 designer,所以到時候一定會比某 CI 好看、好用😂

我個人是 fastlane 的長期愛用者,對 fastlane.ci 相當期待!