そう、Skipはこの取り組みに大きく貢献してるんだ！

もうトランスパイラーを使う必要はないよ。最近、SkipがAndroidでネイティブのSwift実行を追加したからね。トランスパイラーよりもずっと互換性が高いよ（両方とも維持してるけど）。

そうだね、Skipはもう1年以上、私たちのSwift SDKのプレビュー版をFuseモードで使っていて、すごく人気があるんだ！完全にネイティブなSwiftUIアプリをAndroidで作るために使ったブログ記事もあるよ。詳しくはここを見てね：https://skip.tools/blog/fully-native-android-swift-apps/ それから、トランスパイレーションとコンパイルについての他のコメントを明確にするために、Skipには2つのモードがあるんだ。Skip LiteはSwiftコードをKotlinにトランスパイルするモードで、Skip FuseはSwift SDKを使ってSwiftをAndroid用にネイティブにコンパイルするモードだよ。Skip FuseとSkip Liteは並行して動作していて、Skip LiteはAndroidの多くの人気Kotlinフレームワーク（Lottie、Firebase、Stripeなど）とのブリッジ統合を提供するために使われる。2つのモードの比較はここで読めるよ：https://skip.tools/docs/status/ そして、利用可能なモジュールの一部はここで見られる：https://skip.tools/docs/modules/ Swift SDK for Androidが正式にリリースされたことにすごくワクワクしてるし、私たちのプレビュー版から公式にサポートされているものに切り替えられるようになるんだ。

うん、SwiftUIも見てみたいけど、あれはAppleのエコシステム専用だよね。

メタルはAndroidでは使えないよ。ビジネスロジックはライブラリとして分ければ移植できるけど、分けたくないなら、SkipがSwiftUIを含む多くのAppleライブラリのブリッジを処理できるよ。

シェーダーの移植は、最新のLLMを使えば30分でできるよ。本気で言ってる。私もやったことあるし。シェーダーは結構シンプルだよ。ちょっと変なアーティファクトが出るかもしれないけど、それは翻訳エラーよりもプラットフォームの違いによるものだと思う。

iOSのKotlinは静的にコンパイルされて、Swift/ObjCとネイティブに相互運用できるんだ。KMPがiOSでFlutterみたいにDartのVMを動かしてるとは思えないけど？ https://kotlinlang.org/docs/native-overview.html

完璧に届けられた、リースのCMはいつまでも続くね。比喩を完全に合わせるには、クシャクシャのラッパーでKotlinとSwiftのハイブリッドが必要だけど。

Flutterではコーナー半径を好きなように設定できるし、フレームワークもかなり速いよ。アプリがタッチに反応しないなら、それはおそらく作りが悪いアプリだね。

RNやFlutterにはあまり愛着がないけど、なんでAndroidでSwiftがFlutterやRNに近いと思うの？むしろ、Appleがこれを発表してもすぐに忘れそう。

これはすでに.NETとMvvmCrossで可能だよ：共有コアライブラリと各プラットフォームのネイティブUIプロジェクト。C#でのUIKitはすごく良い感じで、Xamarinの時代からずっとうまく動いてるし、Nugetエコシステムにもアクセスできるよ。

ビジネスロジックをJavaScriptで書くのも、クロスプラットフォームの人たちには無視できないと思う。もちろん、パフォーマンスが重要な部分や非同期APIが使いづらいところでは注意が必要だけど（JavaScriptCoreやQuickJSを使うってことね、WebViewで動かすだけじゃないよ）。iOS（v7.0以上）やAndroid（最近になってだと思う）でも動くし、もちろんウェブやサーバーサイドでも使える。しかも、ホットリロードができるから、プラットフォームの制約に引っかからなければ（バグ修正や小さな挙動の変更には使えるけど、新機能を追加するのはダメ）。モバイル開発でイライラするのは、一度バージョンをリリースすると、そのバージョンが誰かのデバイスで無限に動き続けること。私の仕事はさらに一歩進んでいて、顧客にSDKのバージョンを更新してもらわないといけない（多くの顧客は社内にモバイル開発チームがないから、外注することになる）。アプリのアップデートを出す前に、エンドユーザーがその新しいデプロイメントターゲットをサポートしているかもわからない…（このアイデアを9年くらい上司に売り込んでるけど、まだ通ってないから、見落としてる部分もあるかもしれないけど、すごく大きなチャンスを逃してる気がする）。

でも、ほとんどの開発者がアプリを作りたいと思ったら、まずiOS向けに作って、アプリが注目を集めたら後でAndroidに移植するのが一般的だと思う。そうなの？Java開発者が1億人もいるみたいで、Androidアプリを作れるし、個人開発やサイドプロジェクトなら最小限の登録料でリリースできる。Objective-CやSwiftの開発者はその10%くらいしかいないみたい。私は暇なときにAndroidアプリをいじってたけど、iOSに何かをデプロイすることはできなかった。あと、アメリカ以外ではiPhoneはプライベートでは10%のニッチ商品だけど、企業はiPadをたくさん使ったり、仕事用のiPhoneを提供したりするから、企業は両方のプラットフォームを二流扱いしてるかもね（Windowsやブラウザが他の「OSっぽい」主要プラットフォームとして）。

React Nativeは、FlutterやCompose Multiplatformとは違って、プラットフォームごとにネイティブUIを使ってる。React Nativeはかなり改善されてるよ。5年前とは全然違う技術だし、特に今年はスピードに関する改善もたくさんあったし、React Nativeやコミュニティプラグインも進化してる（新しいアーキテクチャが導入されたり、Reactコンパイラ、Hermes v1、Nitroモジュール、Flash List v2、Legend List、React Native Skia、React Native WebGPU、ExpoがDOMを使うようになったり）。JS/TSエコシステムのツールもかなり改善された。

KMPは存在するけど、ほとんどの開発者がアプリを作りたいと思ったら、まずiOS向けに作るのが一般的だと思う。これ、アメリカ中心に聞こえるな。KMPの利点は、かなり成熟していて、Google Workspace（Google Docsなど）みたいな大きなアプリで使われてるから、かなり良いポジションにいるように感じる。Flutterが始まった頃はワクワクしてたけど、大きなリリースのスピード（Flutter 2のためにアプリを書き直してたら、Flutter 3が出てたとか）や、あまり注目を集めてない気がした（Dartは楽しいけど、まあ）。KMPはKotlinの上に構築されていて、JetBrainsとGoogleからの大きな投資がある。これは非常に期待できると思う。

Protonでは、共有ロジックにRustを使ってる（彼らの主張によると、コードベースの80%以上だと思う）、残りはプラットフォーム固有のもの。

今はLLMがあるから、流暢に話す必要はあんまりないよね。

これって、UIの作り方に対する期待を追加するわけじゃないってことは覚えておく価値があるね。スクリーンショットに示されている例は、KotlinがSwiftのビジネスロジックを呼び出す形で、Jetpack Compose（AndroidのネイティブUI）を使い続けてる。もちろん、Androidでは他のUIフレームワークも使えるし、Swiftで書かれたものもあるよ。この実装のいいところは、他のプラットフォームのSwiftと同じ特性をたくさん共有してることだね。一般的な代替手段とは違って、ガーベジコレクションじゃなくて参照カウントを使ってるし、同じ基盤のライブラリや並行処理のプリミティブ、メモリモデルを使ってる。みんながどう使うのか楽しみだな…これが他の面白いイノベーションのきっかけになればいいね。 [開示: 私はAppleで開発者ツールとフレームワークに関わっています。]

Apple/Swiftが開発者の間での認知度を持つことで、AppleのUIを使うことになっても、SwiftバージョンのアプリがAndroid向けにたくさん出る可能性があるかもしれないね。このリリースにはSwiftUIやUIKitをAndroidに持ってくることは含まれていないみたいだから、AppleのUIを使ってAndroidで再現するにはかなりの作業が必要だろうね。

すべてのクロスプラットフォームフレームワークにとって最も重要な質問は、UIはどうなるのか？私はちょっと意見が違うな。クロスプラットフォームフレームワークに求める最初の機能は、ネイティブUIを書けることなんだ。だからKMPが好きなんだ。SwiftUIで作ったiOSアプリとフレームワークを共有できるからね。ビジネスロジックを共有するのは多くのケースで理にかなってるし、昔からやってきたことだよ（C/C++/Rust/Goのライブラリとか）。複雑なアプリでUIを共有するのは、私の経験上、いつも「一度書いて、どこでもデバッグ」っていう悪夢になる。KMP（そしてSwift for Android）がもたらすのは、C/C++/Rust/Goとコードを共有する代わりに、Kotlin（またはSwift）のライブラリを共有できる可能性なんだ。だからAndroid/iOSのチームは、ロジックを共有するために別の言語を導入せずにAndroid/Swiftを使い続けられる。

Browser CompanyはSwiftUIをWindowsに移植するのを素晴らしい仕事をしたね。言語の要素プリミティブが、内部でネイティブなWindows UIのC++クラスにマッピングされている。もしかしたら、Swift for Androidの未来も似たような感じで、SwiftUIがJetpackの要素にマッピングされるかもしれない。それはクールだね。iOSやMacOSでは、SwiftUIは「ネイティブ」じゃないことを覚えておいてね。システムフレームワークが解釈して、NSViewsやUIViews、CGLayersなどを作り出すための記述言語なんだ。