iOSDC 2024 導讀(上)
前情提要
我是從 2017 開始參加 iOSDC 的，就我有記憶以來，除了疫情那幾年是線上辦以外，2017 到現在一直都是在早稻田大學舉辦，每年規模都差不多。
雖然名字叫 iOSDC，但是內容只要跟 Apple 或者說軟體開發沾上邊的，都會出現，大概 80% 以上是開發相關的題目，剩下的是設計與心靈成長類的，身為一個 developer，第一次去的時候很興奮，因為這邊關於 iOS 相關議題的深度廣度，都是我在其他地方沒有看過的。之後興奮感就逐年下降，近幾年都是線上參加。
今年是在 8/22–8/24，前幾天把今年的影片公開了。
因為今年三月我已經去過 try! Swift Tokyo，把家人留在台灣，我感覺到巨大的罪惡感，所以說今年就沒有參加 iOSDC 了，連線上也沒有。
參加心得
雖然我沒有參加，不過有其他人寫的心得
https://fortee.jp/iosdc-japan-2024/blog-link
今年的議程
這是今年的 playlist，扣掉主辦單位的介紹，總共有 92 場 session/talk，雖然裡面有部分是 lightning talk，不過這個數量也是非常驚人。
以下來介紹幾篇我聽完覺得很有趣的 session/talk，學習新知的同時也練習日文，其實蠻賺的。以下只是寫心得，不詳細解釋，因為我不是作者，只能把自己理解的跟心得寫出來。
把新 OS 的功能 backport 到古早的 OS
backport 其實在過去發生過很多次，常常我們在新 OS 看到好用的寫法，但是自己的 app 只支援舊 OS，就會想要做 backport。我最早看到這招的是在 UIStackView，UIStackView 是 iOS 9 推出來的好用 UI layout compoment，但是 FDStackView 支援到 iOS 6，而且連 storyboard 裡面都可以用，就很誇張。
還有這邊把 UICollectionViewCompositionalLayout backporting 從 iOS 13 到 iOS 10，這些 backport 會隨著支援的 OS 越往上升而不被需要，但是只要新 OS 有推新功能，就會有新的 backport 跑出來。
實作方面：
- 新功能 Open Source 後在原本 OS 上面，直接實作出來新功能，但缺點也很明顯，就是原本 OS 裡面的 code，變成到 app 裡面，需要稍微增加 app size。
- 如果沒有可以參考的 code , 那就只好自己實作
- 一樣的接口，內容實作用
if (@available(iOS 10, *)) {分開
比較常看到的 backport 都是 UI 系列的，最後也推薦了幾個現在比較好用的 backports repo 像是 swiftUI 的 https://github.com/shaps80/SwiftUIBackports
Ditto SDK 介紹，沒有網路連線的時候穩定的同步資料
DittoSDK 是個 SDK，在沒有網路連線的時候，和周圍的機器建立 mesh 網路，利用 P2P 的方式更新資料。實際場景，像在飛機、工廠和建築工地上面的都有實際案例。JAL 與 ANA 都有導入。
當然最外面還是要有可以連上網的機器，這樣才能跟 server 溝通，然後再靠這台把資料同步給 mesh 內的所有 client。使用 CRDT 數據結構來避免 data conflict。
聽他在講的時候，讓我回想到以前做遠端桌面 app 的經驗，一樣是要找出最佳傳輸路徑，一樣是要把封包切細，把 performance 最佳化。但是明顯他使用的技巧比我當時用的複雜多了，比如說 Wifi Direct 跟 Bluetooth 我就沒接過。
我覺得這篇對於有在做資料傳輸的 developer 都很值得一看，透過各種方式，不放手直到資料到手。
在 12 分開始有 show case。介紹在 POS 機，飛機上，臨時工地上面的實際使用案例。最後講解如果要串接 DittoSDK 的話要怎麼接。
工程師在面對複雜任務時的思考方式和應對策略
我在看的時候發現同一位作者去年也講過類似題目，去年是講怎麼讀 source code
這篇是我在看別人心得文的時候，很常被提到的一篇，果然心靈雞湯類的都很容易推廣。同樣的題目拿去其他語言的 conf 也一樣實用。
首先人的認知資源是有限的，像是集中力注意力記憶力自制力之類的，同時能記的事(working memory) 大概也就是 3~5 件而已，被干擾時能處理的事就更少了。但是透過有效的訓練，像是好吃好睡，有氧運動，桌遊，語言學習，背單字之類的訓練，可以增加 working memory ，就變強了。另一方面，減掉負荷也有幫助，例如把任務分成更小的部分，記錄下來並發送給團隊成員，有助於分散大腦的負擔。
對我來說，我在事情卡住的時候，比較喜歡用第三者的角度來看，比如說把我現在要處理的問題跟我的能力跟 GPT 講，請 GPT 給我建議，或者用小鴨 Debug 法也很有用。
MPEG構造を把握し、VideoToolBoxを使った特殊再生の実装方法を理解する
做影片編輯 app 的人必看，做 streaming 的話可能也會用到，如果你需要做 AV sync 的話。這場集中在 AVPlayer 播放 local file。
這場 session 首先簡介了 MPEG 的歷史，播放的 flow，還有絕對避不掉的一些專有名詞，PTS(Presentation Time Stamp) 和 GOP(Group of Pictures)，跟快轉縮圖。 line by line 解釋影片播放過程，用 videoToolBox 做硬體加速，還有動畫很認真，好幾個 demo，很舒服的 talk。
但是，這個 topic 實在是太大了，我覺得還可以講這些：
- bitrate /resolution/decoder 的比較
- HLS 的作法，HLS 甚至可以分 vod/live/fairplay/local hls 的版本
- 各種 workaround
這場也是我看很多人 blog 裡面都有提到的一場 session，身為曾經待過 streaming 產業的人，我非常希望可以看到更多類似的 session。
GIS入門 — 來做地圖吧
其實我是先認識這位作者，才想看這篇的，他一直以來的題目都很有趣。這種特殊主題的題目，前面都要花一些時間介紹基本觀念，「你在用 MapKit 的時候有想過要怎麼做地圖嗎？」因為我之前沒有自己畫地圖過，大概就是用景仰的心態在聽這場，基礎知識講完，成果如下：
- 利用 mapbox 做自己的地圖，做出來像 pokemon Go 的畫面。
- 2D 資料配合等高線資料，做出 3D 地圖
看完覺得真的很帥啊，清楚解釋做出地圖需要的基礎知識。還留個伏筆，下次要加上建築物了嗎？
Server-Driven UI入門，畫面組起來
如果可以使用單個 API 接收整個畫面需要的東西，那麼 app 將保留什麼樣的邏輯呢？是不是 app 裡面連 if else switch 都不用寫了呢？藉由 middleware BFF （Backend for Frontend），盡可能多地將邏輯引入後端。
在看這篇的時候，就想到一直以來跟 Apple 對抗的熱更新，目前發現的所有熱更新作法，如果送審的時候被發現， 就一定會被 reject。
首先介紹了 Server-Driven UI，從 WWDC 2010 的時候官方就有提過，Spotify 2016 跟 AirBNB 2021 也發表過他們的做法。藉由預先定義好的 compoment/State/Action，server 告訴 app 要怎麼組裝。藉由這個方式，甚至 business logic 都可以不用放在 app 裡，同一個做法擴展到全平台，除了可以省下巨大的開發時間外，還可以省下驗證不同平台的差異。用不同的 UI，也很適合用來驗證 A/B Test。
聽起來就很適合有多語系，需要對不同地區不同活動做微調的 app，，像是開店 app 電商 app。
利用 Mergeable Library 實現 app 快速啟動
Static Framework 和 Dynamic Framework for iOS 應用程式之間鏈接執行時間的差異，並介紹了 Mergeable Library，在組織了各自的優點后，可以實現兩全其美，以及實際的性能提升效果。
Debug 時用 Dynamic Framework，在 Release 時使用 Static Framework。
自從電腦換成 M 系列以後，我對於這種提升效能的議題就越來越無感了，但是對於有 import 大量 3rd party 或者 code base 很大的 app，增加 app 的 performance 也就是增加自己的 performance。
TVer 的重構計畫
TVer是一個很有名的正版日劇 app，有點像是 Neflix，但是更 local 一點，月播放量 4.5 億次，現在要重構了。從 UIKit ＋RxSwift 變成 SwiftUI、TCA 和 Swift Concurrency。
等一下，去年、不是才講過「 別哭，沒有 iOS 工程師也想改善服務」這麼可歌可泣的題目，看了自家 blog 的資料才知道，這個案情不單純，除了技術能力以外，似乎還加上了濃濃的職場政治學。
這篇的內容就是規劃，透過 module 拆分跟 feature flag 達成，有點像是三部曲中的第二部，第一部大滅絕，第二部是從灰燼中重生，明年再看看他們第三部會怎麼樣吧。
從零開始的 iOS 安全性
介紹 OWASP top 10，作者是 Security Engineer，講解 best practice，其實我覺得平常有在做資安檢測的話，應該都很熟了才對。
讓遊戲角色用你的聲音說話
使用 iOS 17 的 Accecibility API 就能做到（中文的話是 iOS 18）。後面有 demo，效果普普，但是也聽得懂啦，有講話特徵，大概像是早期的 google 小姐那樣。作者也有提到，這是為了避免哪天突然不能講話做的準備。
錄了 150 句文本讓手機學習，手機鎖定後放著充電就會開始 train 了，但是解鎖就會停止，所以建議在睡覺的時候做。
實作還蠻簡單的，都圍繞在 AVSpeech Synthesizer 的幾個 API。
你各位啊，再不寫註解啊
Apple 有 Swift API Design Guidelines 教我們要怎麼命名，作者公司裡面有一個 app 全部都不寫註解，全部都靠命名，也就是 clean code 的方式，把註解寫在 code 上面。
這場只有兩個例子，其實蠻明顯輕鬆易讀的，都是 code，沒有語言隔閡。而且太短了，聽完會覺得，什麼就這樣？我還想聽更多。建議去看 Apple 的教學。
以我個人的經驗來看：這個 app 要不是很小，就是很不重要很少改版，才有辦法這樣玩。在公司收入來源的 app 要這樣搞。必，死，無，疑。
記憶體優化大師！ iOS 應用程式開發的 5 個關鍵要點
這個題目開發 10 年以上的人應該很有感觸，古早 iPhone 的 RAM 容量只有 512MB 或 1GB，記憶體管理非常重要。 然而近年來，記憶體動輒 3~8GB ，記憶體不足的情況已很少見了。不過記憶體還是能省則省，舉一些簡單的做法來節省記憶體。
讓 iOS 和 Android 工程師攜手向前
我常常對沒去過研討會的人說，研討會的題目這麼多，不可能每個題目對你都是有幫助的，一定有很多是你聽不懂or用不到的，但是只要有一兩場是對你有幫助的，那這次來就有意義。對我來說，這兩場 session 就是這麼有意義。
KMP 實際經驗，尤其是第二篇，幾乎把可以用 kotlin 寫的部分全部都用 kotlin 了。
對我來說，比起 flutter 我更看好 KMP，因為 android 工程師本來就會，iOS 工程師已經會 swift 的前提下，大概兩週就可以寫 kotlin 了，然而 flutter 的 dart 對 iOS/Android 工程師來說，都是個更有距離的語言。再來框架的話，兩邊都是用原生 UI 框架，本來就會的東西，不需要再學別的。
今年有另外一場也是在講跨平台工具的比較，也可以參考。
幫我家的鋼琴寫了 iPad/Vision Pro app
鋼琴傳過來的是 MIDI 格式，其實蠻 simple 的：
- 首先知道按下什麼音。
- 第二步就是在 iPad/Vision Pro 上面畫個虛擬鋼琴
- 第三步模擬按下去的樣子。
做好了～從3:30 開始 Demo
從去年 iOSDC 的 logo 反推隱藏內容
設計 logo 好好玩喔，在他分析 logo 的過程中，跟解謎一樣，原本以為最後要公佈答案的，可惜沒有解答完就結束了。看完突然有好多設計 logo 的靈感。
前半部心得
今年的題目共有 92 個，我從其中挑出一些我有興趣的題目簡介，其實內容不到全部的 1/4，剩下的會寫在第二篇，從大部分人的心得中，發現大部分人共同的感觸是：「比較重要的是當下遇到的人，當下的感受」，很有日本一期一會的精神，其實參加過這麼多年研搞會，我也是這樣想：議程是研討會裡面就不重要的部分，因為錯過了可以事後再補，除非是不錄影的場次，那就一定要聽。與之相比，很多人很多事錯過了就錯過了，事後也只能惋惜，像是這個：
今年的美甲攤，這是我從來沒有在研討會看過的東西，不到現場錯過了也就錯過了，照片放大會發現設計得很精緻。
另一方面，也看到設計師與 Android 工程師參加的心得，每個人都心情澎湃熱血沸騰，想要馬上參加下一場的樣子。看到這些文章就想到曾經的自己，似乎又變得年輕幾歲了呢。