Kotlin Multiplatform怎麼幫iOS開發者跨平台少踩雷？這 3-5 招馬上試可直接省時省力。
- 先用 15 分鐘設定 KMP 專案的 basic 模組，別拖太久，速度決定後面順暢度。
新手常卡在一開始，抓緊這 15 分鐘能明顯加快進度。過 3 天再看，基本功能至少能跑起來（看 KMP module 測試結果有無 error）。
- 直接同步 Swift 跟 KMP 資料結構，前 5 個重要 model 先 mapping，避免到最後資料兜不起來。
主資料結構早同步，後面串 UI 比較省事。2 天後只要 SwiftUI 畫面能正常顯示 KMP 來的內容就算成功（UI 測試 pass、資料正確展現）。
- 每週至少測 2 次 Swift async/await 跟 KMP 的橋接，有問題就馬上修，不要拖一堆 bug 到下週。
Async 串接很容易出現非同步卡住或資料亂跳，週期性檢查能把錯誤率壓到最低。第 7 天跑 integration test，bug 數低於 3 就 OK。
- 小型專案（不到 10 個 SwiftUI 畫面）優先整合 KMP，規模太大會拖慢整體進度。
小規模先試水溫，比全產品一起上穩多了。第 14 天能正常切換畫面、資料沒延遲就是有感提升（人工測試畫面切換速度）。
- 團隊討論 KMP 實作時，前 3 次會議都要抓至少 1 個協作 bottleneck，別等到最後才發現不協調。
早期釐清協作重點，能讓 Android 跟 iOS 同時推進。21 天後回顧，如果互通流程少於 2 次卡關，代表協作有進步（回顧歷次 meeting notes 卡關紀錄）。
思考Kotlin Multiplatform如何實現跨平台共享
唉，每個在寫 iOS 的人，大概都體會過吧。就是，Android 同事那邊剛修完一個網路層的 bug，我這邊只好又從頭在 Swift 重抄一次……其實兩套程式嘛，流程根本沒差多少，就抓貼文資料、檢查一下格式、出錯還要丟 alert──可是我們得各自搞自己的版本，還有以後有變更也不能省，全靠自己記得同步。
講到跨平台，其實這幾年一直都有人跟你保證「寫一次，到處跑」超夢幻。比如 Xamarin 啦、Flutter 啦、然後還有 React Native。說的時候信誓旦旦啦，但每次最後遇到什麼？不是 app 變胖，就是畫面明明同樣代碼卻頓成一坨，有時你如果堅持原生手感，也很可能碰上一些奇怪的小毛病，不管疊多少 hacks 怎麼改，就是跟 iOS 或 Android 原生的比起來…呃，就是那種微妙的不協調。
再來，Kotlin Multiplatform（KMP）就這樣突然開始冒出來了。沒有什麼鋪天蓋地的廣告，也沒見什麼炒熱新聞，但說真的，它讓我覺得好像現狀真有可能不太一樣 - 嗯，有點像，你坐著突然發現桌子晃了一下，但旁邊的人還沒察覺……
講到跨平台，其實這幾年一直都有人跟你保證「寫一次，到處跑」超夢幻。比如 Xamarin 啦、Flutter 啦、然後還有 React Native。說的時候信誓旦旦啦，但每次最後遇到什麼？不是 app 變胖，就是畫面明明同樣代碼卻頓成一坨，有時你如果堅持原生手感，也很可能碰上一些奇怪的小毛病，不管疊多少 hacks 怎麼改，就是跟 iOS 或 Android 原生的比起來…呃，就是那種微妙的不協調。
再來，Kotlin Multiplatform（KMP）就這樣突然開始冒出來了。沒有什麼鋪天蓋地的廣告，也沒見什麼炒熱新聞，但說真的，它讓我覺得好像現狀真有可能不太一樣 - 嗯，有點像，你坐著突然發現桌子晃了一下，但旁邊的人還沒察覺……
比較Swift開發者與KMP協作的差異與優勢
KMP是什麼？嗯...你如果只想知道重點，其實就是這工具完全不會動到你的UI，一點都不沾手。像以前有些套件啊，都很想管你的畫面排版，有時候還硬生生要你放棄UIKit或SwiftUI。可是KMP它沒有興趣 - 就把非畫面的東西抓起來，比如資料模型啦、API請求啦、要不要快取、做認證這種事，就放一起，兩端共用。
iOS比較妙的是，你UI一樣寫最純的SwiftUI，不用配合別的語法，也不用為了相容犧牲那些SwiftUI本來的寫法 - 還滿舒服的。
那...直接來寫東西吧。打算隨便弄個小app給你看看：SwiftUI畫面，點開就從 https://jsonplaceholder.typicode.com/posts 抓一份文章清單。那些抓資料什麼的，通通在同一個KMP module裡處理，不管Android或iOS都能調用，反正就是省掉那堆重複造輪子的流程。而畫面這塊，在iOS上仍然是「原味」SwiftUI，用起來跟自己原本寫的一模一樣，真的沒太多違和感。
iOS比較妙的是，你UI一樣寫最純的SwiftUI，不用配合別的語法，也不用為了相容犧牲那些SwiftUI本來的寫法 - 還滿舒服的。
那...直接來寫東西吧。打算隨便弄個小app給你看看：SwiftUI畫面，點開就從 https://jsonplaceholder.typicode.com/posts 抓一份文章清單。那些抓資料什麼的，通通在同一個KMP module裡處理，不管Android或iOS都能調用，反正就是省掉那堆重複造輪子的流程。而畫面這塊，在iOS上仍然是「原味」SwiftUI，用起來跟自己原本寫的一模一樣，真的沒太多違和感。
開始設定Kotlin Multiplatform專案的必備步驟
嗯……KMP，Kotlin Multiplatform Mobile，你要我講直白一點嗎？其實它本質跟你拿Swift Package Manager打包自己的library有點像，不過它還會自動把給Android用的那份也準備好，所以你寫一次core邏輯就能同時吃兩個平台。呃，就是說，只要你的底層都寫在Kotlin裡，接下來這工具會幫你生出兩種檔案 - 一個是iOS直接可以吃的.xcframework，那種格式現在很通用（而且支援async/await）；另一個就是JAR檔案，Android那邊標準套路。
這做法…腦海中浮現一張很簡單的結構圖，中間有個「Shared Module」，把model、networking甚至整包業務code丟進去，一份source code撐住核心。然後iOS App部分走SwiftUI，用剛剛生好的.xcframework就能串接（真的不用改啥），async/await直接呼叫；Android端比較直觀，就照原本習慣叫自己的library，Compose UI隨便玩。
有些人可能好奇：「我已經寫Swift了，到底幹嘛要理這套？」最簡單的原因，大概就是你再也不怕不同平台在核心功能上搞不一樣，有bug兩邊一起修、feature同步加，也不容易出現那種「啊iOS怎麼跟Android邏輯完全分家」的局面。我老實說，如果追求效能或UI差異，其實沒犧牲什麼，就純原生跑速度照舊。如果你的產品對「每台手機操作起來必須行為一致」蠻執著 - 這方法是真的穩。重點：不用JavaScript bridge，不需要額外搞個半虛擬機器之類神秘產物在旁插手，也不是那種天馬行空一次編譯全世界的平台幻想啦，是很腳踏實地該共用共用、該獨立獨立，沒有多餘負擔。
這做法…腦海中浮現一張很簡單的結構圖，中間有個「Shared Module」，把model、networking甚至整包業務code丟進去，一份source code撐住核心。然後iOS App部分走SwiftUI，用剛剛生好的.xcframework就能串接（真的不用改啥），async/await直接呼叫；Android端比較直觀，就照原本習慣叫自己的library，Compose UI隨便玩。
有些人可能好奇：「我已經寫Swift了，到底幹嘛要理這套？」最簡單的原因，大概就是你再也不怕不同平台在核心功能上搞不一樣，有bug兩邊一起修、feature同步加，也不容易出現那種「啊iOS怎麼跟Android邏輯完全分家」的局面。我老實說，如果追求效能或UI差異，其實沒犧牲什麼，就純原生跑速度照舊。如果你的產品對「每台手機操作起來必須行為一致」蠻執著 - 這方法是真的穩。重點：不用JavaScript bridge，不需要額外搞個半虛擬機器之類神秘產物在旁插手，也不是那種天馬行空一次編譯全世界的平台幻想啦，是很腳踏實地該共用共用、該獨立獨立，沒有多餘負擔。
建立專案目錄與核心架構流程
嗯……其實KMP專案剛開始沒什麼技術難度啦，真的就是先把環境弄起來就對了。現在已經2025年了，不得不說Xcode 16以後才行，蘋果這邊也沒有什麼討論空間，你想跑iOS就只能這樣，沒得選。Android那邊要寫Kotlin的話，我建議直接用Android Studio Ladybird以上版本 - 因為JetBrains自己支援的，有時候那些小細節才不會莫名卡住，而且你也可以順便讓它跑新功能。
還有喔，Gradle不能舊，要9以上才過關。不只這樣，Kotlin語言本身也得2.1才能搞，不然很多套件根本裝不上去，有的地方直接爆錯……反正這個數字不要抄錯，比較保險。
再來我覺得最直觀的，就是你會幾乎都在Android Studio裡面轉啊。那個共用Kotlin模組嘛，其實放哪裡理論上都可，可是現實操作起來還是Android Studio裡頭弄比較輕鬆。如果臨時切回iOS、硬是要開Xcode才能動，有一點點麻煩，不過大部分流程都不用換軟體啦。
最後新建專案怎麼搞…老實說真的無腦：直接打開Android Studio，「File」>「New」>「New Project」那邊選「Kotlin Multiplatform App」，跳出對話框不是會問你的專案類型嗎？直接點那個「Shared logic for iOS and Android」，就跟著按下一步。嗯，就算一開始很迷糊，也照著這條路走沒機會走丟，很順。
還有喔，Gradle不能舊，要9以上才過關。不只這樣，Kotlin語言本身也得2.1才能搞，不然很多套件根本裝不上去，有的地方直接爆錯……反正這個數字不要抄錯，比較保險。
再來我覺得最直觀的，就是你會幾乎都在Android Studio裡面轉啊。那個共用Kotlin模組嘛，其實放哪裡理論上都可，可是現實操作起來還是Android Studio裡頭弄比較輕鬆。如果臨時切回iOS、硬是要開Xcode才能動，有一點點麻煩，不過大部分流程都不用換軟體啦。
最後新建專案怎麼搞…老實說真的無腦：直接打開Android Studio，「File」>「New」>「New Project」那邊選「Kotlin Multiplatform App」，跳出對話框不是會問你的專案類型嗎？直接點那個「Shared logic for iOS and Android」，就跟著按下一步。嗯，就算一開始很迷糊，也照著這條路走沒機會走丟，很順。
撰寫KMP共享模組的網路邏輯與資料結構
這個 KMPPostsApp 裡，其實就是三個資料夾嘛：androidApp、iosApp，還有一個 shared。androidApp 那邊是 Jetpack Compose UI 的東西，iosApp 就在跑 SwiftUI，可是整體架構比較重要的，我覺得還是 shared 這塊。因為主要邏輯都塞進那裡面了。
然後要講步驟 2，就是開始搞 shared 模組裡頭的共享邏輯。像這種共用的網路層，也是直接寫 Kotlin，很順手啦，也沒那麼複雜。
commonMain 最值得看的地方，是有一串共用依賴：io.ktor:ktor-client-core:3.0.0、io.ktor:ktor-client-json:3.0.0、io.ktor:ktor-client-logging:3.0.0、io.ktor:ktor-client-content-negotiation:3.0.0、還有 io.ktor:ktor-serialization-kotlinx-json:3.0.0。全部都是 Ktor 客戶端家族的。
iOS 的就專門加 io.ktor:ktor-client-darwin:3.0.0，要丟到 iosMain dependencies；Android 是 androidMain 加 io.ktor:ktor-client-okhttp:3.0.0。反正 iOS 跟 Android 差很明顯，每個平台各自來一份就對了，不同地方就是 dependency 要分開擺，每個 sourceSet 它自己處理自己需要那幾包。
然後要講步驟 2，就是開始搞 shared 模組裡頭的共享邏輯。像這種共用的網路層，也是直接寫 Kotlin，很順手啦，也沒那麼複雜。
dependencies 設定會放在 shared/build.gradle.kts，重點在 kotlin{} 那段，會設 ios() 跟 android()，旁邊 sourceSets 也很關鍵。commonMain 最值得看的地方，是有一串共用依賴：io.ktor:ktor-client-core:3.0.0、io.ktor:ktor-client-json:3.0.0、io.ktor:ktor-client-logging:3.0.0、io.ktor:ktor-client-content-negotiation:3.0.0、還有 io.ktor:ktor-serialization-kotlinx-json:3.0.0。全部都是 Ktor 客戶端家族的。
iOS 的就專門加 io.ktor:ktor-client-darwin:3.0.0，要丟到 iosMain dependencies；Android 是 androidMain 加 io.ktor:ktor-client-okhttp:3.0.0。反正 iOS 跟 Android 差很明顯，每個平台各自來一份就對了，不同地方就是 dependency 要分開擺，每個 sourceSet 它自己處理自己需要那幾包。
利用KMP自動橋接讓Swift async/await無縫串接
如果你有玩過 Swift 裡的 struct，Kotlin 的資料類型大概也長得差不多。不過這個 Post 模型直接加上 @Serializable，有序列化功能，完全免寫那一堆奇怪的轉換函數，對懶人超級友善。檔案路徑就是 shared/src/commonMain/kotlin/com/example/shared/Post.kt，一眼就找到。
然後在 Kotlin Multiplatform 常見那種共用網路層，就像這裡那個 PostApiService 一樣，是用 Ktor 搭 HttpClient。我看 import 超多 ktor.client 相關 package，HttpClient 隨便開一個出來，加 ContentNegotiation 插件，把 JSON 格式交給 kotlinx.serialization 處理掉。
裡面其實很單純，有個 getPosts() 函數，就是 suspend 的，所以可以放到 coroutine 跑。直接打一發 GET 到 https://jsonplaceholder.typicode.com/posts，那邊回傳什麼 response.body() 就收 List
然後在 Kotlin Multiplatform 常見那種共用網路層，就像這裡那個 PostApiService 一樣，是用 Ktor 搭 HttpClient。我看 import 超多 ktor.client 相關 package，HttpClient 隨便開一個出來，加 ContentNegotiation 插件，把 JSON 格式交給 kotlinx.serialization 處理掉。
裡面其實很單純，有個 getPosts() 函數，就是 suspend 的，所以可以放到 coroutine 跑。直接打一發 GET 到 https://jsonplaceholder.typicode.com/posts，那邊回傳什麼 response.body() 就收 List
回來，不用自己 decode、也不用特別包裝 JSON，到底有多爽你試一次就知道了。
接下來這段才真的妙：Concurrency with async/await 那橋自動幫你搭好了。你 Kotlin 寫 suspend fun getPosts(): List，結果去到 Xcode 那端，它就自動被翻成 Swift 裡面 async throws 方法。千真萬確喔，你不用自己去設計 interface、不需要 wrapper、更沒有 callback 地獄，KMP 幫你全部串起來！
所以，在 Swift 上，你只要調 class PostApiService 裡頭的 func getPosts() async throws -> [Post] 就通了，就是這麼直白。Android、iOS 都吃同一份 API code，再也不用各寫各的亂七八糟，非常療癒。
最後要做的就只是把 shared module 丟到 Xcode，就好像盪鞦韆回 iOS 領地。之前搞定那些結構設計或接法，其實核心意思就是 Kotlin 寫一次，全平台都跟著一起賺到啦。 
將Kotlin共享模組整合到SwiftUI專案的方法
開 iosApp 資料夾看一下，KMP 已經自動把 .xcframework 弄進依賴了。其實蠻省事的，共用 Kotlin code 都直接被轉成 Swift 的 class、struct，可以直接調，用起來不費腦。
ViewModel 要建的話這樣搞：PostViewModel.swift 新增一個檔，import Foundation 跟 shared，再加個 @MainActor 標籤在 class 前面（對，這步不能忘），繼承 ObservableObject。@Published 那幾個屬性 posts、isLoading、errorMessage 就標著，可以 reactive 綁定畫面。apiService = PostApiService() 也很直觀。
fetchPosts 真的沒什麼學問啦，就是 isLoading 設 true、errorMessage 清空，再 try await 一下 apiService.getPosts() 拿資料，有錯誤就 errorMessage = error.localizedDescription，最後別忘 isLoading 設回 false。
SwiftUI View 呢？去 iosApp/PostListView.swift 開新檔案。用 @StateObject 把 viewModel 接上，一開始 NavigationStack 跑起來，再放 Group 判斷三種狀態。如果 loading 就 ProgressView("Loading posts...")；有 errorMessage 則 Text("Error: \(error)") 並紅字置中，不然就 List 把 post 寫出來 - 標題 headline, body subheadline, 字色 secondary，每則下面記得補 padding，那細節還是照顧到。
.navigationTitle 給 "KMP Posts"，然後加上 .task 裡 await viewModel.fetchPosts()，畫面載入時自己抓資料，用戶啥都不用管，不用刷新也不用點按鈕，就會自己跑流程了。
實際跑 iOS app，你看到的就是 SwiftUI 原生 list，但核心網路和共用程式邏輯都交給 Kotlin KMP 處理。有點像作弊啦，其實不是，就是…很務實那種魔法感吧，說不上浮誇但效果明確。
講白一點：KMP 沒有包治百病，但可以讓 UI 用 native 的語法設計（比如蘋果那套 SwiftUI），完全順手；而那些麻煩又重複的底層事，比如拉 api 或資料存取，全通通搬去 Kotlin 層一次搞定，共用 Android iOS。有 bug？你直接在共同 core 修一份，好多步驟都能省掉。不多說了，維護超輕鬆是真的。
ViewModel 要建的話這樣搞：PostViewModel.swift 新增一個檔，import Foundation 跟 shared，再加個 @MainActor 標籤在 class 前面（對，這步不能忘），繼承 ObservableObject。@Published 那幾個屬性 posts、isLoading、errorMessage 就標著，可以 reactive 綁定畫面。apiService = PostApiService() 也很直觀。
fetchPosts 真的沒什麼學問啦，就是 isLoading 設 true、errorMessage 清空，再 try await 一下 apiService.getPosts() 拿資料，有錯誤就 errorMessage = error.localizedDescription，最後別忘 isLoading 設回 false。
SwiftUI View 呢？去 iosApp/PostListView.swift 開新檔案。用 @StateObject 把 viewModel 接上，一開始 NavigationStack 跑起來，再放 Group 判斷三種狀態。如果 loading 就 ProgressView("Loading posts...")；有 errorMessage 則 Text("Error: \(error)") 並紅字置中，不然就 List 把 post 寫出來 - 標題 headline, body subheadline, 字色 secondary，每則下面記得補 padding，那細節還是照顧到。
.navigationTitle 給 "KMP Posts"，然後加上 .task 裡 await viewModel.fetchPosts()，畫面載入時自己抓資料，用戶啥都不用管，不用刷新也不用點按鈕，就會自己跑流程了。
實際跑 iOS app，你看到的就是 SwiftUI 原生 list，但核心網路和共用程式邏輯都交給 Kotlin KMP 處理。有點像作弊啦，其實不是，就是…很務實那種魔法感吧，說不上浮誇但效果明確。
講白一點：KMP 沒有包治百病，但可以讓 UI 用 native 的語法設計（比如蘋果那套 SwiftUI），完全順手；而那些麻煩又重複的底層事，比如拉 api 或資料存取，全通通搬去 Kotlin 層一次搞定，共用 Android iOS。有 bug？你直接在共同 core 修一份，好多步驟都能省掉。不多說了，維護超輕鬆是真的。
設計SwiftUI畫面並從KMP取得資料展示
Kotlin Multiplatform這東西，有一點讓我挺佩服，就是可以直接用Swift的async/await，不需要什麼額外魔法，感覺很直白。有時候切換來用還蠻舒服，可...也不是說完全沒坑，尤其你本來只熟Swift，剛開始碰Kotlin多半會抓頭，有些語法就會忘記到底該怎麼寫。對了，Gradle那個也是 - 恩，跟Xcode比就是比較不透明？有時一些配置煩得想打人。
然後啦，每次跨語言debug就超容易迷路。我是說，那種bug卡在Kotlin跟Swift的邊界，要抓真的像找掉進沙發縫裡的耳機（超煩）。團隊合作那更麻煩，如果大家理念不同、進度不同意願也不同，就真的耗精神。可如果你們原本是Android一組、iOS又另外搞，各自照自己的App修，已經膩到不行，其實轉過來考慮Multiplatform搞不好比較輕鬆。
它不太像什麼「大家都在吹」那種buzzword工具吧，比較像，你真的能讓兩邊搭起橋。最妙的大概在這邊──iOS開發的人不會因為共用Kotlin就失去那些自家流程和介面的細節，同時可以把重複寫程式的時間壓到剩差不多四成到六成左右（差很多我自己感覺）。所以啊，如果你嫌一直維護兩套App很累，多看一眼KMP應該也不吃虧。
然後啦，每次跨語言debug就超容易迷路。我是說，那種bug卡在Kotlin跟Swift的邊界，要抓真的像找掉進沙發縫裡的耳機（超煩）。團隊合作那更麻煩，如果大家理念不同、進度不同意願也不同，就真的耗精神。可如果你們原本是Android一組、iOS又另外搞，各自照自己的App修，已經膩到不行，其實轉過來考慮Multiplatform搞不好比較輕鬆。
它不太像什麼「大家都在吹」那種buzzword工具吧，比較像，你真的能讓兩邊搭起橋。最妙的大概在這邊──iOS開發的人不會因為共用Kotlin就失去那些自家流程和介面的細節，同時可以把重複寫程式的時間壓到剩差不多四成到六成左右（差很多我自己感覺）。所以啊，如果你嫌一直維護兩套App很累，多看一眼KMP應該也不吃虧。
評估Kotlin Multiplatform在iOS團隊的真實效益與挑戰
2025年，其實...就真的不是在試驗階段了。是直接進去了，你知道嗎，就是上線正式用那種。Netflix，然後Cash App、Lenskart這些公司，現在都把這東西加到自己產品裡頭耶。有點不敢相信吧？啊你如果還沒試過，也不用太緊張啦，可以先拿個小部分玩玩就好，比如說只弄你的 models 跟 networking layer去做跨平台，先看一下效果，感覺還可以接受你再慢慢擴大嘛。很多人其實等KMP 這解法很久了，我自己是真的覺得它蠻務實的。
對了，突然想到，我們創辦人有句話想說──呃，嘿，我是 Sunil。在這邊先跟你道聲謝謝啦，不管你是怎麼滑到這裡，或者其實你一直在我們這一圈混，都蠻感激的。有件事情我想講一下，就是我們團隊啊，其實都算志工性質在經營專欄的……重點是，有超過3（應該指萬？）的人受到影響，其實我到現在也覺得有點難以置信，但反正事情還在繼續，就是想讓你知道而已。
對了，突然想到，我們創辦人有句話想說──呃，嘿，我是 Sunil。在這邊先跟你道聲謝謝啦，不管你是怎麼滑到這裡，或者其實你一直在我們這一圈混，都蠻感激的。有件事情我想講一下，就是我們團隊啊，其實都算志工性質在經營專欄的……重點是，有超過3（應該指萬？）的人受到影響，其實我到現在也覺得有點難以置信，但反正事情還在繼續，就是想讓你知道而已。
規劃下一步：小規模應用KMP推動跨平台開發
5m monthly readers？嗯，沒看錯，就是每個月有 500 萬人來逛，不是隨便吹的。你只要想像一下，一篇文章隨便都有幾十萬人在滑，那感覺還蠻誇張的啦。
更妙的是，他們完全沒拿過資金，就是靠自己撐，超佛心在養這個社群。現在不是很多平台都會拉一堆投資、到處找合作嘛，結果他們硬是一毛錢外部資助都沒有，純支持公益那種精神，看了真的有點佩服。
你如果也想支持一下，可以去追 LinkedIn、TikTok 跟 IG 帳號，追蹤又不用錢，多按幾下滑一滑就好了。或者如果你對內容感興趣，可以訂閱他們週報，一週才一封，我自己覺得不會很擾人，頂多就是多個信通知出現而已。
差點忘記，他們也很在意 Medium 上面的拍手（clap），就是看到喜歡的作者要給愛心那種感覺吧～還有最後一定要 follow 作者本人！真的不難欸，就像平常滑手機多按一下，你知道嗎？
更妙的是，他們完全沒拿過資金，就是靠自己撐，超佛心在養這個社群。現在不是很多平台都會拉一堆投資、到處找合作嘛，結果他們硬是一毛錢外部資助都沒有，純支持公益那種精神，看了真的有點佩服。
你如果也想支持一下，可以去追 LinkedIn、TikTok 跟 IG 帳號，追蹤又不用錢，多按幾下滑一滑就好了。或者如果你對內容感興趣，可以訂閱他們週報，一週才一封，我自己覺得不會很擾人，頂多就是多個信通知出現而已。
差點忘記，他們也很在意 Medium 上面的拍手（clap），就是看到喜歡的作者要給愛心那種感覺吧～還有最後一定要 follow 作者本人！真的不難欸，就像平常滑手機多按一下，你知道嗎？
