Ethan Huang's blog

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 相當期待!