13 重拾程式解題的樂趣 - Advent of Code

Wed, 04 Dec 2019 00:00:00 +0000

你有做過線上解題嗎？像是高中生軟體比賽會寫的 ACM Online Judge，或是有些軟體工作面試要求考演算法，而要刷的 LeetCode。

我不喜歡寫這些，雖然富有挑戰性，說實在並不有趣。如果想要享受純粹的解題樂趣，我不會去寫 LeetCode。

直到最近我發現一個只在每年 12 月才會有的解題活動：Advent of Code。

它是一人專案，作者是 Eric Wastl (@ericwastl)。這個活動從 2015 年以來已經是第 5 年了。

什麼是 Advent of Code

Advent 是天主教專有名詞，你可以簡單理解成「耶誕節倒數」（維基百科）。所以 Advent of Code（以下簡稱 AoC）的活動是在每年的 12/1 到 12/25。

在這 25 天中，每天都會公布兩題（通常）要寫程式才能解決的題目。時間是台灣的下午一點。

第一題通常不會太難，而你要解開第一題以後才會看到第二題的題目，是第一題的變化。很有可能顛覆你前面的思路跟設定。我喜歡這種變化題的設計方式，可以打破慣性思維。

實際解了幾題，我發現就解題樂趣而言，AoC 比 LeetCode 好玩很多。

LeetCode 的解題過程大致上是：

挑題目（有些要付錢）
理解題目（同時心裡想著，不會吧，這題是 Easy？）
在網頁介面上寫程式來：
- 處理輸入的測試資料
- 解題完回傳答案
送出程式碼讓 LeetCode 後台執行
要考慮到 edge cases
要考慮到執行時間，解完以後還會跟別人比較

而 Advent of Code 的解題過程則是：

有一個簡單的背景故事（例如聖誕老人被困在太陽系某處，你要幫助他 blah blah）
每天準時公布題目
一組資料
一個答案輸入框
解題方式隨意
第一題解完會有第二題
答錯的話要過一分鐘才能重試

以下說明 AoC 的幾個特色。

解題方式隨意

2019 Day 1-1 這題，其實我是在手機上複製貼上到 Numbers app 解的😆

因為它的題目非常簡單，大意是：

聖誕老人的太空船上的各種模組要消耗燃油。它列給你所有模組的重量，然後你用簡單的四則運算求出對應的燃料重量，再加總。

所以用試算表秒解。而且不是只有我有這種想法。

變化題

當你把 1-1 解完以後，「故事」才會往下展開。看到 1-2 這題就有趣了：

原來你剛才忘記計算燃料本身的重量了。每次增加燃料的同時，你要再增加一定的燃料，如此反覆直到某個條件為止。

這就不能用原本的方式計算，所以我才打開電腦寫程式，順便重寫第一題。

邏輯變了，但資料沒有變。我只要調整計算方式。

比較少在處理資料，比較多在解題本身

在寫 LeetCode 時，有好一部分時間是在處理資料的輸入格式，這個部份特別無趣。

AoC 你可以隨意。因為資料只會有一組而且是公開的，不需要像 LeetCode 反覆嘗試來處理各種「規則有寫但看不到範例」的 edge cases。

每天的兩題共用同一份資料，所以即使第二題的邏輯不同，你初始處理資料的程式碼通常也可以沿用第一題。

這些條件與設計，就讓人更專注在解題而不是處理資料格式。

題目難度

2019 前面四天每天有越來越難的趨勢。

活動玩法

既然是玩法很自由的解題遊戲，你要怎麼做都可以。你可以跟高手比賽解題速度，每天下午一點公布題目後就開始寫。如果前 100 名的話，會得到 (100 - N + 1) 點積分，可以累積積分來排名。但是排行榜上都是在幾分鐘內解完，我可能題目都還沒理解完呢😂

所以我的玩法是志在參加，有把題目都解出來就好。我是用 Swift + Playground。每解完一題就 commit 起來。

解完之後再去看討論。以後學了其他語言也可以回來解一次。

AoC 也支援私底下的排行榜，可以跟朋友同事切磋。

救命，解不下去

不確定題目意思可以跟我在 Twitter 討論。

凡是公開題目就會有公開解答。GitHub 有一些可以參考，Reddit 也有很多討論。甚至還有人靠 Siri 解題！？（1-1 還沒解完的不要看）

不過我覺得前幾天的第一題的難度真的沒有太高，可以多試幾次再去看討論。

費用

AoC 完全免費！甚至不用登入就可以看題目。

只要用 GitHub、Twitter 等註冊帳號就可以開始填答。

若你覺得這個活動很有趣，可以考慮捐助，金額隨意。

歷史題目

我是從今年才開始玩的。但是 2015-2018 也各有 25 * 2 題可以回去解。

結語

對你來說，線上程式解題是好玩、痛苦，或是苦樂參半的經驗？

前陣子在 Twitter 上有看到一陣在討論 LeetCode 怎麼刷、怎麼買（中文版比英文還便宜）。看到討論時，我比較有興趣的卻是，這種線上測驗的專案是怎麼做起來的啊？

等到我看到 @ericwastl 創造的 AoC 發現，這個專案是他一個人從頭搭建的，題目也都是自己想的。他甚至說，為了避免法律爭議，即使寄給他題目的建議他也不會讀，免得不小心用上了這些點子。我覺得這位工程師以及 AoC 這個專案，甚至比解題本身甚至更有意思。

也許我們應該思考怎麼創造出題目，而不是只會解題而已？

總之，AoC 是一個很有趣的程式解題活動，有空的話一起來玩吧。

可以來我開好的 Leaderboard，輸入747723-067e3e4b加入，已經有一些推友在上面了。我會把 anonymous user 移除，所以請記得到設定把自己的名稱顯示出來。

或者是只跟自己比也完全沒問題。

AoC 刷起來！

如何管理 Xcode 版本才不會害到自己跟團隊

Fri, 01 Nov 2019 00:00:00 +0000

身為一個 iOS 工程師，我們應該對自己的開發工具有完整的掌握。最常使用的就是 Xcode。

我注意到開發者很常踩到 Xcode 在安裝、版本選擇方面的坑，所以決定來分享一下自己是怎麼管理 Xcode 版本。

安裝與下載

不要透過 Mac App Store

開發者最常犯的錯誤大概就是用 Mac App Store 下載 Xcode 了。使用 MAS 看似方便，但是後面會有各種無法掌握的因素。比如說：

下載不了…

類似的抱怨在 Twitter 上隨便找都一堆。

更新了一个星期的 xcode还没成功……
— Jia (@deepjia) October 13, 2019

连续两个星期没法从 MAS 里安装 Xcode 之后，我选择： pic.twitter.com/Ha1za3fTBO
— 迟先生的星星球 (@iskyzh) October 16, 2019

低能安裝過程…

幹你娘低能 Apple Store，Xcode 下載完跟我說要關閉 Xcode 才可以安裝，但我沒開 Xcode 所以想說先按取消再試一次，結果他給我重新下載...
— Haruka (@hirakujira) September 21, 2019

下載失敗浪費空間…

Xcode 升級下載失敗就算了，每次安裝失敗還留一堆垃圾檔案在系統裡。

全部反安裝再試一次。
— OOBE (@OOBE) October 29, 2019

正要用的時候，自己手賤或是系統犯賤幫你更新…

我覺得這個超慘的耶🤦‍♂️

我說那個 Xcode 可以不要挑正要驗收時更新嗎⋯⋯
🤦‍♂️🤦‍♂️🤦‍♂️
— 餿腐味粗工 (@joe_trash_talk) September 25, 2019

而且強迫症的你還糾結著那該死的紅點…

升上10.15.1终于把xcode的更新安装完了，终于不用见到那个该死的红点了。
— 工藤龍一郎 (@BakeCom) October 30, 2019

其他缺點

同時只能保留一個版本
一直跳出更新提示

你完全可以避免這些問題😎，以下提供兩種方式。

直接從 Apple Developer 網站下載 Xcode

其實 Apple 官網一直有下載 .xip 壓縮檔版本 Xcode 的連結，但是藏得有點深。

下載頁面的首頁是 https://developer.apple.com/downloads。而列出下載檔的位置是在 https://developer.apple.com/downloads/more。都需要登入開發者帳號。

要去按 More，是不是藏得有點深…

是說，這邊最早還可以下載到 Xcode 3.2 呢。

自己下載唯一的缺點就是，通常這個版本會比 Mac App Store 還要晚個半天才會放上去。

但我通常都會在 Twitter 觀察一下災情，才決定要不要抓新版，所以沒差。

透過 xcode-install 套件管理 Xcode

如果你覺得手動下載、手動解壓縮好蠢，那麼來用 command line 吧。

xcode-install 是一個很方便的 Ruby 套件。

安裝 Xcode 11.0 只需要兩行：

gem install xcode-install
xcversion install 11.0

就會登入（使用跟 Fastlane 一樣的 Keychain 機制）、下載，並且解壓縮。

甚至可以列出所有可下載與已安裝的版本：

xcversion update
xcversion list

Xcode 與 iOS 相容性測試

（2020/06/23 更新：本段落舉例版號改成 WWDC20 推出的新版本，以利閱讀）

每次 Apple 發表新版 Xcode 的 beta 版以後，尤其是 WWDC 的年度大版本，開發者應該將 beta 版抓下來做專案的相容性測試。

我們應該要測試相容的有哪些呢？以下為了方便說明我們把時光假定為 beta 版期間。

以 2020 年發表的 Xcode 12 與 iOS 14 來說，相較於前一代的 Xcode 11 與 iOS 13，會有以下四種組合：

	Xcode 11	Xcode 12 beta
iOS 13 或更早	A. 現況 🔁	C. 向下相容 ⬇️
iOS 14	B. 向上相容 ⬆️	D. 新東西 🆕

通常 A、C、D 這三種情境我們比較熟悉，也比較容易。

A. 現況 🔁

專案在目前 Xcode 正式版的相容性，也就是現況。

B. 向上相容 ⬆️

專案在舊版 Xcode 上 build 出來的，跑在新版的 iOS beta 裝置。比如 Xcode 11.5 正式版去連接 iOS 14 beta 裝置。

這一塊可以說是個大盲區。你想想看當新的 iOS 正式推出的時候，使用者可能就升級上去了，但你不見得已經準備好支援 iOS 14 的 app。就算準備好了，他們也不見得會更新 app。

這明明就是在新版系統正式推出以後，使用者最有可能遇到的情境。但是 Apple 從來就沒有為了向上相容的測試提供方法。把一台 iOS 14 的裝置接到 Xcode 10，會告訴你不支援，系統版本太新，沒辦法 run 在實機上。這樣子要怎麼確保向上相容呢？

幸好，要讓 Xcode 去支援它本來不支援的新版系統，只需一個關鍵—DeviceSupport。我們可以從新版 Xcode 裡面把對應的 DeviceSupport 資料夾，看是要用 symbolic link 還是複製一份的方式。我是比較推薦前者。

我寫了一個 gist 來做這件事情，裡面還有 watchOS 與 tvOS 的指令。你可能得依照自己的 Xcode 路徑來修改指令內容。

唉呀，其實我在 2017 年就寫過類似的文章了。

C. 向下相容 ⬇️

專案在新版 Xcode build 出來以後，跑在舊版的 iOS 裝置。比如 Xcode 12 beta 連接 iOS 13 裝置。

WWDC 新版 Xcode 出來時，Apple 會希望你下載最新的 beta 版，來做向下相容的測試。直接把舊系統的裝置連到新版的 Xcode，通常安裝 app 不會有問題，我們要留意的是跑起來以後，新的 SDK 怎麼樣相容舊版系統，有沒有一些壞掉的情況。

一般來說向下相容比較不會有問題，因為 Apple 必須確保系統升級不會讓原有的應用程式無法使用。

而且除非你要升級 Xcode，不然這件事也沒那麼急。

D. 新東西 🆕

專案對於新系統、新版 Xcode 的相容性。現有專案直接用新版 Xcode 打開看能否 build。比如 Xcode 12 beta 跑在 iOS 14 beta 裝置。

這邊主要看的是專案對於系統的相容性。越早版本的 beta 問題當然是越多。

但是除非你的產品非得要用到最新的 API，要不然 D 這個部份的相容性應該是最不急迫的。

就一個成熟的產品或是日常工作來說，我覺得處理的優先順序應該是 A 現況 🔁 > B 向上相容 ⬆️ > C 向下相容 ⬇️ > D 新東西 🆕。

2019 年大家都興沖沖地跑去玩 SwiftUI 或是 Combine，然後才發現坑超多。其實那些都是屬於 D 的部分，優先度最低🤣

以後 Apple 再發表新東西，我們最好還是吸取教訓，先搞定 A、B、C，再來玩玩具。

團隊協作

指定 Xcode 版本

有多個版本 Xcode 的話，用 xcode-select 來指定要使用的 Xcode 的路徑。這應該是基本功夫。

sudo xcode-select -s /Applications/Xcode.app #路徑

在專案中鎖定 Xcode 版本

我建議在發布 app 時使用 Fastlane，就可以用 ensure_xcode_version 來確保版本。

確定 Xcode 是沒有被動過手腳

你可能聽過 XcodeGhost 事件。下載來路不明的 Xcode 是有可能抓到被駭過的版本。

使用 Fastlane 的 verify_xcode 可以幫忙確認 Xcode 的 code sign，以及用 GateKeeper 檢查。

想要自己跑指令的話，也可以參考這裡。

不過要注意的是，這個動作要跑好幾分鐘，比較建議是在出正式 Release 的 lane 再跑。

另外，如果因為前述的向上相容，而改過 DeviceSupport 資料夾的話，驗證會失敗。

我們到底要保留哪幾版 Xcode？

這完全是要看你手邊專案的狀況。三個版本不算誇張：

前一個正式版，如果舊版 app 出了問題可能要回去看。比如說你舊版 app 的 Swift 版本是上一代
目前的正式版，用在最近上架更新的 app
最新的 beta 版，如果要使用一些新系統才有的 API

我以前也舉過一個例子。

結論

iOS 開發者的電腦硬碟要買大一點，MacBook Pro 要 512 GB 以上。

不是啦，講認真的：

不要用 Mac App Store 安裝 Xcode，從官網的 More 下載，或透過 xcode-install 管理
弄清楚相容性測試的優先順序
可以透過 Fastlane 幫助團隊管理 Xcode 版本

同場加映

空間清理工具

每次更新開發裝置的 iOS 版本以後，記得把電腦上舊的 cache 給清除。身為 Xcode 使用者，一次清出幾十 GB 也是很常有的事。

如果你偏好無腦解，DevCleaner 或 Cleaner for Xcode
如果你偏好自己來，GrandPerspective

跨版本安裝模擬器

皮樂的手動安裝 iOS 模擬器到 Xcode
我寫的在 Xcode 10 模擬器上跑 Xcode 9 build 的 app

其他資料

#我會刷掉
從 Xcode 正式版連到 iOS beta 版裝置
weak self 0: 如果你想要浪費一個人的暑假這集有聊到開發者該怎麼分配 WWDC 到正式版上架這段期間的時間與資源
weak self 9: 帶你親臨 iPlayground 現場最後一段有講到不要用 Mac App Store 安裝 Xcode
weak self 13: 喬喬 Erasure 前面有聊到 xcode-install
Modern iOS dev life

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

Tue, 30 Oct 2018 00:00:00 +0000

2019/01/04 更新：

這篇文章本來是寫在 iOS 12 時代，可以忽略了。現在請愛用 iOS 13 的 Dark Mode。

2018/11/30 更新：

如果要將整個 app 反向的話，不能用 UIView.appearance().accessibilityIgnoresInvertColors = true ，否則會遇到問題。官方回說可以在各個 viewController.view 做設定。

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 即可。

2018/11/30 更新：請不要這麼做🚫 ~~如果整個 app 都不要反相，在 UIApplicationDelegate 的 didFinishLaunchingWithOptions 方法設定 UIView.appearance().accessibilityIgnoresInvertColors = true 即可。~~

正常的顏色：

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

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

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

雖然說叫做智慧型反相，其實也沒有多智慧🤣，就是可以指定部分 UI 元件不要反相而已。也許你還會想，既然照片的顏色顛倒不堪用，為什麼智慧型反相時，系統沒有預設把 UIImageView 忽略掉呢？大概是因為 UIImageView 可以用來顯示照片，也可以用來顯示圖形按鈕。即使 UIImage 有 renderingMode 也不容易判斷，乾脆讓開發者自己決定。就像其他 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

Tue, 09 Oct 2018 00:00:00 +0000

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

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

Mon, 01 Oct 2018 00:00:00 +0000

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

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

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

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

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

iPhone XS Max 與 Xcode 9 相容性分析

Fri, 21 Sep 2018 00:00:00 +0000

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 則是原生解析度。

iPhone X
iPhone XS Max, Xcode 9 (iOS 11 SDK), 放大模式
iPhone XS Max, Xcode 10 (iOS 12 SDK), 放大模式
iPhone XS Max, Xcode 9 (iOS 11 SDK), 標準模式
iPhone XS Max, Xcode 10 (iOS 12 SDK), 標準模式

另外一點，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 即時通知 - Canopy

Thu, 20 Sep 2018 00:00:00 +0000

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，支援開源專案的即時訊息，像是：

Commit
New issue
New pull request
Issue reply
Star
Follow
…

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

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

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

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

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

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

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

iOS 12 相關技術新知

Tue, 18 Sep 2018 00:00:00 +0000

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

Foundation Release Notes 提到 NSCoding、UserDefaults 等的變更
iOS 12 Security 是每年更新的安全白皮書。這是第一次跟 iOS 正式版一起發表
Swift 4.2 正式發表。另外可參考 Ole 的 What’s new in Swift 4.2 Playground
Safari、iCloud Keychain、WebKit 新功能推文串 - 這串推文是 Apple 員工自己寫的，有很多小地方更新值得快速複習一下
你應該已經看過的 New Apple Developer Videos，連同 iPhone XS 等新機一起推出
NSHipster 的 iOS 12 專文講到一些冷僻的 API，像是 URLRequest.networkServiceType 的新選項、CLLocationManager.activityType 新增了飛行模式✈️。值得一讀

另外還有一些 apps 的更新：

Shortcuts.app（中文翻成捷徑）已上架並取代 Workflow.app
MacStories 寫的 iWork 更新資訊
1Password 跟 LastPass 已支援 iOS 12 的自動填寫密碼鍵盤⌨️功能

fastlane.ci 停止開發

Tue, 18 Sep 2018 00:00:00 +0000

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 普及率預測與觀察

Mon, 17 Sep 2018 00:00:00 +0000

請見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

Fri, 14 Sep 2018 00:00:00 +0000

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

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

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

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

Thu, 13 Sep 2018 00:00:00 +0000

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

Thu, 19 Apr 2018 00:00:00 +0000

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

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

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

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

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

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

Wed, 11 Apr 2018 00:00:00 +0000

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

Mon, 09 Apr 2018 00:00:00 +0000

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

Sun, 08 Apr 2018 00:00:00 +0000

昨天 4/7 在 @johnlinvc 的大力協助之下，fastlane 開發團隊成員 Felix(@KrauseFx) 與 Josh(@taquitos) 在 iCHEF 樓下的場地介紹了 fastlane 與 fastlane.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 相當期待！

13

重拾程式解題的樂趣 - Advent of Code