Android 開發者替另外一邊的人寫問題也很多:
- 為什麼我這邊工作比較多？
- Android 開發者寫 kotlin 給 iOS，那最終他還是要會 iOS 的東西。會雙修的人就是兩邊都會寫了，不會找這種工具來用。不想雙修的人會去找 flutter ，而不是 KMP
Mono repo
iOS/Android 兩個專案肥的跟什麼一樣，tool chain 也很混亂，放在一起會很痛苦
原本的 code base 要把業務邏輯切得夠乾淨
這基本上要三修的人 (backend/android/ios...etc) 的人來規劃才有機會做的好，然後沒有這種人。就算有，他也不太可能指揮所有部門聽他的
去年稍微摸了一下 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，通常都不容易做到這點。
找到一個 wiki1 ，不知道哪邊有更新的
想說看到先貼過來一下
--
寫backend來看，大概在意效能跟好不好寫，現在Loom正式還沒出來，看看之後的效能比較吧。另外像裡面提到的Structured concurrency，通常意識到的機會也不多，很多時候後端應該都是一個request一個coroutine吧？我自己想要同時取多個東西的狀況或是在啟動(launch)新的coroutine的情況不太多。所以雖然有更自然的Structured concurrency語法，但用的機會不多的話，好處就比較少？ JEP 437: Structured Concurrency (Second Incubator)1 但Java 這 API 看起來也好麻煩，得自己 join 之類的。
另外影片內好像沒提到loom在除錯時看stacktrace應該會比較方便，這個感覺就差很多啊。