1ebec223e0dc2bae61abe9e74683776d32540413fa1f9d8d1e24da37b51d7c904e6c33ba6d0e68b9675b814b76dffce19fff

우선 코틀린 멀티플랫폼은 다른 크로스플랫폼 기술들과는 다르게 자바-코틀린의 관계처럼 해당 타겟 기술을 코틀린으로 사용할 수 있는게 목적임

그런데 이 구조는 문제점인게 공유할 수 있는 코드가 별로 없지

위에 사진만 봐도 코틀린으로 공유하는 부분은 "조금의 비즈니스 로직" 딱 하나 뿐임



iOS 특화 코드(Swift 라이브러리, iOS API) 를 코틀린과 함께 or 코틀린으로 쓸 수 있다 뿐이지 안드로이드에서 Swift 라이브러리를 쓸 수 있게 하는 기술이 아니니깐 ㅇㅇ,,,



그래서 실제로 코틀린 멀티플랫폼으로 개발했다가 SwiftUI 개발자도 필요하고 안드로이드 개발자도 필요하고 이게 크로스플랫폼 개발이 맞냐면서 비판하는 의견도 많았지





1ebec223e0dc2bae61abe9e74683776d32540413fa1f9d8d1c21da37b51d7c904483c17bfb26638459f6c20f0dfa3589e7ef

근데 오늘 KotlinConf에서 Compose iOS 알파를 발표했음

이제 UI 도 코틀린으로 코드를 공유할 수 있게 된건데

안드로이드 네이티브 개발하는데 쓰는 Jetpack Compose 코드 완전히 그대로 iOS에서 사용 가능한거임(패키지명조차 같아서 프로그래머는 할게 없음)



성능이슈같은건 생각 안해도 됨

코틀린은 플러터나 리액트 네이티브처럼 추상화 위에서 동작하는게 아니라 해당 네이티브 코드로 직접 빌드됨

아까도 말했듯이 코틀린 멀티플랫폼은 자바-코틀린 관계처럼 동작함

Compose로 만든 UI는 해당 타겟에서 지원하는 네이티브 UI 엔진으로 빌드되어서 네이티브랑 다른게 없음






1ebec223e0dc2bae61abe9e74683776d32540413fa1f9b8e1c23da37b51d7c9096ab1876af052081aa166f15bfcd7e997583ab

코틀린으로 개발한 iOS앱 시연 장면

좌: iOS 우: 안드로이드








1ebec223e0dc2bae61abe9e74683776d32540413fa1f9a8b1d24da37b51d7c90bfa9fb56571759f62cc8202fc8a6bdc0ebca

또 Compose for web 도 실험적인 기능으로 발표했음

최근에 열렸던 WASM IO 에선 코틀린으로 만든 UI 를 브라우저에서 바로 실행하고, 성능까지 잘 뽑히는것까지 시연했더라






3년 정도만 지나면 꽤 볼만해지겠는데?