SwiftのAndroid SDK登場！クロスプラットフォーム開発に新たな波が来るか？
引用元：https://news.ycombinator.com/item?id=45698570
クロスプラットフォームフレームワークで一番大事なのはUIがどうなるかだよね。Adobe製品はどこでも異質なデザインだったし。FlutterはCupertinoテーマでiOSにピクセルパーフェクトを目指すし、React NativeはプラットフォームのUIに任せる。AppleがAndroidでAppleのUIを使わせるのか、それとも高品質なUIを作るのか、コミュニティがどう関わるのか、それが知りたいな。
UIよりビジネスロジックの共有が一番重要だと思うな。KMP (Kotlin Multiplatform) がそうであるように、Swift for AndroidでもSwiftライブラリを共有できるようになるのがメリットだよね。複雑なアプリでUIを共有するのは、結局「書いてはデバッグ」の悪夢になりがちだからね。
クライアントチームと長く働いてきたけど、ビジネスロジックの共有は本当に大変だったよ。前のスタートアップでは、ビジネスロジックを全部GraphQLサーバーに載せて、ViewModelをクライアントに送るようにしたら、クライアント側の複雑さが劇的に減ったんだ。これは本当に効果的だったね。
ビジネスロジックはサーバーでやるべきってこと？それって昔からそうじゃなかったっけ？
The Browser CompanyがSwiftUIをWindowsに移植したのはすごいよね。Swift for Androidも、SwiftUIの要素がJetpackの要素にマッピングされるような形になったらクールだね。SwiftUIって、iOSやmacOSでも「ネイティブ」ってよりは、フレームワークが解釈してUIを作る記述言語だからね。
KMPも経験あるけど、開発者体験が最大の課題だよ。iOS開発者はデバッグしにくいし、KotlinとSwiftでモデルの不一致もある。結局、Kotlin MultiplatformもKotlin for Androidとは違うから、実質3つ目の言語を導入してるようなものなんだよね。
OPはたぶんローカルのビジネスロジックについて話してるんだよ。例えば、パスワードが最低3文字必要みたいなやつ。ユーザーに即座にフィードバックするために、フロントエンドでバリデーションするって話だね。
すごく unpopular opinion だけど、俺は「ネイティブ」な見た目より、独自のUXを持つアプリが好きだな。ゲーム開発が好きだから、退屈で面白くないネイティブアプリより、クレイジーなデザインの方が断然いい。最近のAppleのアップデートも、この考えをさらに強くしたよ。
APIが十分速くてエッジにホストされていれば、サーバーサイドでのバリデーションでも即座にフィードバックできるよ。
クライアントにビジネスロジックを置くなんてありえないでしょ。サーバー側で必ず検証が必要になるし、二重挿入とか競合状態も防げない。ソロ開発者なら特に、サーバーが真実の唯一のソースであるべきだよ。
TypeScriptでクライアントとサーバーが同じコードベースを共有する場合を除き、サーバーと同じ言語じゃないなら論外だね。
Swift SDK for AndroidはUIを強制しないよ。Skip.toolsを使えばSwiftUIをJetpack Composeにブリッジして、UIもビジネスロジックも同じコードベースで書けるんだ。
詳しい情報はhttps://skip.tools/blog/fully-native-android-swift-apps/を見てね。Skip Showcaseアプリも試してみて！https://skip.tools/docs/samples/skipapp-showcase-fuse/
（注: 僕はSkipの社員で、Swift Android Workgroupの創設メンバーでもあるよ。）
この実装はUIの作り方を強制しないよ。Jetpack ComposeとKotlinでAndroidのネイティブUIを使いつつ、Swiftのビジネスロジックを呼び出せるんだ。Swiftで書かれたUIフレームワークも使えるよ。
Swiftの特性（参照カウント、GCなし、共通のライブラリや並行処理モデル、メモリモデル）は他のプラットフォームと同じで、今後の革新に繋がるだろうね。
（注: 僕はAppleのデベロッパーツールとフレームワークに関わってるよ。）
遅延は自分のAPIだけじゃなくて、ユーザーのネット環境とか外部要因にも左右されるからね。開発環境みたいに何でもうまくいくって思い込んじゃダメだよ。現実のユーザーはもっと厳しい状況で使ってるから、そこを考慮するのは大事だ。
返信ありがとう！でも正直、Skip.toolsのデモはAndroidだとニセモノっぽく見えるよ。Androidを最初からサポートしないアプリならマシかもしれないけど、全ての顧客に配慮したいならこの方向はおすすめしないな。
元のブログ記事に「UIにはSwiftでビジネスロジックを書き、AndroidのSDKでインターフェースを作るか、Skip.toolsのようなライブラリを使ってSwiftUIアプリを直接書ける」みたいな言及があると良いと思う。
もうすでに実現してるよ！SwiftUIをJetpack ComposeにするSkip.toolsもあるし、SwiftCrossUIっていうmacOS/Linux/Windows/Android/TUIをサポートする面白いプロジェクトもある。
それと、SwiftUIはもう「ネイティブ」化が進んでて、Liquid Glass UIもSwiftUIで書かれてるんだ。UIKitやAppKitがSwiftUIビューをラップするようになり、SwiftUIの部品がUIKit/AppKitの実装から置き換えられてきてるんだよ。
もしアプリをオフラインで動かしたいなら、どうすればいいの？
それは前のコメントの人が提案してることと真逆だよ。前の人は、ビジネスロジックをGQL/Apolloサーバーに移して、クライアントはそれを簡単に取り込めばいいって言ってるんだ。
FlutterはiOSのLiquid GlassやAndroidのMaterial 3で苦戦してるよ。これらの新しいUI言語の実装には相当な労力が必要なのに、今のところFlutterのロードマップには入ってないみたいだ。
React Nativeはクロスプラットフォームにかなり向いてるけど、最初から全プラットフォームでちゃんとテストしないとダメだね。iOSだけのReact Nativeアプリを後からAndroidに移植しようとすると、最初は最初は結構大変なことになるかも。
Liquid Glassなんてどうでもいいよ。AppleにとってのWindows Vistaみたいなもんさ。
彼らが言ってたことは分かったよ。なんで前のコードの持ち主たちが、ビジネスロジックをクライアント側に置くって決めたのか不思議だね。
GCなしでトランスピレーションってどう動くの？Kotlinで相当するものは全部GCヒープに割り当てられるオブジェクトだと思うんだけど。
＞デモがAndroidでは偽物に見えるって意見に対して、Android側ではSkipアプリはJetpack Composeを直接使ってるよ。これは最近のAndroidアプリ開発でGoogleが公式に推奨してるツールキット（https://developer.android.com/compose）なんだ。他のクロスプラットフォームツールみたいにネイティブUIを真似してるわけじゃなくて、Google推奨のAPIを実際に使ってるんだぜ。
ごく一部のユーザーがフォームのバリデーション結果を受け取るのに1秒かかっても、ビジネスには影響ないでしょ。
アプリのそんな中核部分に、クローズドソースのソリューション（プラットフォームのネイティブソリューション以外）を使うのは大反対だな。
議論はもう決着したんじゃないかな。Facebook、Whatsapp、Youtube、Tiktokみたいなトップアプリはどれもネイティブデザインを使ってないし、ユーザーは単に気にしてないんだよ。
うん、すごく不安になるのはわかる。でも、僕の理解では、ほとんどオープンソースなんだ（追記：ビルドツールは違うけどね）。彼らのトランスパイラソリューションは少なくともメンテナブルなKotlinコードを生成するから、Skipなしで直接作業を始められるよ。ただ、トランスパイラ方式はAndroid上のネイティブSwift SDKより制限が多いけどね。
僕は主にiOS/Macに注力してきたから、これをきっかけに使うことを考えてる。もしAndroidで十分な新しい収益源を生み出せれば、SkipなしでそれをやるAndroid開発者を雇う余裕もできるだろうしね。
＞もしウェブサイトも持っていたら、そのロジックをフロントエンドで二重に実装することになる…それはReact Nativeを支持する意見だね、欠点があってもね。
＞例えばKotlinの例外はSwiftからキャッチできないって意見に対して、ちなみにswift-javaがJava（とKotlinも）の関数呼び出しの相互運用性を管理する方法だと、JVMがスローした例外を、キャッチしてSwiftのエラーとして再スローするラッパーを使って完全にキャッチできるよ。だから、Android上で動くJVMベースのコードにSwift呼び出しを持ち込むことに関しては、ここが異なる点だろうね。
アプリの見た目は自由でいいけど、システムとの連携はネイティブにすべきだね。2025年なのにiOS版Gmailアプリでドラッグ＆ドロップできないのはありえない。GmailのアカウントだとメールアプリでIMAPのリアルタイムプッシュ通知もないし、ほんと困るよ。
もっとコメントを表示（1）
これが公式プロジェクトになったのはめちゃくちゃ嬉しいね！これまでRNとかFlutterとかのマルチプラットフォームフレームワークを触ってみたけど、どうもしっくりこなかったんだよね。やっぱりプラットフォームごとのネイティブUIを使って、ビジネスロジックだけ共有できるのが理想だよ。KMPもあるけど、普通はまずiOS用に作って、うまくいったらAndroidに移植するってパターンが多いと思うし。Swift Packageでコードを共有できるなら、ますます便利になるから期待してる！
JavaScriptでビジネスロジックをクロスプラットフォームで共有するってのは、もっと注目されるべきだと思うんだ。JavaScriptCoreとかQuickJSを使えば、iOS (v7.0+), Android、ウェブ、サーバーサイドで動くし、何よりホットリロードできるのが最高だよ。モバイル開発って一度アプリをリリースしたら、いつまでも古いバージョンが使われ続けるのがフラストレーションなんだよね。SDKのアップデートはもっと大変だし。9年も上司に提案してるけど、まだOKが出ないんだ。
いやいや、君、何か見落としてるよ。みんな、アプリと一緒にChromiumをバンドルするなんて絶対嫌だし、Discordのモバイルアプリは嫌われてるけど、あれがChromiumを使ってるって知ってる？
iOSを先に作って、後からAndroidに移植するってのが一般的なのかな？Java開発者は1億人規模でいるし、Androidアプリは簡単に作れるよ。それに比べてSwift/Objective-Cのデベロッパーはその10分の1くらいしかいないと思うな。アメリカ以外ではiPhoneはニッチな製品だし。会社だとiPadや仕事用iPhoneは使うけど、Windowsやブラウザが主要プラットフォームで、モバイルは二の次って感じじゃない？
開発者の数じゃないんだよ。アメリカでビジネスするなら、収益のほとんどはiOSユーザーから来るんだから。
アメリカではiOSの市場シェアは相変わらず強いよ。スマホの出荷台数も50%を下回ることはないんだ。
https://counterpointresearch.com/en/insights/us-smartphone-m…
これって.NETとMvvmCrossを使えば、もう実現できてることだよ。共有のコアライブラリに、各プラットフォームごとのネイティブUIを組み合わせるんだ。C#でUIKitを扱うのはすごくいい感じだし、Xamarinの時代からNugetのエコシステムと一緒にずっとうまく動いてるんだから。
React.NativeはChromiumを使ってないよ。
Xamarin (.NETとMvvmCross) もRNやFlutterと同じクロスプラットフォーム開発のカテゴリだと思うよ。最近見てないから変わってたらごめんね。
世界のOSシェアを無視しても、iOSユーザーはApp StoreでGoogle Playよりずっと多くお金を使うんだ。稼ぐにはお金が集まる所に行くべきだよね。iOS App Storeの収益はスマホ市場の約30%しかないのに、Google Playより圧倒的に大きいんだよ。参考記事：https://sqmagazine.co.uk/iphone-vs-android-statistics/
ちょっと知りたいんだけど、React.NativeってChromiumを使わないのに、どうやってネイティブUIを実装してるの？
OTAアップデートは便利だよね。RNやFlutterが対応してるのに、ネイティブiOSでできないのは意外。技術的には動的フレームワークを使えば可能らしいけど、実際はサーバー設定でカバーしやすいかな。
Xamarin (今の.NET) とXamarin.Forms UIフレームワーク (今のMAUI) は混同しない方が良いよ。前者はC#用のネイティブバインディングで、ネイティブUIをプラットフォームごとに作ってロジックだけ共有する。後者はRNみたいに一度書けばどこでも動くアプローチだからね。
OTAアップデートは昔は許されてたけど、Appleが完全に禁止したんだよ。RNを使っても、技術的にはダメなはずだけどね…。
Protonでは、共通ロジックにRustを使ってるんだって。コードベースの80%以上がRustらしいよ。残りはプラットフォーム固有の部分だって言ってた。
RNにはChromiumは入ってないよ。最適化されたJSランタイムのHermesを積んでるんだ。あと、DiscordのiOSアプリはRNを使ってなくて、ネイティブアプリだよ。
iOS開発はAndroid開発に比べて15年くらい遅れてる気がする。Xcodeが最悪だし、Appleの投資不足でエコシステムが疲弊してるから、簡単なことでもすごく大変なんだ。いろんな会社で聞いたけど、iOSのリポジトリはひどいパッチワークで、iOSを更新するとすぐ壊れるって話ばかり。今の会社だと、iOS開発者4人の方がAndroid開発者1.5人より実装に時間がかかってるよ。GoogleのKMPチームも、一番熱心なユーザーはiOS開発者で、ツール地獄から救ってほしいって懇願してたらしい。iOS開発者の採用やプロジェクトの維持にはどこも苦労してるね。
平均支出額は、親コメントの米国企業の収益って文脈ではあまり意味ないんだ。例えばNetflixやHertz、Walmartみたいな企業の場合、iOSユーザーからの収益は、結局iOSとAndroidどっちのユーザーが多いかで決まるからね。ゲーム会社が「whale」狙いなら話は別だけど。
React NativeはFlutterやCompose Multiplatformと違って、プラットフォームネイティブUIを使うんだ。5年前と比べてものすごく進化してて、特に今年は速度面で多くの改善があったよ。新しいアーキテクチャやReact Compiler、Hermes v1、Nitro Modules、Flash List v2、Legend List、React Native Skia、React Native WebGPU、Expo Use DOMなど、たくさんの技術革新があったんだ。JS/TSのツールも大幅に良くなってるよ。
なるほど、説明ありがとう。.NET製アプリの欠点は、ランタイムのせいでバイナリサイズが大きくなっちゃうことなんだ。これは今も変わらないかな？Swift for Androidでも同じ問題があるかもしれないけど、まだ確認してないよ。
ソーシャルメディア企業みたいにネットワーク効果が重要な場合でも、iOSファースト戦略は有効だよ。Snapも最初はそれで、会社が潰れるなんてことはなかったし。これはクロスプラットフォーム互換性が本当に重要なケースだよね。SnapChatにはWebクライアントがないから。HertzやCostcoなら、AndroidユーザーをWebに誘導しても特に問題ないと思うよ。
地域によるだろうけど、アメリカではiOSファーストが一般的だよ。両方開発した経験から言うと、これは納得。iOSは圧倒的に収益性が高くて、サポートの手間も少ないんだ。バージョンも少なくて済み、フォームファクターも単一。メーカーごとのバグ対応も不要。コア製品を立ち上げるのに良い環境だよ。Androidは、素早いイテレーションが終わって、対応する余裕ができてからでいいと思う。
うちの会社ではPixelフォンを使ってるよ。iPhoneも選べるけど、みんなPixelが良いって言うんだ。だから僕はMacBookとPixelの組み合わせ。iPhoneだけってのは、アメリカだけの現象じゃないかな。
ビジネスロジックをJSで動かすなら、ブラウザは不要だよ。iOSにはJavaScriptCoreがあるし、小さいJavaScriptランタイムもたくさんある。でも、JSが全てのアプリに最適とは限らないし、もっと良い言語機能やパフォーマンスに慣れてるデベロッパーもいるだろうね。
新しいレンダラーが導入されてから複雑になったけど、基本的にはReactのUIツリーをJSON形式に変換し、ネイティブ側に渡して、ネイティブ側でそれを解析してコンポーネントをレンダリングする仕組みだよ。
いくつかの”低レベル”なコンポーネントを、プラットフォームのプリミティブにマッピングすることで実現してるよ。詳しくは公式ドキュメントを見てね: https://reactnative.dev/docs/intro-react-native-components
React Nativeはネイティブ層にUIをネイティブでレンダリングするよう要求するんだ。
え、そうだったんだ。Androidのことだと思ってたよ。最近までこれは完全にネイティブだったんだね。
ありがとう。もうReact NativeとFlutterは消えてくれ。数日経つとタッチが効かなくなる四角いUIアプリにはうんざりだよ。
Flutterではコーナーラディウスを好きなように設定できるし、フレームワークもかなり速いよ。アプリがタッチに反応しないなら、それはアプリの作りが悪いんだろうね。
もっとコメントを表示（2）
Flutterには、iOSで全てのインタラクションに1フレームの遅延が生じる長年の問題があるんだ（2022年からP2）。
https://github.com/flutter/flutter/issues/110431
シェーダーコンパイルのラグとかも挙げたらキリがないしね。
確かに、しっかり探せばいくつか問題は見つかるさ。でも実際のところ、Flutterで高性能で機能的なアプリを出荷することは十分に可能だし、もう長い間そうだったよ。Dartや一貫した宣言型パラダイム、ホットリロードで最高の開発体験も得られる。何事もトレードオフさ、俺には2つのネイティブアプリを維持するメリットはほとんどないね。Flutterアプリを出荷している人も使っている人もたくさんいるんだ。だから、もう批判はやめてくれないか？
嫌いってわけじゃないよ、実は今Flutterのプロジェクトで働いてるんだ。なぜこのプラットフォームが完璧だってふりをする必要があるのか理解できないんだよね。
Flutterの客観的な欠点を指摘したことへのかなり防御的なコメントだね。トレードオフだと認めるのは良いけど、トレードオフってことは必ずデメリットがあるってことだろ。iOS上のFlutterアプリがネイティブに感じられないのは事実だ。Flutterを使っている人が悪いってわけじゃないけどさ。
それは事実じゃなくて、ごく一部のエリートなiOSスーパーユーザーの意見だよ。最近のネイティブなんて完全に過大評価された概念だし、良いUXのアプリを作る解決策にはならない。ユーザーはSwiftUI、Components、Widgetsのどれを使っているかなんて気にしないし、ネイティブアプリが何かなんて知らないよ。それが唯一の正しい聖なる道であるかのように振る舞うのはやめてくれ。
“ネイティブ”ってちゃんとした意味がある言葉なのに、Flutterはネイティブじゃないんだよね。
これがそんなに問題になるってのが気になるな。Flutterアプリを試したけど、UIがちょっと違和感あるくらいで他はスムーズだったよ。Kagi Newsみたいなアプリはどうかな？
致命的じゃないけど、iOSユーザーには違和感があるんだよね。AndroidはGoogleがネイティブコードにアクセスできるから、もっと良いかも。Flutterのもう一つの問題は、良いライブラリや見本アプリが少ないこと。ほとんどが未完成に感じるんだ。Kagi Newsアプリは例外だけど、他のFlutterアプリ同様、Material Designが強すぎてiOSでは浮いて見える。タイポグラフィもまだ変で、スクロールやタッチ操作も『Flutterっぽい』感じ。これはプラットフォーム固有の問題だよ。
Kagi Newsは確かに良くできたアプリだけど、iOSのネイティブっぽい見た目や操作感じゃないのは確かだね。
シェーダーコンパイルのラグなんて、もう何年も前の話だよ。
RNとFlutterは好きじゃないけど、Swift on AndroidがFlutterやRNと比べて、どれくらい成功すると思う？Appleはこれを出してすぐ忘れちゃうんじゃないかな。
AppleはSwiftにすごい影響力があるけど、リンクにもある通りSwift for Androidはコミュニティ主導だよ。コミュニティが必要とすれば自分たちでメンテナンスするし、Appleは邪魔しないだろうね。邪魔する理由がないでしょ？
なるほど、それならもっと大きな話になるね。投稿者はSwift for AndroidがFlutterとRNの問題を解決するって言ってたけど、それはAppleがお金と力でやるって意味だと思ってた。もし草の根プロジェクトなら、もっと先行き不透明じゃないかな？成功は祈るけどね。
それは間違った二分法だよ。僕はReact、Flutter、Swift on AndroidのどれよりもKMPに賭けるね。Reactはなくならないだろうけど、5年後にはKMPがネイティブアプリのスタートアップの定番ツールになると思うな。
RNとFlutterを葬ってくれ、って？無理だよ。iOSストアの30%以上を占めるアプリをなくせるわけない。Flutterは、あのひどいSwiftUIと比べると、開発体験が圧倒的に優れてるんだ。SwiftUIは情けないから、今やアプリの3分の1以上がFlutterで書かれてるんだよ。「コンパイラはこの式を妥当な時間内に型チェックできません」なんてエラー、本当に最悪。人類のためにも、SwiftUIを早く葬ってくれ！
Flutterやってる身からすると、Xcodeや半分もドキュメントがないAppleフレームワークには金積まれても使いたくないね。アプリのビルドとアップロードプロセスはマジで苦痛だよ、これ以上は勘弁してほしい。
Xcodeのアップロードプロセスって大変？俺はかなり良いと思うけどな。Android Studioにはそんな機能ないし、APK/AABはブラウザから手動でアップロードしないといけないんだからね。
（RNで働いてるよ）
Appleがそのプロセスをバイパスするために社内ツールを作ったくらい酷いってことだよ。
このプロジェクトってSKIPトランスパイラ（https://skip.tools/blog/bringing-swift-to-android/）と関係ある？既存のSwift / SwiftUIアプリをAndroidに移植したいんだけど、React Nativeには移行したくないんだよね。
うん、Skipは1年以上前からSwift SDK for AndroidのプレビューリリースをFuseモードで使ってて、すごく好評だよ！ネイティブなSwiftUIアプリをAndroid向けにビルドした記事（https://skip.tools/blog/fully-native-android-swift-apps/）も見てみて。トランスパイルとコンパイルについて補足すると、Skipには2つのモードがあるんだ。SwiftコードをKotlinにトランスパイルする「Skip Lite」と、Swift SDKを使ってAndroid向けにネイティブにコンパイルする「Skip Fuse」だね。両方動くし、Skip LiteはKotlinフレームワーク（Lottie, Firebase, Stripeとか）へのブリッジ統合に使われてるよ。モード比較は（https://skip.tools/docs/status/）、モジュールは（https://skip.tools/docs/modules/）で確認して。Swift SDK for Androidが正式になったのは本当に嬉しいよ！これで自分たちのプレビュービルドから公式版に切り替えられるからね。
もうトランスパイラを使う必要はないよ。Skipは最近、AndroidでのネイティブSwift実行を追加したからね。トランスパイラよりも互換性がずっと高いんだ（両方維持はしてるけど）。
うん、Skipはこの取り組みに大きく貢献してるよ！
彼らはSDKに貢献してるの？それとも何かの統合が進んでるの？俺の理解だとSDKはAndroidバイナリに直接コンパイルされるけど、Skipはトランスパイルするんだよね？どうやって一緒に動くの？
これを続けてくれるといいんだけどな。Swift Embeddedなんて、実用的なプラットフォームっていうより概念実証みたいなもんだし、解決したい問題よりそっちと戦うことになることが多いんだ。美的にはSwiftって現代の安全な言語の中で一番いいのに、もったいないよ。プロジェクトのリーダーシップに関するコミュニティの変な噂が台無しにしてるんだよね。
