Why Kotlin Multiplatform Won’t Succeed - DONN FELKER
(www.donnfelker.com)
walkingice
積分 3
去年稍微摸了一下 Kotlint Multiplatform，總讓我一直想到 LLVM。
當時的需求是有一段業務邏輯，需要在 SpringBoot Server/Android/iOS 三個平台上面做同樣的處理，但不希望寫三份。如果當時採用 KMP 就能用一份源碼生出三個平台都能用的 library。就當下來說滿符合我們的需求，最後沒採用是因為它的版號仍然是 beta，公司覺得有風險。
就我對其他跨平台方案的粗淺理解(實在不太想花時間去理解這類方案了)，多是希望開發者在一個抽象層上實作，藉以避開各個平台的差異。KMP 則是僅提供 Primitive Class，再去生出各個平台的函式庫。
原文認為會有 ego 問題，要求 iOS/JS developer 去寫 Kotlin 會有難度。我覺得可以有另外一個切入點：「如果公司有 Android/iOS dev，那就讓 Android 的人多寫點 code 給 iOS 的用」，在我的角度來看應該難度沒增加。(至少當時我的 iOS dev 同事還滿期待前述的那塊邏輯他不用管 XD)
我反倒覺得 KMP 的難關在於，許諾的事情太少，但是引入的成本頗高。
譬如說，它要 Android 跟 iOS 放在同一個 Parent directory 底下，這在沒有 Mono repo 的公司就很難做到。若是獨立一個 Repo 專門處理業務邏輯，又要考慮如何把生出的 binary 放進 Android/iOS repo，這是對於開發流程的影響。另外，多一個external dependency，偶爾又要擔心版本問題。
最難的是，原本的 code base 要把業務邏輯切得夠乾淨，才能享受到 KMP 的好處，但是大公司的 code base，尤其是 client side，通常都不容易做到這點。
Android 開發者替另外一邊的人寫問題也很多:
- 為什麼我這邊工作比較多？
- Android 開發者寫 kotlin 給 iOS，那最終他還是要會 iOS 的東西。會雙修的人就是兩邊都會寫了，不會找這種工具來用。不想雙修的人會去找 flutter ，而不是 KMP
Mono repo
iOS/Android 兩個專案肥的跟什麼一樣，tool chain 也很混亂，放在一起會很痛苦
原本的 code base 要把業務邏輯切得夠乾淨
這基本上要三修的人 (backend/android/ios...etc) 的人來規劃才有機會做的好，然後沒有這種人。就算有，他也不太可能指揮所有部門聽他的